WireGuardインターフェイスとインターネットでiptablesを偽装しようとしています。以前は機能していましたが、最近はいくつかのWireGuardインターフェース(4つのみ)を追加しましたが、すべてのインターフェースで機能が停止しました。私をさらに混乱させることは、(WireGuardを使用して)サーバーに直接接続されているロード戦士がまだ正常に動作することです。
何らかの理由で、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に変換しました。場合に備えてデバッグする方が簡単です。
- 最後に、同じサブネットを使用する2つのゾーンによるOSPFルーティングフラッピングが原因である可能性が高いです。