关于运营商分配假公网 IP 的问题

[Marionic0723]

感谢 @onion83 发的图


这种技术多半是是运营商用来应对那些啥都不知道又跟风申请公网 IP 的小白的，用了这招之后，拨号获取到的 IP 和上网查到的的确是同一个，NAT 类型也会测出最宽松，能骗过绝大多数人，只有需要公网开服务而且正好端口和别人冲突的时候才会发现异常。

那么问题来了，如何分辨这种假公网？多用户在同一端口开放服务后，NAT 设备如何处理流量？

我的想法：
1.分别在低位和高位端口开设服务，然后用跨运营商的网络去访问它，查看访问能否成功，如果有不成功的，除了被运营商封锁（如 25 ，80 ，443 ），剩下的端口就是给别人了，证明公网 IP 是共享的。
2.内网发起路由跟踪，看看到达运营商真正的公网网关前是否出现丢包跳数。手机流量一般就是这样，只不过能看出是内网 IP 。
还有什么想法欢迎各位补充。

[Marionic0723]

或者是开放全部端口，然后进行端口扫描？最好跨运营商操作，避免处于同一防火墙规则或者网关之下。
一可看公网是不是真实的，顺便也测试哪些端口是被运营商阻止的了。据我测试，离用户最近的网关是不会丢 80 的包的，因此我可以扫描自己家这一段公网地址上的任意端口而不被运营商丢包，能到达别人的 80 端口。

[100240v]

挖槽，测了下，上海联通 cgn 假公网。上海电信应该真的，还能 rdns ，怪不得联通的公网 ip 那么好申请....

[NXzCH8fP20468ML5]

我猜其实就是 NAT+，只不过传统的 NAT 技术利用四元组原理，这个 NAT 还加上了应用层的特征，比如 FTP ，TLS 等。
想想冲突的可能性，首先要求同一个 IP 的池子里，有两个以上用户打开相同的端口，用相同的协议 /应用处理，才会有冲突。

然后看看如何解决冲突。
在网络层，TCP 本来就会丢掉 SEQ 不对的包，一旦哪方没有 ACK ，后续就能充分利用 srcip 和 src port 四元组进行 NAT ，那么后续 TCP 流就不会丢包多包。UDP 多包漏包在正常不过。
在应用层，TLS 或 QUIC 等加密流，也会丢弃无法加解密的包。即使不加密，一般应用（比如游戏）也会进行鉴权。

这么看来，出现冲突的可能性微乎其微，只觉得想出 NAT4444 这个技术的人真牛逼！我爱这项技术。
不过话说回来，无论如何改善 IPv4 ，都不过是苟延残喘罢了，不如大力推广 IPv6 ，争取 IPv4 早日退网。

[Windn0]

这个技术用户获取的公网 ipv4 ，拥有真正的 ipv4 体验吗？不会吧？换句话说，它不能被当成和服务器一样被外界找到，对吧？

[NXzCH8fP20468ML5]

如果真的考虑到冲突，以后就有两个选择了。

要稳定，不接受一切波动的小白客户，老老实实选择内网 NAT 。
要功能，可以接受概率波动的高级玩家，选择可能冲突的假公网 IP 。

[NXzCH8fP20468ML5]

@Windn0 肯定是可以在外界连上了的，看我上面分析就知道了。
视情况而定，有小概率到微小概率的网络波动。

[LnTrx]

关键看是什么需要吧？低位端口本来就是封的，高位端口如果外网主动访问正常，很多人也不会在意。

[Marionic0723]

@100240v 天津联通默认给公网 IP ，不过同一时刻并发拨号，拨到的 IP 能差五六百个，估计是很紧张，我实测远程桌面啥的正常，路由跟踪也没多余的跳数，不知道是不是假公网。

@xxfye 但是真的出问题了绝大部分人都不会往公网 IP 的真假上想，更何况这个几乎天衣无缝。
话说以后会变成纯 v6 吗？我觉得 v4 始终不会淘汰，因为一大优势就是手打方便而且略微好记一点……就比如 1.1.1.1 ，shua 一下打完了，v6 还要按 shift 输入 2606:4700:4700::1111……

@Windn0 可能会分一部分独享的端口给客户，其他的共享转化出去。主要看客户需求了，小白当然不会远程访问，所以可以默认给“公网”，就是完全不能被外界访问，公网私用。

[my2492]

tracert 试试看，国内运营商中间节点一般不用内网 ip

[my2492]

假公网应该是比较少见的，发达地区 ip 就不缺啊，其他地区打死不给公网

[cnbatch]

造成冲突的可能性，对某些应用来说还是比较高的，例如 RDP 的 3389 ，还有 SSH 的 22 。

开启 Windows 的远程桌面其实一点都不罕见，对于部分非小白用户来说，公网 IP 有一个很重要的用途就是 RDP 。
很久以前我试过用 tcping 简单扫描我用着的 IP 的 /24 网段，发现开启 3389 的机器还真不少，有时能找到十几个。
用远程桌面连过去，确实能够连得上，有一些甚至是 Windows Server 。

万一同一个假公网 IP 后方刚好有两人甚至更多人开启了 3389 ，那就一定会造成冲突，而且很容易就被发现。包括 3390 也有可能会冲突，有些人会用端口映射把 3390 映射到另一台 Windows 的 3389 。

SSH 同理，基于 BSD 的或者 Linux 的设备（主要是软路由，还有一部分高端路由器）自带 SSH 服务，部分使用者会把 SSH 暴露到公网。

从理论上来说，VNC 其实也会有同样的冲突，只不过使用 VNC 的机器应该没 RDP 和 SSH 那么多。


除非 NAT4444 的那套设备能够针对性处理，发现有人开启了 SSH 、RDP 、VNC 就单独让这个人使用单独分配的公网 IP 。只有这样才能避免冲突。

[mikewang]

没有用过 NAT4444 ，但是可以推测出这种方案是无法接受传入连接的。
假公网是两层 Fullcone NAT ，然而 Fullcone NAT 本身没有要求转换前后端口号一致。
假公网内外 IP 显示一致，所以可以推测出可能是这样的方案：
　　用户 1-5 ，共用 IP 123.45.67.89：
　　　　用户 1 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:10000-19999 ）
　　　　用户 2 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:20000-29999 ）
　　　　用户 3 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:30000-39999 ）
　　　　用户 4 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:40000-49999 ）
　　　　用户 5 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:50000-59999 ）

映射方法应该和普通的 NAT 类似，只不过进出都是同一个 IP ，并且不能接受传入（无法从外部映射回去）

[cnbatch]

甚至会不会有这种可能：

当客户发现并确认公网 IP 无法接受传入连接，或者发现 RDP 、SSH 连接到的并不是自己的机器，于是再打电话询问运营商客服时，运营商才真正将该客户分配到真·公网 IP 的池子中。

[joynvda]

通过外网把一些端口抢占了，是否可以解决问题？

用不了那么多的端口，预留 100 个够了吧。

[mikewang]

我觉得大家缺的不是公网 IP ，而是开放端口。
假如运营商全程 NAT1 ，并且提供端口映射服务，可以解决 99% 的问题并且节省公网 IPv4 。

[duke807]

@Marionic0723 #8

不管 v6 地址输入有多麻烦，v6 + v4 只会更麻烦，所以不如只用 v6 单栈

至于地址，我司的局域网产品，v4 地址是：
192.168.44.1 和 192.168.88.1
对应的 v6 地址是：
fd44::1 和 fd88::1
即便加上中括号：
[fd44::1] 和 [fd88::1]
也是 v6 地址更短

[onion83]

首先声明这也是网图，本人也非业内人士，不要找我喝茶：）

其次 NAT4444 其实已经是很早前的技术了，我记得以前 10 年前北京的宽带通，长城宽带也会分配一个公网 IP ，但是各省、各运营上出口的 IP 都是不一样的，mtr 第三跳就是内网了...

上图所提到的方案 “2 、 采用端口组固定分配模式的 CGNAT” 其实已经说明方案的要点了：

假设可用端口数为 65533 ，减去系统保留端口 （ 65533-1024 ）/ 14 ~= 4607 端口 /每用户，单用户并发连接数 4K 基本是够用的，这篇文章： https://www.codeprj.com/zh/blog/93fc4f1.html 也说得很清楚。

如果做 1:1 的 FullClone 我估计就要碰运气了，先来先得，但是不排除运营商使用比较聪明的智能端口分配技术，但是如何能做到公网环境下的 upnp 、智能打洞、端口分配时长管理、心跳保活可能就是核心机密了。有网友反馈要了公网 IP 也无法访问自己的机器，我估计和此有关。

另外，运营商也没承诺你一定可以对外提供服务。更多人的应用场景可能只是为了下载能拿到 hightID ，upnp 过检、NatTypeTester 显示 Fullclone 而已，再投诉的话下发一个策略帮你放到 1:1 的地址池搞定，但是毕竟很少数。

[Tianao]

@mikewang #15 说到点子上了，可惜运营商不想趟这浑水。

[NXzCH8fP20468ML5]

@cnbatch
@mikewang
tcp 入站不会有问题的，你看我上面分析，系统会丢掉 seq 不正确的包，seq 都是随机生成的，范围太广了，根本撞不上，一旦有正确响应的 ack ，就能根据对应的 src ip 和 src port 建立稳定的 tcp 连接。
如果真的冲突了，大多数应用会自动重试，撞上概率就更小了。

[Kowloon]

@onion83
鹏博士是因为出口不够多，所以有流量穿透，实际分配的确实是公网 IP 只不过从鹏博士访问异网大概率会走穿透。