web-dev-qa-db-ja.com

iptablesで、MASQUERADEは新しい接続（SYNパケット）でのみ一致しますか？

MASQUERADEターゲットが応答方向のパケットで一致しないことを確認しました（netfilter conntrackの観点から）。

私は単一の単純な-t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADEルール、すべてのチェーンのACCEPTポリシー以外には何もありません。

ケース1）10.a/16ネットワークからの接続初期化試行のSYNパケットはNAT処理されます（これは問題ありません）。

ケース2）10.a/16ネットワークからのSYN/ACKパケット（10.b/16からのSYNに応答して、つまり、この場合、イニシエーターは10.b/16です）は変換されませんが、srcアドレスはそのままの状態で、単純にルーティングされます。

それが期待される動作なのか、何かを逃したのかわかりませんか？私はそれが他の方法で動作することを望まないことを意味します、すべてが機能しているようです。しかし、ドキュメントでは、これがMASQUERADEターゲットの工場出荷時のデフォルトの動作であることを確認していませんでした。

確認してもらえますか？ありがとう。

iptablesnatnetfilter
1
bandie

TCP接続のIDは、次の4つのセットによって定義されます。

  • エンドポイントAのIPアドレス
  • エンドポイントBのIPアドレス
  • エンドポイントAのポート番号
  • エンドポイントBのポート番号

TCPプロトコル標準では、これら4つのもののanyが変更された場合、パケットは同じ接続の一部と見なされてはなりません。その結果、最初のSYNもNAT処理されていない場合は、SYN/ACKパケットにNATルールの適用を開始する意味があります。同じ種類のNATマッピング最初から最後までの接続全体について、またはそうでない場合NATまったく; NATマッピングの途中で接続を追加または変更しようとすると、 TCP接続が失敗します。これはTCPプロトコルの基本的な事実であり、Linux iptables/netfilterコードはそれを考慮に入れるように設計されています。

2）の場合、SYN/ACKの前に10.b/16のSYNがあります。そのSYNのソースは10.b/16であるため、MASQUERADEルールと一致せず、アドレスをそのままにしてルーティングされます。次に、10.a/16から10.b/16に戻るSYN/ACKが変換される場合、元のSYNの送信者応答として認識されなくなります独自のSYNに対して、送信元IP +宛先IP +送信元ポート+宛先ポートの組み合わせは、有効な応答に期待されるものとは異なるためです。

基本的に、10.b/16で接続を開始したシステムのTCPプロトコルドライバーは、「ため息をつきます。10.a.connection.destinationは応答しません。そして10.b.NAT.systemは明らかに偽のSYN/ACKで私を悩ませています：私は彼ではなく10.a.connection.destinationに接続しようとしています。時間があれば10.b.NAT.systemにRSTを送信します;うまくいけば彼は気づきます彼の間違いと私を悩ませることをやめます。」

2
telcoM

MASQUERADEは、発信インターフェイスのソースを備えた単なるSNAT（ソースNAT）です（man iptables-extensionsを参照）。

接続の試行（最初のSYN）がNATされ、次に接続がカーネル（ "conntrack"）で追跡され、この接続のすべてのパケットが適切な方向にNATされます。

そうです、着信SYNに対する発信SYN/ACK応答はSNATによってNATされません。 NAT着信SYNが必要な場合は、SNATではなくDNATが必要です。これにより、NAT SYN/ACKが応答します。

1
dirkt

これは、パケットが反対方向に進むと、送信元が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
0
Alexander