Iptables MASQUARADEは、要求の厳しいインターフェースではなく、インターネットから「結果」を返すようです。

Iptables MASQUARADEは、要求の厳しいインターフェースではなく、インターネットから「結果」を返すようです。

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ルーティングフラッピングが原因である可能性が高いです。

おすすめ記事