私は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
答え2
MASQUERADEは、発信インターフェイスソースを持つソースNAT（SNAT）ですman iptables-extensions。
接続試行（初期SYN）がNAT処理され、接続がカーネル（「conntrack」）で追跡され、接続内のすべてのパケットが適切な方向にNAT処理されます。
はい。着信SYNに対する発信SYN / ACK応答は、SNATによってNAT処理されません。着信SYNをNATに連結するには、SNATではなくDNATが必要です。これはSYN / ACK応答もNATします。
答え3
これは、パケットが反対方向に移動すると、ソースが10.b / 24で宛先が10.a / 24であるため、規則に従って処理されないために発生します。 MASQUERADEを実行するには、2つのルールを追加する必要があります。
-t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADE
-t nat -A POSTROUTING -s 10.b.0.0/16 -d 10.a.0.0/16 -j MASQUERADE