为啥这种方式的 TCP 打孔不起作用?

Posted

技术标签:

【中文标题】为啥这种方式的 TCP 打孔不起作用?【英文标题】:Why TCP hole punching in this way doesn't work?为什么这种方式的 TCP 打孔不起作用? 【发布时间】:2017-04-11 19:30:34 【问题描述】:

我对 NAT 表的理解是

    仅 NAT 表映射(私有 IP:端口)->(公共 IP:端口) 它不关心协议或套接字连接

通过这种方式,我认为可以通过重用本地端口来完成 TCP 打孔。

    在 NAT 之后的主机 A 连接到服务器 S,主机 A 的 NAT 映射它的对

    Host A(192.0.0.1:100)            ->            NAT            ->            Server
                                 (192.0.0.1:100 -> 121.0.0.1:200) MAPPED
    

    主机 A 关闭该套接字并在同一本地端口 (100) 上打开新的侦听套接字

    Host A(listening 192.0.0.1:100)   ->            NAT            ->            Server
                                 (192.0.0.1:100 -> 121.0.0.1:200) MAPPED
    
    然后,我认为任何客户端都可以使用已映射的对 (192.0.0.1:100 -> 121.0.0.1:200) 连接到主机 A(从服务器获取 121.0.0.1:200) 因为 NAT 表只考虑目标 IP 和端口,而不考虑源 IP 和端口。

但这不起作用!我发现了其他复杂的实现,但我很好奇这种方式有什么问题。

【问题讨论】:

欺骗:***.com/questions/26694286/… 【参考方案1】:

好的,如果有人到达这里,请阅读https://en.wikipedia.org/wiki/Network_address_translation中的“翻译方法”部分

【讨论】:

以上是关于为啥这种方式的 TCP 打孔不起作用?的主要内容,如果未能解决你的问题,请参考以下文章

Magento中的打孔不起作用

为啥这种方法不起作用?

为啥 UICollectionView didSelect 方法不起作用?

为啥 Marquee 在小部件中不起作用?

使用 jQuery Mobile 和 jQuery 可排序的第一页加载时触摸打孔不起作用

为啥 selectAnnotation 在这种情况下不起作用?