私はMASQUERADE宛先が応答方向のパケットと一致しないことを観察しました（netfilter conntrackに関する限り）。
すべてのオンチェーンポリシーを受け入れる以外に、他の規則がない単純な規則があります-t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADE。
ケース1）10.a / 16ネットワークの接続初期化試行からのSYNパケットはNATを通過しますが（正常）
ケース 2) 10.a/16 ネットワークから戻ってくる SYN/ACK パケット (10.b/16 から来る SYN に対する応答、つまりこの場合イニシエータは 10.b/16 である) は変換されませんが src アドレスは次のようになります。同じです。そのままにして簡単なルーティングを行います。
これが期待された動作であるか、何か欠けているかどうかはわかりません。私の言うことは、それが他の方法で行動したくないということです。すべてが大丈夫に見えます。ただし、ドキュメントでは、これがMASQUERADEターゲットの工場出荷時のデフォルト動作であることを確認しません。
これを確認できますか？ありがとうございます。
ベストアンサー1
TCP 接続の ID は次の 4 つで定義されます。
- エンドポイントAのIPアドレス
- エンドポイントBのIPアドレス
- エンドポイントAのポート番号
- エンドポイントBのポート番号
TCPプロトコル標準は次のように規定しています。どのこれら4つの変更がある場合は、パケットを同じ接続の一部と見なすべきではありません。したがって、初期SYNがNAT処理されていない場合、NATルールをSYN / ACKパケットに適用することは意味がありません。最初から最後まで、接続全体に同じタイプのNATマッピングを適用する必要があります。そうしないと、接続でNATマッピングを追加または変更しようとすると、TCP接続が失敗します。これはTCPプロトコルの基本的な事実であり、Linux iptables / netfilterコードはそれを念頭に置いて設計されています。
あなたの場合2）では、SYN / ACKの前に10.b / 16のSYNが続きます。このSYNのソースは10.b / 16なので、MASQUERADEルールと一致せず、そのままアドレスを使用してルーティングされます。次に、SYN/ACKを10.a/16から再び10.b/16に変換する場合、オリジナルSYNの発信者これ以上応答として認識されません。送信元 IP+ 宛先 IP+ 送信元ポート+ 宛先ポートの組み合わせが有効な応答に対して予想されるものと異なるため、独自の SYN に接続します。
デフォルトでは、10.b/16で接続を開始したシステムのTCPプロトコルドライバは、「ええ、10.a.connection.destination応答がありません」と思います。そして明らかに偽のSYN / ACKが私を悩ませました。時間があれば10.b.NAT.systemつながろうとし10.a.connection.destinationました。10.b.NAT.system