@wuosuper 你说端口冲突可以通过算法分配，降到一个够低的概率，我信。那我回答所有 SYN 包，怎么办？我通过#99 提出的方案主动探测是否是假 IP ，怎么解决？
更重要的是，既然不遵循标准协议，是不是也应该告诉客户会发生什么，以及这一技术的安全隐患。算法一定是根据开端口的情况的来分配 IP 的，那我换个端口又是首次拨号，攻击面根本没变。

@wuosuper 关于如何发现是假的公网 IP ，不玩投机取巧，我就玩概率。直接扫我所在的网段的所有端口，开了服务的和没开服务的分成两组。然后反复重播反复扫，只要拨到了有服务的 IP 上，就高度怀疑假公网。测试自己拥有这个公网 IP 时有服务 port(s)的情况，再测试自己释放了该 IP 时有服务 port(s)的情况。写脚本反复测上半个月，概率学上可以获得极高置信的结果。如果再对有服务端口做针对性监听，就可以完全确定是否为假公网了。运营商再怎么投机取巧，别人一步一个脚印走路你是拦不住的。

@wuosuper 我都不用管什么机密不机密的，你就告诉我，三个 SSH 开到一个 IP 的 22 上了，你连哪个？我开全端口服务回答所有 SYN 包，你怎么办？其实根本不用问，知道了有这么个玩意，测试一下就知道了。土加密最怕见光，一曝光就死的透透的，这玩意也是一样。你说没有明显差异，完全是因为这个方案足够奇葩，发现问题了也不可能往这上面去想。本质上玩的还是信息差。

@HugeToon 我的意思是你不能主动创造这个攻击条件啊。信道不能保证是否安全和主动去创建一个危险的信道，这是完完全全的两码事。就好比你不能确定你收到的外卖是否有毒，这个风险的确要用户自己承担，但这不代表外卖公司可以给小哥人手发一瓶砒霜。

OPENWRT 的防火墙默认只开了 IPV6 的 ICMP 吧，UDP 和 TCP 都不会发到下面的设备上的。

@xxfye 你要明白，这个不安全的代价不是天然的，而是这个方案引入的。
针对游戏需求，某些地区的移动已经做到了高等级 NAT ；针对外网服务需求，也有端口映射的选择，只是运营商没有动力去做。而且你不能说天气太热，为了凉快我就把内裤都脱了，这已经远远超出"代价"的范畴了。

@luckycatio 而且最关键的是，这个方案有安全隐患的。我的 TCP 连接会被别人抢答，后面的数据就会流过去。如果是例如 SOCKS5 之类的明文，直接用户名密码就发给人家了。这要不是蜜罐还好，大范围部署了有人开蜜罐，怎么搞？你的 SOCKS5 密码给人家了，要是没做好内网隔离，直接在你家内网爆破。还有上面提到的 RST 抢答，怎么搞？还有一大堆你想到没想到的问题，不是你说的这玩意大范围铺开了，大家就都能用上公网 IP 那么理想的。

@luckycatio 说白了就是为了让大家都能过得好，就明里暗里剥夺大家的知情权呗？一个公网 IP 搞得跟国家机密一样，这个逻辑恕我不能认同。

@zanzhz1101 咱别成天投诉率了成么，咱分析下这个方案会给用户带来什么样的影响吧？

@luckycatio 我说句实在话，这种连安全性没有经过系统分析的方案，直接就抬上来给客户用，还不告诉客户，根本就是离大谱，更何况这还是垄断运营商。有些运营商做的 NAT 不标准，为了提高利用率不遵循四次挥手的 TIME-WAIT ，我这儿都已经遇到问题了。你要是搞这个方案，我还不如用标准的 100.64.0.0/10 呢，因为至少我知道发生了什么。

@luckycatio 这个知识不冷我知道，中国几个省，日本某个运营商。这能说明什么，部署范围很广泛么？
你们啊有个毛病，三句话不离投诉率，这是站在用户角度看问题么。要是站在用户角度考虑问题，我会告诉你这种方案玩的就是信息差。那些投诉要公网 IP 的用户，知道了你搞了个假的骗他，大概率继续投诉你。你要不告诉他，让他两眼抹黑，鬼知道连自家 IP 的 SSH 有可能跑到别人家里去，这不是坑人么？

@xxfye 如果你有机会系统学习下计算机知识，然后再来会看你的发言，你就会知道为什么这个方案的问题在哪儿了，在此之前没有人能说的动你。
而且你可以反过来想想，这个方案早就有了，要是真有你说的那么强大，早就和 NAT 一样部署到全球了，它必然是有什么致命的弱点在里面。这个逻辑总能理解吧。

@xxfye 别的不说，这个玩意会以非预期的方式干扰到网络层和传输层，且没有解决方案，就意味着不会成为标准并推广。这种方案还会造成安全隐患，根本就不可能和 NAT 相提并论。 @snw 举了一个非常好的例子，RST 和这个方案只有一个能活，这意味着直接跟 TCP 协议冲突。你倒好直接来了个 NAT+，让人看了就觉得很风趣。
技术上的问题我也不想讨论了，不在一个频道上。另外这个东西根本就不是站在用户角度弄出来的，PPT 里写得一清二楚，什么减少投诉、无感知、显示优秀字样，潜在问题也不告诉客户，出了问题让用户两眼抓瞎，哪个用户愿为它唱赞歌是他的自由，但这事儿我干不出来。

@xxfye 你没有理解计算机网络里的"协商"是什么意思。用户层协议服务端与客户端之间要协商好，网络层协议路由器和路由器之间要协商好。所以 SS 当然是商量好的协议，要不怎么运行得起来。另外独享端口并不一定意味着回收公网 IPV4 ，你能理解伪公网 IP 的运行模式，怎么在这个基础上的独享端口就变成必须回收了呢？
我建议你在了解一件事物之前不要轻易批评它或赞美它，尤其在它是个专业问题的时候。用户想要一个好的结果，没有问题，但你的评论是站在技术的角度来评价的，还给它起了个 NAT+的名字，搞得它好像比 NAT 还牛逼一样。那你就别怪别人怼你技术不行了。

@xxfye 我一点也不清高。只要你提出你的理由，有理有据地反驳我，我就承认我是那个学的不好的。阴阳怪气是一个人最后的保护伞，轻易不要使用。

@xxfye 坚决反对这种做法。网路层 /传输层设备去分析会话、表示、应用层数据，绝对不是一个正常的选择。分层是计算机网络的基础与核心，破坏了这一点会造成很多上层的未定义行为，后患无穷。另外下层协议的正常运行依赖于上层协议的设计，学过计算机网络的都会觉得这极其离谱。
计算机网络的本质是协议。而协议之所以称作协议，核心就是这件事大家要商量好。自己瞎搞出来的一个东西，谁都不告诉，这连协议都不能叫，又怎么能叫做"牛逼"。你可以告诉用户，哪些端口共享哪些端口独享，大多数人根本用不到几万个端口，分上几百个独享端口，剩下的端口做动态映射，比这样瞎 JB 搞要强得多。现在这么搞本质上不是解决问题，而是减少投诉，除此之外没有任何优势。为它洗地的，要我说不是计算机网络没学好，就是利益相关。

@oblivion 歪了就歪了呗？比萨斜塔也没见给拆了啊。

NAT444 这样的公网 IP 是有安全隐患的。
而且 UDP 怎么办？ UDP 无连接，先别说开服务了，两个人打一个游戏，恰好用到同一个客户端口，直接凉凉。