發送 SYN 後，NAT 會驗證收到的 SYN 的源埠嗎？
我不確定這個問題是否更適合 stackoverflow 或 serverfault。如果您認為它更適合 stackoverflow，請告訴我，我將刪除它並將其移至上面。
我有一個特技實施。如果您不知道 STUNT 是什麼，它是一種用於在不同 NAT 後面的兩個對等方之間建立直接 TCP 連接的協議。我將簡要概述一下，儘管我的問題與協議沒有直接關係。
這是通過使用第三方來預測每個對等方的 NAT 將映射其下一個傳出連接的埠來完成的。然後第三方告訴每個對等方對方的預測埠，並且他們都嘗試在預測埠上相互連接。當他們相互發送 SYN 數據包時，它會在該埠的 NAT 中打開一個“洞”，從而允許 SYN 數據包通過並進行握手。
我的一位同事建議讓發起 STUNT 連接的對等方嘗試將 SYN 數據包發送到預測埠以及接下來的四個埠，以防預測埠在我們之前被另一個應用程序（甚至我們的應用程序）使用嘗試連接，但在做出預測之後。
這方面的一個例子是預測另一個對等方將從埠 80 連接到我們，但隨後另一個應用程序最終使用埠 80，因此連接實際上來自埠 81；但是將 SYN 數據包發送到五個不同的埠，如果它來自 80、81、82、83 或 84，我們（理論上）會成功。但是，事實並非如此。測試時，只有第一個 SYN 包有成功的機會。即使第一個 SYN 包被發送到錯誤的埠，但接下來的四個包中的一個被發送到正確的埠，它們都被默默地丟棄；沒有響應，連接嘗試超時。
一個簡單的例子：
Peer A 正在向 Peer B 發起 STUNT 連接。
預測 Peer A 將從埠 1000 連接到 Peer B。預測 Peer B
將從埠 2000 連接到 Peer A。
伺服器將 1000 發送到 Peer B 和 2000到對等點 A。
對等點 B 電腦上的另一個應用程序建立新連接，接管埠 2000。
對等點 A 電腦上的另一個應用程序建立新連接，接管埠 1000。
對等點 A 同時嘗試在埠 2000、2001 上連接到對等點 B 、2002 年、2003 年和 2004 年；連接嘗試來自埠 1001、1002、1003、1004 和 1005。Peer
B 嘗試在埠 1000 上連接到 Peer B；連接嘗試來自埠 2001。
在 Peer A 和 Peer B 的 NAT 中分別在 1001 和 2001 埠創建了一個洞；它應該允許 SYN 數據包通過。
我認為正在發生的是對等 B 的 NAT 不允許對等 A 的 SYN 數據包通過埠 2001，因為它期望連接來自 1000 但它來自 1002。這表明 NAT 正在驗證SYN 包。
然而，根據我的閱讀，STUNT 的一個缺陷是，在創建連接時存在一個漏洞視窗，其中連接可能被另一個來源劫持。如果 NAT 驗證傳入連接的來源是標準行為，那麼我看不出這個漏洞視窗是如何存在的。
請注意，我的實現沒有缺陷。如果任一預測埠正確，則連接成功；當兩個預測埠都錯誤並且一次嘗試多個埠時，就會出現問題。
作為任何熟悉該協議的人的旁注，我正在使用涉及發送 SYN 的方法，我希望在嘗試實際連接之前靜默。我沒有使用低 TTL 實現。
我的 NAT 拒絕 SYN 數據包是因為它們不是來自預期的埠，還是其他東西拒絕了它們？如果是我的 NAT，這是預期/標準行為嗎？請注意，拒絕是指“靜默丟棄”，因為沒有返回 RST 或根本沒有任何響應，連接只是超時。
編輯：有問題的路由器都是您在沃爾瑪購買的家用路由器，而不是大型企業使用的路由器。
簡短的回答：是的——你的 NAT 拒絕數據包，因為它們不完全是它所期望的。這將因 NAT 實施而異。
拋開社論：我以前沒聽說過特技……（特技，是的——不是特技）。哦，哎呀……真是個黑客。網際網路已經變成了這個 NAT 拖車公園，我們正在訴諸這樣的黑客，這讓我哭泣。
讀完論文後，我明白他們在做什麼。它基本上是 STUN，在每個“端點”上添加了一點數據包嗅探，以嗅探初始序列號並通過網路上可以接受任意傳入 TCP 連接的第三方進行交易。實際上，這是一個可愛的把戲。
你永遠不會像這樣獲得 100% 可靠的通信。我看到最初實現此功能的研究人員有一些測試結果在埠預測方面看起來相當不錯，但是……這實際上是一個非常有趣，雖然密集的小圖表。本文更深入地探討了所有預測問題，並給出了一些成功百分比。事實上，他們做得這麼好，讓我感到震驚。
任何合理的 NAT 實施都將至少使用源 IP、目標 IP、協議、協議源埠和協議目標埠來辨識“連接”。（希望他們也在跟踪序列號/確認號。）
如果您的 SYN 與儲存在設備 NAT 表中的這些屬性的組合不完全匹配，則 NAT 實現確實應該靜默刪除它。這將是我所期望的行為。