WireGuard 인터페이스와 인터넷에서 iptables를 가장하려고 합니다. 예전에는 작동했지만 최근에는 WireGuard 인터페이스 몇 개(4개만)를 추가했는데 모든 인터페이스에서 작동이 중단되었습니다. 나를 더욱 혼란스럽게 만드는 것은 (WireGuard를 사용하여) 서버에 직접 연결된 Road Warrior가 여전히 제대로 작동한다는 것입니다.
어떤 이유로 NATing 코드는 wg72 대신 인터넷 인터페이스(eth0이라고 함)에 "사후 프로세스 UNNATED ANSWER"를 반환하는 것 같습니다. (참고: 서버 주소는 127.127.127.127로 차단되어 있습니다.)
13:22:26.212282 IP 74.125.5.8.443 > **127.127.127.127.55576**: Flags [S.], seq 4023527294, ack 2220950656, win 65535, options [mss 1408,sackOK,TS val 808558239 ecr 648649,nop,wscale 8], length 0
13:22:26.212299 IP 74.125.5.8.443 > **192.168.61.150.55576**: Flags [S.], seq 4023527294, ack 2220950656, win 65535, options [mss 1408,sackOK,TS val 808558239 ecr 648649,nop,wscale 8], length 0
13:22:26.218685 IP 74.125.5.8.443 > 127.127.127.127.55575: Flags [S.], seq 1487311994, ack 816352590, win 65535, options [mss 1408,sackOK,TS val 808558245 ecr 648649,nop,wscale 8], length 0
13:22:26.218699 IP 74.125.5.8.443 > 192.168.61.150.55575: Flags [S.], seq 1487311994, ack 816352590, win 65535, options [mss 1408,sackOK,TS val 808558245 ecr 648649,nop,wscale 8], length 0
나는 이것이 모든 관련 방화벽 규칙을 포함하는 WireGuard 구성이라고 생각합니다.
[Interface]
Address = 10.255.16.74/30
Table = off
SaveConfig = true
PostUp = iptables -A FORWARD -i eth0 -o wg72 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostUp = iptables -A FORWARD -i eth0 -o wg72 -m conntrack --ctstate INVALID -j ACCEPT
PostUp = iptables -A FORWARD -i wg72 -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1350
PostUp = iptables -A FORWARD -i wg72 -o eth0 -j ACCEPT
PostUp = iptables -t nat -I POSTROUTING 1 -s 192.168.61.0/24 -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = iptables -D FORWARD -i eth0 -o wg72 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PreDown = iptables -D FORWARD -i wg72 -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1350
PreDown = iptables -D FORWARD -i wg72 -o eth0 -j ACCEPT
PreDown = iptables -t nat -D POSTROUTING -s 192.168.61.0/24 -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 12072
PrivateKey = MAYBEMAYBENOT
[Peer]
PublicKey = BLAHBLAHBLAH
AllowedIPs = 0.0.0.0/0
Endpoint = x.x.x.x:18445
여기서는 이러한 규칙의 통계 결과를 사용하려고 합니다. 호스트의 일반 규칙이 이미 이를 처리하고 있기 때문에 특정 "관련성, 확립됨"을 사용하지 않는 것을 확인했습니다. 여러 가지 변형된 규칙을 시도했지만 결과는 항상 같았습니다.
0 0 ACCEPT all -- eth0 wg72 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- eth0 wg72 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
1953 117K TCPMSS tcp -- wg72 eth0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS set 1350
4334 529K ACCEPT all -- wg72 eth0 0.0.0.0/0 0.0.0.0/0
6148 925K ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
NAT 테이블은 다음과 같습니다.
Chain POSTROUTING (policy ACCEPT 440 packets, 52566 bytes)
pkts bytes target prot opt in out source destination
2128 208K MASQUERADE all -- * eth0 192.168.61.0/24 0.0.0.0/0
이것은 요약 네트워크 다이어그램입니다.
체계VPS는 QENU/KVM에서 실행된다고 생각합니다)
uname -a:Linux xyz 4.15.0-213-generic #224-Ubuntu SMP 월 6월 19일 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
iptables버전: iptables v1.6.1
답변1
문제 발견:
--업그레이드된 커널 4.15.0-213-generic. Wireguard의 불안정성 문제 중 일부를 해결했지만 더 중요한 것은 가끔 화성 유형 라우팅에 대해 불평하기 시작한다는 것입니다.
-- 외계인 검색에서 iptables를 nft로 변환했습니다. 만일의 경우에 대비해 디버그하기가 더 쉽습니다.
-- 마지막으로, 동일한 서브넷을 사용하는 두 영역으로 인한 OSPF 라우팅 플래핑이 원인일 가능성이 높습니다.