在 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-ed（這沒關係），而
案例 2) 再次來自 10.a/16 網路的 SYN/ACK 數據包（響應來自 10.b/16 的 SYN，即在這種情況下發起者是 10.b/16）不會被翻譯，但 src 地址是保持原樣，簡單地路由。
我不確定這是預期的行為還是我錯過了什麼？我的意思是我不希望它以任何其他方式表現，一切似乎都有效。但是文件並沒有向我確認這是 MASQUERADE 目標的出廠預設行為。
你能確認一下嗎？謝謝。
TCP 連接的標識由一組四件事定義：
- 端點 A 的 IP 地址
- 端點 B 的 IP 地址
- 端點 A 的埠號
- 端點 B 的埠號
TCP 協議標準規定，如果這四項中的任何一項發生了變化，則數據包不得被視為同一連接的一部分。因此，如果初始 SYN 也未經過 NAT，則開始將 NAT 規則應用於 SYN/ACK 數據包是沒有意義的。您必須從頭到尾對整個連接應用相同類型的 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，不是他。如果我有時間，我會發送一兩個 RST 給10.b.NAT.system; 希望他意識到自己的錯誤並停止打擾我。