我正在開發一款能夠在DSL兩種不同NAT上正常工作的p2p聊天應用程序，但是當涉及到3G USB互聯網連接時，它會失敗。爲什麼3G網絡NAT不能被繞過？
我發現它不可能繞過3g網絡的NAT，而像Skype和山洪這樣的已知P2P應用程序也無法繞過3G網絡，只要遇到這些問題，就通過中央服務器發送數據。
我想知道什麼是3G網絡的體系結構。我聽說他們沒有專用IP，端口對只有公共IP，端口可用，並且一個公共端口可以分配給很多設備，我是否正確？如果是的話服務器如何發送數據到3G網絡？
維基百科claims電信級NAT 可以通過P2P應用被遍歷，即使在端口共享存在：
上述技術一個CGN內正常工作。 CGN也可以使用端口過載行爲，這意味着可以將具有相同端口值的不同內部端點映射到同一個公共端點 。這並不會破壞5協議，公共地址，公共端口，遠程地址，遠程端口的唯一性，因此是可以接受的。保留TCP端口也會導致案例 CGN端口過載，並且不是協議 健全性的問題。用於TCP的端口過載允許CGN在內部安裝更多主機 ，同時保留TCP端對端通信保證。
但是，未引用該段落的參考文獻。
對於運營商，他們可能不會選擇與您的內部客戶端相同的外部端口。這打破了TCP和UDP打孔。在這裏看到：
這是可能的，你就不能準確地猜到端口號。你可能會有點失敗，無法建立連接。對於可以在對稱和大規模NAT工作更魯棒的打孔方法，嘗試這些方法之一：
這不適用於真正的4G LTE路由器。 – 2015-09-26 06:56:28
爲什麼3G網絡NAT不能被繞過？
歸結爲統計。爲了建立連接，您必須將數據包發送到他們所在的端口，並且必須將數據包發送到您所在的端口。如果發送到錯誤的端口號或者發送到錯誤的端口號，則會錯過並且沒有建立連接。如果你們兩個同時綁定到一個端口併發送一個指向另一個ip地址的數據包，那麼你有65535中的1（65535是ip地址上的端口數）發送數據包到端口的機會， 65535中大約有1個將數據包發送到您的端口的機會。所以你建立連接的機會是（1/65535）*（1/65535）或（1/65535^2）。
因爲對於每個新的出站連接，路由器會隨機爲您提供一個1024到65535間隔的新端口號，因此無法知道您的端口號。因此，如果您詢問服務器您的ip和端口號是，它可能會告訴你正確的IP（你的IP地址不會經常改變，除非你關掉你的手機或類似的東西），但端口號會改變。如果您嘗試猜測端口號，則會出現（（65535-1024-1）/（65535-1024））或99.998％的更改，您認爲它錯了，假設可以選擇的端口號的數量是（ 65535-1024）。因此，除非端口號碼是可預測的（在很多4G網絡中它們不是），否則你就沒有機會了。
許多運營商正在執行雙NAT。他們有一個靠近塔的「本地」NAT，以及運營商網絡內部的運營商級NAT。越來越難獲得可用的IPv4地址，並且ARIN在今天早些時候完全用完了可用的IPv4地址以分配給運營商。 –
我想我知道你的意思。在我的T-Mobile網絡上，前四個跳都以「10」開頭。那些是靠近塔的「本地」NAT。然後接下來的四跳都以「4」開始。那些是非本地的，但在同一ISP下。之後，出現分歧，其中綁定到不同公有IP地址的數據包採用不同的路徑，並且不共享公共前綴。 – 2015-09-26 06:53:20
很好解釋。 ！ –
我在開發多代理系統的中間件，我們最近必須爲4G/3G網絡上的p2p使用創建一個基於UDP的傳輸選項。我們已經在T Mobile的數據計劃以及NAT背後的各種學術網絡上對此進行了測試，對於目前的實施我感到非常自信。由於這裏似乎沒有解決這個問題的可靠解決方案，所以我想通過REGISTRY_CLIENT傳輸選項來分享我們目前在MADARA中間件（http://madara.sourceforge.net/）中實現的解決方案類型。
對於我們，我們選擇了您可能稱之爲P2P端點的註冊服務器或名稱服務（如果您熟悉CORBA）。註冊表服務器需要運行在UDP可以通過單向消息訪問的公共ip：端口上。對於我們的測試，我們租用了Amazon EC2節點，並確保防火牆設置允許UDP流量通過我們要綁定的UDP端口。在服務器端（註冊服務器的公共IP：端口配對），我們綁定到端口並等待客戶端註冊。任何想要與其他人交談的P2P客戶端向註冊服務器發送註冊表消息
P2P client ----> [register message] ---> Registry Server
註冊消息可以具有任何任意內容。我們的實際上除了來自正常數據協議的消息頭以外沒有內容。在服務器端，我們通過正常的套接字recv調用來檢查註冊消息發送者（P2P客戶端到左上方）的遠程主機。這個遠程主機應該是通過保護P2P客戶端的防火牆的端點信息。
爲了理解這裏發生了什麼，我們必須看看消息如何被路由到P2P客戶端到我們的公共註冊服務器。以下ASCII圖顯示了從P2P客戶端到我們的EC2服務器的路徑中套接字可能看到的遠程信息（即示例防火牆映射）。這隻顯示一個防火牆，但它應該與P2P客戶端和註冊服務器之間的多個NAT一起工作，只要當流量通過該特定NAT的指定ip：端口時，NAT保持公共ip：端口打開。現在
P2P client ----> [message from 192.168.1.10:35000] ---> Firewall ---> [message from 111.111.50.34:5627] --> Registry Server
，如果我們試圖從我們的註冊服務器發送消息給192.168.1.10:35000，它會失敗（或至少，它幾乎肯定會去錯了地方）。同樣，您可以看到4G防火牆也將端口從35000更改爲5627.要將消息發送回P2P客戶端，您需要做兩件事：1）通過111.111.50.34:5627發送返回消息比我們最初綁定到P2P客戶端的任何ip：端口信息，以及2）確保P2P客戶端或註冊服務器經常將數據重新發送給對方 - 每秒一次對於我們永久綁定到公共ip：端口111.111.50.34:5627，在我們的例子中。
作爲我們協議的一部分，我們不只是發送一個無用的數據包回註冊的P2P客戶端。我們發送該客戶端的組/集團/域/任何P2P客戶端的所有相關公共ip：端口配對。基本上，我們發送P2P客戶端發現信息，用於註冊表服務器知道的與P2P客戶端相關的所有內容。
例如，假設兩個P2P客戶端通過111.111.50.34:5627和111.111.37.24:15234 ip：port通過4G提供商的防火牆發送消息給註冊服務器。一種新的P2P客戶端從111.111.70.105:7000連接的，我們在一個簡單的迴應上市背部與其他兩個終點：
[Registry Response for P2P Client #3]
111.111.50.34:5627
111.111.37.24:15234
現在，在P2P客戶端＃3月底，你把這個列表和使用它作爲您的P2P應用程序的潛在端點。這些是你的P2P同行。您可以通過您註冊的相同套接字創建UDP數據包，只要它們不在保守防火牆之後（例如手機上的移動連接熱點，根據我的經驗，傳統上它被設計爲阻止短暫端口上的所有入站UDP流量綁定，沒有配置設置可用於啓用端口轉發），流量應該能夠雙向流動。
如前所述，爲了保持P2P UDP連接的有效性，您基本上只需要定期向/從此端點重新發送數據，以使公用ip：端口綁定在保護P2P客戶端的每個防火牆上保持活動和活動狀態。這可以通過定期向公共註冊服務器重新發送註冊信息和/或從其他P2P客戶端接收UDP數據包到4G防火牆已分配給您的P2P客戶端的公共ip：端口來完成。
是的，他們是！看看我的答案！我在維基百科頁面上回答了兩個參考文獻！ – 2015-08-14 22:28:50
沒關係。早稻田大學的技術可能適用於一些規模較小的對稱路由器（我自己並沒有見過很多），但是我自己實現了它，它不適用於3/4G網絡。 – 2015-09-24 23:34:23