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
_
さらに、図に示されているように、lo
インターフェイスに_1.1.1.6
_アドレスが構成されています。技術的には、これは必要ありません。つまり、削除しても、_linux-svr
_は引き続き接続できます。したがって、NATゲートウェイでSNAT送信元アドレスを構成するポイントはありますか?_1.1.1.6
_を_linux-svr
_に関連付けてトレースする方が簡単なので、トラブルシューティングの目的のみです。
netfilterはルートに依存しません。それは、以下で何が起こるかを説明する重要なことです。netfilterのNAT処理はアドレスを変更し、場合によっては、これがルート決定の前に行われると、これがルート決定を変更します。 netfilterはルーティングの決定自体を行いません。それはルーティングスタックの役割のみです。
linux-routerには追加のfirewallingルールがないと仮定しています(デフォルトのiptablesfilterテーブル内)。これは質問で言及されていないためです。また、ケースが増えて対処するのを避けるために、10.99.99.0/24 LANでlinux-srv(およびlinux-router)以外に検討するシステムが他にないことを想定しています(それらに対処するのも難しい)。
SNATは、ルーティングが決定された後、POSTROUTINGで発生します。 SNATは、指定された基準に一致するIPを検出すると、返信を処理するためにconntrackエントリを追加します。これに似たことがlinux-routerで発生します(_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
_
返信が本当に返ってくるようにするのはnetfilterの仕事ではありません。これもルーティングスタックジョブです(linux-routerが制御できない外部ルーティングを含む)。
削除される前は、1.1.1.6はlinux-routerのIPでした。 Linuxは 弱いホストモデル に従っているため、このIPが追加されたインターフェイスはそれほど問題ではありませんでした。任意のインターフェイスで受信したこのIPへのクエリに応答できます。 M10iは1.1.1.6に到達するための特定のルートを持っているため、このエントリを削除しても1.1.1.6のパケットを受信できます。linux-routerに属する1.1.215.48を使用します。したがって、linux-routerはこのIPのARP要求を取得しません。M10iからのARP要求は常に1.1.215.48です(同じことを言えば、M10iのARPテーブルのみが1.1.1.6ではなく1.1.215.48をキャッシュしました)。つまり、このIPの存在は重要ではありません。linux-routerwillalways1.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-routerは、次のように、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)がルーティングテーブルの反対側にあり、Strict PathForwardingによってフィルタリングされているため。厳密なリバースパス転送がなければ、これはM10iとlinux-routerの間のループを引き起こし、パケットのTTLが0にデクリメントされ、その後パケットもドロップされます。
着信パケットがする場合は、conntrackによってNATおよび追跡された以前のフローと一致します。
前の例: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]
_
いくつかの事前ルーティングポイントで、conntrackは "de-SNAT"を処理します(注意として、このパケットは二度と通過しませんiptables 'natテーブル。これも前の回路図に記述されています:「nat」テーブルは「NEW」接続についてのみ参照されます)。宛先IPが10.99.99.50に変更され、パケットは最初のルート決定に到達します。つまり、linux-srvにルーティングされます。すべてが正常に動作します。
したがって、私は1.1.1.6を削除するとどうなるかを説明しました。インターネットクライアントとしてのlinux-srvには影響しませんが、M10iとlinux-routerの間で、無関係なイングレスに若干の混乱を引き起こしますパケット。
インターネット上の一部のクライアントがlinux-routerのDNATルールを使用してlinux-srvに到達するようにしたい場合は、影響を受ける接続(例:linux-srvtcpポートのWebサーバー) 80)、すべてが中断することなく動作します。他の試みについても、M10iとlinux-routerの間に小さな問題があります。
情報が提供されませんでした:発信インターフェイスにセレクター/フィルターもあるかどうか。以下の2つのルールは、_iptables -t nat -n -L
_から同じ出力を取得します(ただし、_iptables -t nat -n -v -L
_以上の_iptables-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-routerに属しています
プライベートIP宛先アドレスがeth0の側からネットワーク上に来るのを見ることができないため、linux-routerは事実上one IPアドレスしかルーティングできません:linux-srvの10.99.99.50およびルーティングは、最初に10.99.99.50から開始されたときにのみ発生するため、パブリックIPにSNATされます。iptablesは最初の接続(状態NEW)でのみ新しいconntrackエントリを作成するため、この後、conntrackエントリは変更されず、すべてが正常に機能します。
linux-routerから削除された1.1.1.6
linux-srvの場合、インターネットに接続してもすべてが期待どおりに機能します。前の説明も当てはまります。
外部から1.1.1.6への不明な着信接続の場合(例:198.51.100.101から):
ルーティングスタックは、1.1.1.6をM10iにルーティングする必要があると判断します(前述の説明を参照)。暫定的なconntrackエントリが状態NEWで追加され、パケットがnat/POSTROUTINGに到達します。パケットは1.1.1.6にSNATされ、M10iに返送されます。M10iは1.1.1.6へのルートを持ち、変更されたパケットをlinux-routerに送信します。送信元IPと宛先IPの両方が1.1.1.6です(送信元はルーティングテーブルの正しい側にあるため、 Strict Reverse Path Forwardingによってもドロップされません)。linux-routerパケットを受信します...そこからバグかどうかはわかりませんが、_conntrack -E
_を使用して、単一のTCP 198.51.100.101から受信した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-routerの間で実際にループが発生しています(TTLが0に低下するまで)。
ローカルIPアドレス1.1.1.6を削除しないでください。あなたはルーティングの問題を作成していますが、それらのルーティングの問題を修正するのはnetfilterの役割ではありません。これらのループを防ぐファイアウォールルールを追加したとしても、誤ったルートを使用するのは正しい動作ではありません。
同様に、SNATルールのソースIPセレクターを削除することもできますが、インターフェイスが選択されていない場合(つまり、このルールを選択した場合:_iptables -t nat -A POSTROUTING -j SNAT --to-source 1.1.1.6
_)はお勧めできません。インターネット上でルーティングできないプライベートIPアドレスが機能しているため、機能しているだけです。そうでない場合、linux-routerのeth2インターフェースの背後にあるLANにアクセスしようとする外部からの接続は、1.1.1.6にSNATされます。
たとえば、linux-srvからインターネットから到達可能で、linux-srvが1.1.1.6とは異なる送信元アドレスを表示できないようにするDNATルールを追加した場合も同様です。シミュレーションの具体例を次に示します(1.1.1.6をlinux-routerに正常に復元します)。
_# 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を参照してください。