☰

NATゲートウェイでSNATソースアドレスを設定する必要がありますか？

tag-icon • tag-icon iptables nat
NATゲートウェイでSNATソースアドレスを設定する必要がありますか？

次のネットワークトポロジを想定します。 NATゲートウェイネットワーク設定

NAT ゲートウェイには、linux-router次の SNAT ルールがあります。

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  10.99.99.50          anywhere             to:1.1.1.6

また、図のようにインターフェイスに1.1.1.6アドレスが設定されています。lo技術的にはこれは必要ありません。つまり、削除してlinux-svrも接続できます。それでは、NATゲートウェイでSNATソースアドレスを設定するのが合理的ですか？相関と逆1.1.1.6追跡がより簡単なため、トラブルシューティング目的にのみ使用されますかlinux-svr？

答え1

Webフィルタパスとは何の関係もありません。これは、以下で何が起こるかを説明する上で重要な要素です。WebフィルタNAT処理はアドレスを変更し、場合によってはルーティング決定の前にこの操作を実行すると、ルーティング決定が変更されることがあります。Webフィルタそれ自体はルーティング決定をしません。これは単にルーティングスタックの役割です。

私はこの下に仮定していますLinuxルーター追加なしファイアウォールルール（基本的にiptables フィルター表）質問に言及されたことがないからです。また、解決すべきケースの数が増えないようにするために、次のような事項をさらに想定しています。Linux-srv（そしてLinuxルーター）10.99.99.0/24 LANにあります（修正することは難しくありません）。

削除情報 1.1.1.6

SNAT は、ルーティング決定が行われた後の POSTROUTING 中に発生します。 SNAT が指定された基準に一致する IP を見つけた場合、応答を処理するために conntrack エントリを追加します。同様のことが起こりました。Linuxルーター（使用conntrack -E -e NEW）：

    [NEW] tcp      6 120 SYN_SENT src=10.99.99.50 dst=8.8.8.8 sport=57490 dport=80 [UNREPLIED] src=8.8.8.8 dst=1.1.1.6 sport=80 dport=57490

そうではないWebフィルタ応答が実際に戻ってきたかどうかを確認するのはあなたの仕事です。これは再ルーティングスタックの作業です（外部ルーティングを含む）。Linuxルーター制御なし）。

削除前のIPアドレスは1.1.1.6でした。Linuxルーター。 Linux は次のようなので、この IP がどのインターフェイスに追加されるかは問題ではありません。弱いホストモデル：すべてのインターフェイスで受信したこのIPに対するクエリに応答できます。このエントリを削除しても、1.1.1.6のパケット受信はブロックされません。M10i1.1.1.6への特定のパスがあります。次の 1.1.215.48 を使用してください。Linuxルーター。だからLinuxルーターこのIPのARP要求を受信できませんでした。以下からARPリクエストを受け取りました。M10i常に1.1.215.48です（同様に、次のことを意味します。）M10iARPテーブルは1.1.1.6ではなく1.1.215.48のみをキャッシュします。これは、このIPの存在が重要ではないことを意味します。Linuxルーター〜するいつも1.1.1.6 でトラフィックを受信します。しかし、今違いがあります。

  • 受信パケットが以前に生成されたconntrackエントリと一致しない場合

パケットが以前のアクティビティに関連していない場合Linux-srv、パケットが最初に到着しますパスの決定のように、この図。現在のルーティングテーブルによると、次のようになります。

    # ip route get from 198.51.100.101 iif eth0 1.1.1.6
    1.1.1.6 from 198.51.100.101 via 1.1.215.60 dev eth0 
        cache iif eth0

もしそうならM10i（または1.1.215.32/27 LANのすべてのシステム）Linuxルーター以下のように、ICMPリダイレクトも随時追加されます。

    # ip route get from 1.1.215.60 iif eth0 1.1.1.6
    1.1.1.6 from 1.1.215.60 via 1.1.215.60 dev eth0 
        cache <redirect> iif eth0

それにもかかわらず、インターネットからの着信パケットの場合、パケットは再送信されます。M10i、実装可能厳格なリバースパスの転送：後ろにルーティングされたパケットは破棄されます。M10iこれは、ソース（198.51.100.101）がルーティングテーブルの間違った側にあり、したがって厳密なパス転送によってフィルタリングされるためです。厳密なリバースパス転送がない場合、間にループが発生します。M10iそしてLinuxルーターパケットの TTL が 0 に減少するまで、パケットは破棄されます。

  • パケットが入ってくる場合する以前にNATで接続され、conntrackで追跡されたフローを一致させます。

前の例：8.8.8.8 tcpポート80から1.1.1.6ポート57490に受信された応答パケットは、以下を介して追跡されますconntrack -E。

     [UPDATE] tcp      6 60 SYN_RECV src=10.99.99.50 dst=8.8.8.8 sport=57490 dport=80 src=8.8.8.8 dst=1.1.1.6 sport=80 dport=57490
     [UPDATE] tcp      6 432000 ESTABLISHED src=10.99.99.50 dst=8.8.8.8 sport=57490 dport=80 src=8.8.8.8 dst=1.1.1.6 sport=80 dport=57490 [ASSURED]

特定の事前ルーティングポイントでは、つながる「de-SNAT」を処理します。 （注：このパケットは再び通過しません。）iptables'natテーブル、これは前の回路図にも記録されています。「新しい」接続についてのみ「nat」テーブルを参照してください。）。これで、宛先IPは10.99.99.50に変更され、パケットは最初のルーティング決定に達します。Linux-srv。すべてが正常です。

だから1.1.1.6を削除すると何が起こるのか説明しました。影響はありません。Linux-srvインターネットクライアントとして機能しますが、少し中断が発生します。M10iそしてLinuxルーター無関係な受信パケットの場合。

インターネット上の一部の顧客に到達したい場合Linux-srvDNATルールの使用Linuxルーター、影響を受ける接続（Webサーバーなど）についてLinux-srvTCPポート80）、すべてが中断することなく正常に実行されます。他の試みにも小さな問題がありますM10iそしてLinuxルーター。

SNATルールの送信元IPセレクタ/フィルタ削除情報

提供された情報なし：発信インターフェイスにセレクタ/フィルタがあるかどうか。以下の2つの規則は次のような結果を得ますiptables -t nat -n -L（しかし、まだ良い結果ではありません）。iptables -t nat -n -v -Liptables-save

iptables -t nat -A POSTROUTING -o eth0 -s 10.99.99.254 -j SNAT --to-source 1.1.1.6

または

iptables -t nat -A POSTROUTING -s 10.99.99.254 -j SNAT --to-source 1.1.1.6

実際、この場合、次の2つのコマンドのいずれかを使用することは重要ではありません。

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 1.1.1.6
iptables -t nat -A POSTROUTING -j SNAT --to-source 1.1.1.6
  • 1.1.1.6は依然として属していますLinuxルーター

eth0側ではプライベートIP宛先アドレスが見えないので、Linuxルーター効率的にルーティングできる必要がある一つIPアドレス：Linux-srvこれは10.99.99.50で、このルートは10.99.99.50で最初に開始された場合にのみ発生するため、パブリックIPでSNATされます。 ~からiptables新しいconntrackエントリは、初期接続（NEW状態）でのみ作成されます。その後、conntrackエントリは変更されなくなり、すべてが正しく機能します。

  • 1.1.1.6 削除済みLinuxルーター

  • ~のためLinux-srvインターネットに接続すると、すべてが期待どおりに機能します。前の説明も適用されます。

  • 外部から 1.1.1.6 (例: 198.51.100.101) に着信する不明な接続の場合:

    ルーティングスタックは、1.1.1.6を次にルーティングする必要があると判断します。M10i（前の説明を参照）NEW状態に一時的なconntrackエントリが追加され、パケットはnat / POSTROUTINGに到着します。パケットは1.1.1.6にSNATされ、再送信されます。M10i。M10i1.1.1.6 へのルートがあり、再変更されたパケットは次に送信されます。Linuxルーター送信元と宛先のIPはどちらも1.1.1.6です（ソースがルーティングテーブルの正しい側にあるため、厳密なリバースパス転送はそれを削除しません）。Linuxルーターconntrack -Eパケットが受信されました...バグかどうかは不明ですが、198.51.100.101で受信された単一のTCP SYNパケットを使用して状況を再現する実験でキャプチャされた内容は次のとおりです。

         # conntrack -E
         [NEW] tcp      6 120 SYN_SENT src=198.51.100.101 dst=1.1.1.6 sport=48202 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=48202
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=48202 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=60062
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=60062 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=23442
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=23442 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=54429
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=54429 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=7652
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=7652 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=34503
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=34503 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=49256
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=49256 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=58399
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=58399 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=54522
         [...]

    netfilterが異常に動作していても、間にループがあります。M10iそしてLinuxルーター（TTLが0になるまで）。

結論として

ローカルIPアドレス1.1.1.6を削除しないでください。ルーティングの問題が発生していますが、そうではありません。Webフィルタこれらのルーティングの問題を修正してください。これらのループを防ぐためにファイアウォールルールを追加しても、間違ったルーティングを使用することは賢明な対策ではありません。

同様に、SNATルールの送信元IPセレクタを削除することを選択できますが、インターフェイスが選択されていない場合（つまり、このルールを選択した場合）は削除しないことをお勧めしますiptables -t nat -A POSTROUTING -j SNAT --to-source 1.1.1.6。インターネットからルーティングできないプライベートIPアドレスがあるために機能します。そうでない場合、外部からのすべての着信接続は背面LANに到達しようとします。Linuxルーターeth2 インターフェイスは 1.1.1.6 に SNAT されます。

例えば、以下から特定のサービスを得るためにDNATルールを追加した場合も同様です。Linux-srvインターネットからアクセスできますLinux-srv1.1.1.6 とは異なるソースアドレスは決して表示されません。以下は、シミュレーションの具体例です（1.1.1.6から1.1.1.6への一般復帰）。Linuxルーター):

# ip -br a
lo               UNKNOWN        127.0.0.1/8 1.1.1.6/32 
eth0@if5         UP             1.1.215.48/27 
eth2@if4         UP             10.99.99.254/24 

# iptables -t nat -A PREROUTING -d 1.1.1.6 -p tcp --dport 80 -j DNAT --to-destination 10.99.99.50

# iptables-save | grep -v ^#
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -d 1.1.1.6/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.99.99.50
-A POSTROUTING -j SNAT --to-source 1.1.1.6
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

# conntrack -E 
   [NEW] tcp      6 120 SYN_SENT src=198.51.100.101 dst=1.1.1.6 sport=45752 dport=80 [UNREPLIED] src=10.99.99.50 dst=1.1.1.6 sport=80 dport=45752
 [UPDATE] tcp      6 60 SYN_RECV src=198.51.100.101 dst=1.1.1.6 sport=45752 dport=80 src=10.99.99.50 dst=1.1.1.6 sport=80 dport=45752
 [UPDATE] tcp      6 432000 ESTABLISHED src=198.51.100.101 dst=1.1.1.6 sport=45752 dport=80 src=10.99.99.50 dst=1.1.1.6 sport=80 dport=45752 [ASSURED]

明確ではないかもしれませんが、これは予想される応答が10.99.99.50から1.1.1.6（198.51.100.101ではない）であることを意味します。Linux-srv実際に接続されているIPアドレスを無視すると、常に1.1.1.6が表示されます。

関連情報