원래 소스 공용 IP를 변경하지 않고 VPN 터널을 통해 로컬 웹 서버로 포트 80,443을 전달하는 테스트를 위해 VPS를 사용하려고 합니다. 여기서 주요 문제는 라우팅입니다. 에지 라우팅 장치는 실제로 공용 IP가 있는 2개의 인터페이스(실제 WAN 및 VPN 인터페이스)를 보게 되기 때문입니다.
분명히 간단한 해결책은 VPN 터널을 통해 SNAT 트래픽을 보내는 것이지만 웹 트래픽이 실제로 어디에서 오는지 더 깊이 이해하고 싶었으며 NAT를 더 많이 수행할수록 시스템에 더 많은 오버헤드가 발생하게 됩니다. 또한 VPS를 통과하는 네트워크 트래픽의 암호 해독을 거부하므로 VPS에 역방향 프록시를 배치하지 않습니다.
이제 지금까지의 테스트는 다음과 같습니다. 사용된 IP: Web SRV: 192.168.0.2, VPS Wireguard 주소: 192.168.200.1, Router Wireguard 주소: 192.168.200.2.
VPS 서버, 로컬 라우터 및 웹 서버 역할을 하는 여러 Debian 11 시스템으로 가상 테스트 네트워크를 설정했습니다.
VPS에서 DNAT 트래픽은 포트 80,443의 인터페이스로 들어갑니다.
iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport –dports 80,443 -j DNAT –to-destination 192.168.0.2
ipv4 전달을 활성화하기 위해 sysctl.conf를 설정했습니다. VPS에 192.168.0.2에 도달할 위치를 나타내는 고정 경로가 있습니다.
ip route add 192.168.0.2/32 via 192.168.200.2 dev wg0
로컬 라우터에서 온라인에서 인터페이스 기반 응답 기반 규칙을 발견했습니다.
echo 200 vpsrt >> /etc/iproute2/rt_tables
ip rule add from 192.168.200.2 table vpsrt prio 1
ip route add default via 192.168.200.1 dev wg0 table vpsrt
VPN 터널은 라우터에 있고 웹 서버에는 기본 게이트웨이가 구성되어 있으므로 로컬 라우터와 웹 서버 간의 반환 트래픽은 전혀 변경되지 않습니다.
VPS의 wg0.conf(서버 역할):
[Interface]
PrivateKey=*
Address=192.168.200.1/30
ListenPort=50000
[Peer]
PublicKey=*
AllowedIPs=192.168.200.2/32,192.168.0.2/32
라우터의 wg0.conf(클라이언트 역할):
[Interface]
Address=192.168.200.2/32
PrivateKey=*
[Peer]
Endpoint=PUBIPVPS:50000
PublicKey=*
AllowedIPs=172.20.200.0/30
Wireguard 터널이 작동하는지 확인했습니다. 각 장치에서 개별적으로 192.168.200.1 및 .2를 ping할 수 있으며 wg show에서는 핸드셰이크가 완료되었으며 데이터가 양방향으로 흐르고 있다고 말합니다.
일부 PCAP를 수행하면 VPS를 통한 트래픽이 정확합니다. VPS의 wg0에 있는 Tcpdump는 주소가 192.168.0.2 포트 443인 패킷을 표시합니다. VPS의 WG Show는 1.3Kb를 전송했다고 말하지만, 라우터의 WG Show는 500바이트(테스트 핑)만 수신했다고 말합니다. 라우터 WAN 인터페이스의 Tcpdump는 Wireguard 패킷이 라우터에 도착하고 있음을 보여줍니다. 그러나 라우터 wg0의 Tcpdump는 어떤 패킷도 수신하지 못했다는 것을 보여줍니다.
문제는 Wireguard가 (라우터의) AllowedIPs에 소스 IP가 구성되지 않은 패킷을 자동으로 삭제한다는 것입니다. 그러나 문제는 wg0.conf 라우터에 0.0.0.0/0을 넣을 수 없다는 것입니다. 왜냐하면 이 라우터는 터널을 전체 네트워크의 기본 게이트웨이로 사용하기 시작하기 때문입니다!
Wireguard를 기본이 아닌 게이트웨이로 사용하면 소스 기반 라우팅이 불가능합니까? 다른 터널링 소프트웨어를 사용하는 잠재적인 해결 방법이 있습니까? 저는 Wireguard의 속도를 정말 좋아하지만 SNAT/Masquerade가 없으면 속도가 극도로 제한됩니다.
고쳐 쓰다: 방금 다음 기사를 찾았습니다. https://techoverflow.net/2021/07/09/what-does-wireguard-allowedips-actually-do/ Wireguard "방화벽"과 라우팅이 AllowedIP를 사용하여 함께 번들로 제공된다는 것을 설명합니다.
좀 더 테스트하면 라우터의 AllowedIP를 0.0.0.0/0으로 설정하고 wg0.conf에 사후 규칙을 추가하여 기본 게이트웨이 경로를 제거하고 터널 IP에 고정 경로만 추가할 수 있습니다. (불행히도 wireguard는 "방화벽"과 라우팅을 하나의 옵션으로 결합하기로 선택합니다)
라우터의 wg0 인터페이스의 Tcpdump는 패킷이 이제 터널을 통과하고 있음을 보여줍니다. 라우터 LAN 인터페이스의 Tcpdump는 패킷이 전송되었고 웹 서버가 응답하고 있음을 보여줍니다. 그러나 이제 문제는 웹 서버 응답이 와이어가드 터널로 전달되지 않기 때문에 인터페이스 소스 기반 라우팅 규칙이 작동하지 않는 것 같다는 것입니다.
라우터의 WAN 인터페이스에 있는 Tcpdump는 웹 서버 Syn-ack이 게이트웨이 밖으로 푸시되는 것을 보여줍니다. 이제 내 문제는 위에서 언급한 소스 기반 라우팅 규칙에 있습니다. 소스 기반 라우팅은 제가 아는 범위를 벗어나므로 이에 대한 도움을 주시면 대단히 감사하겠습니다.
답변1
당신은 90% 성공했습니다. vpsrt라우터에서 사용자 정의 라우팅 테이블을 설정할 때:
echo 200 vpsrt >> /etc/iproute2/rt_tables
ip rule add from 192.168.200.2 table vpsrt prio 1
ip route add default via 192.168.200.1 dev wg0 table vpsrt
당신은 사용해야합니다웹 서버대신 IP 주소라우터IP 주소, 두 번째 줄:
ip rule add from 192.168.0.2 table vpsrt prio 1
그러면 라우터가 웹 서버의 모든 트래픽을 WireGuard 터널로 보내도록 지시합니다. 라우터의 WireGuard 구성에 VPS 서버 피어 항목의 일부로 포함하는 한 AllowedIPs=0.0.0.0/0WireGuard 터널은 트래픽을 수락하여 VPS 서버로 다시 보냅니다.
또한 라우터의 WireGuard 구성에서 이 테이블을 지정하는 경우 위의 세 번째 줄은 필요하지 않습니다.
[Interface]
Address=192.168.200.2/32
PrivateKey=*
Table=vpsrt
[Peer]
Endpoint=PUBIPVPS:50000
PublicKey=*
AllowedIPs=0.0.0.0/0
이 설정을 사용하면 전역 기본 경로를 방해하지 않고 wg-quick기본 경로가 사용자 정의 테이블에 추가됩니다 .vpsrt
또한 라우팅을 원하지 않는 경우모두웹 서버에서 VPS로의 트래픽(TCP 포트 80 및 443의 응답만 해당) 위의 두 번째 줄 대신 다음 규칙을 사용할 수 있습니다.
ip rule add from 192.168.0.2 ipproto tcp sport 80 table vpsrt priority 1
ip rule add from 192.168.0.2 ipproto tcp sport 443 table vpsrt priority 2
답변2
VRF(가상 라우팅 및 전달) 사용을 고려할 수 있습니다. VRF는 자체 기본 게이트웨이로 별도의 라우팅 테이블을 구성하는 데 사용됩니다. Wireguard 인터페이스와 웹 서버를 VRF에 연결할 수 있으며 트래픽은 현재 기존 연결과 분리됩니다.
VRF를 사용하는 좋은 예는 다음과 같습니다.https://interpip.es/linux/creating-a-vrf-and-running-services-inside-it-on-linux/