这是一个创建于 843 天前的主题，其中的信息可能已经有所发展或是发生改变。
感谢 @onion83 发的图
这种技术多半是是运营商用来应对那些啥都不知道又跟风申请公网 IP 的小白的，用了这招之后，拨号获取到的 IP 和上网查到的的确是同一个，NAT 类型也会测出最宽松，能骗过绝大多数人，只有需要公网开服务而且正好端口和别人冲突的时候才会发现异常。
那么问题来了，如何分辨这种假公网？多用户在同一端口开放服务后，NAT 设备如何处理流量？
我的想法：
1.分别在低位和高位端口开设服务，然后用跨运营商的网络去访问它，查看访问能否成功，如果有不成功的，除了被运营商封锁（如 25 ，80 ，443 ），剩下的端口就是给别人了，证明公网 IP 是共享的。
2.内网发起路由跟踪，看看到达运营商真正的公网网关前是否出现丢包跳数。手机流量一般就是这样，只不过能看出是内网 IP 。
还有什么想法欢迎各位补充。
这种技术多半是是运营商用来应对那些啥都不知道又跟风申请公网 IP 的小白的，用了这招之后，拨号获取到的 IP 和上网查到的的确是同一个，NAT 类型也会测出最宽松，能骗过绝大多数人，只有需要公网开服务而且正好端口和别人冲突的时候才会发现异常。
那么问题来了，如何分辨这种假公网？多用户在同一端口开放服务后，NAT 设备如何处理流量？
我的想法：
1.分别在低位和高位端口开设服务，然后用跨运营商的网络去访问它，查看访问能否成功，如果有不成功的，除了被运营商封锁（如 25 ，80 ，443 ），剩下的端口就是给别人了，证明公网 IP 是共享的。
2.内网发起路由跟踪，看看到达运营商真正的公网网关前是否出现丢包跳数。手机流量一般就是这样，只不过能看出是内网 IP 。
还有什么想法欢迎各位补充。
第 1 条附言 · 2022-08-28 10:02:02 +08:00
简单看了下各位的讨论，我觉得：
1.这个方案分配到的公共 IP 地址（请注意“公共”和“公网”的区别）其实称作“共享公网”更恰当（可惜标题不能改），因为它确实支持有限度的从外部访问（除非运营商还有一套方案，公网私用而且来骗小白，也就是完全不支持外部访问，也就是加强版的 100.64.0.0/10 ），路由器 WAN 口和上网查到的是同个 IP ，NAT 类型也是 A/宽松 /优秀，只不过同一时刻别人也在用。
2.如果真的是共享公网地址，那就必然会提到外部访问，而共享的肯定会冲突。虽然各位提到很多避免冲突的问题，撞协议其实在某些时候并不是少数。如 SSH 、RDP 和 VNC 。我举个例子，有人发现自己是 100.64 ，然后申请公网，一开始运营商二话不说给了这种共享公网，客户一时间根本看不出异常，除非要外部访问时，那才会发现——SSH 密钥不通过、RDP 登录死活是密码错误，或者 NAT 网关丢包。有点电脑操作水平的话会继续排查，很快就会发现连的是别人的机器（或者是机器始终没有收到请求），继而马上知道这个公网是假的 /被共享过的，然后再向运营商投诉时，才会被分配到独享全端口（除 80 等）的，广义上的「公网 IP 」。
3.我同意 @mikewang 的观点，大家缺的可能就是开放端口。很多地方即使是内网，NAT 类型也是 A ，如果一部分人有外部访问的需求，申请公网 IP 的步骤就换成申请开放端口，路由器啥的 DDNS 靠检测网页上返回的 IP 而不是接口 IP 来更新，然后在这个公共 IP 上分配 100 个独享端口啥的，这样的话就能解决不少问题。我自己也有公网，但是常用到的端口也就那么十几个。
目前尚未得知这套方案是否已经大范围部署，也不知道冲突时运营商的网关是怎么处理的，就比如 @cnbatch 的假设：“假设某个假公网（假设是 123.45.67.89 ）后面有 3 个 3389 （都是 Windows 远程桌面），那么外界某台机器发起请求，连接到 123.45.67.89:3389 的时候，应该连后面的哪台机器？”
不过运营商狡猾得很，干出啥都不奇怪。我家前几天免费升级电信千兆，装好了公网掉了，去测速，选了个美国洛杉矶的服务器，电信出国慢是众所周知的，结果也给我跑了 900 多 Mbps ，Speed test 延迟也是 170 左右，看上去没问题，而打开资源监视器一看，发现测速 IP 全是天津电信机房，估计是劫持 DNS 吧，真的闸总。第一时间确实把我骗过了，随后马上想到电信出国不可能这么快，于是才发现异常。但凡它装的像一点，装模作样跑个 200M ，我都不会去怀疑了。
1.这个方案分配到的公共 IP 地址（请注意“公共”和“公网”的区别）其实称作“共享公网”更恰当（可惜标题不能改），因为它确实支持有限度的从外部访问（除非运营商还有一套方案，公网私用而且来骗小白，也就是完全不支持外部访问，也就是加强版的 100.64.0.0/10 ），路由器 WAN 口和上网查到的是同个 IP ，NAT 类型也是 A/宽松 /优秀，只不过同一时刻别人也在用。
2.如果真的是共享公网地址，那就必然会提到外部访问，而共享的肯定会冲突。虽然各位提到很多避免冲突的问题，撞协议其实在某些时候并不是少数。如 SSH 、RDP 和 VNC 。我举个例子，有人发现自己是 100.64 ，然后申请公网，一开始运营商二话不说给了这种共享公网，客户一时间根本看不出异常，除非要外部访问时，那才会发现——SSH 密钥不通过、RDP 登录死活是密码错误，或者 NAT 网关丢包。有点电脑操作水平的话会继续排查，很快就会发现连的是别人的机器（或者是机器始终没有收到请求），继而马上知道这个公网是假的 /被共享过的，然后再向运营商投诉时，才会被分配到独享全端口（除 80 等）的，广义上的「公网 IP 」。
3.我同意 @mikewang 的观点，大家缺的可能就是开放端口。很多地方即使是内网，NAT 类型也是 A ，如果一部分人有外部访问的需求，申请公网 IP 的步骤就换成申请开放端口，路由器啥的 DDNS 靠检测网页上返回的 IP 而不是接口 IP 来更新，然后在这个公共 IP 上分配 100 个独享端口啥的，这样的话就能解决不少问题。我自己也有公网，但是常用到的端口也就那么十几个。
目前尚未得知这套方案是否已经大范围部署，也不知道冲突时运营商的网关是怎么处理的，就比如 @cnbatch 的假设：“假设某个假公网（假设是 123.45.67.89 ）后面有 3 个 3389 （都是 Windows 远程桌面），那么外界某台机器发起请求，连接到 123.45.67.89:3389 的时候，应该连后面的哪台机器？”
不过运营商狡猾得很，干出啥都不奇怪。我家前几天免费升级电信千兆，装好了公网掉了，去测速，选了个美国洛杉矶的服务器，电信出国慢是众所周知的，结果也给我跑了 900 多 Mbps ，Speed test 延迟也是 170 左右，看上去没问题，而打开资源监视器一看，发现测速 IP 全是天津电信机房，估计是劫持 DNS 吧，真的闸总。第一时间确实把我骗过了，随后马上想到电信出国不可能这么快，于是才发现异常。但凡它装的像一点，装模作样跑个 200M ，我都不会去怀疑了。
第 2 条附言 · 2022-08-29 10:38:55 +08:00
补充说明：
据说这套方案早已经部署了，如果不是这张图，可能没人能发现，怪不得会出现“有时候连不上，过一会又好了”的灵异现象。
wuosuper 说：“至于探测，老用户是没法探测的，只有新装宽带的用户在前一周内可以探测，并且经过多年迭代体验与真实 IP 无异。厂商并不想推这项技术，是某地运营商要他们做的，后来被各地运营商看中，并且已经已经部署了 40+城市。”
假到足够以假乱真时，是不是就可以把它当成残血的正牌货了？
据说这套方案早已经部署了，如果不是这张图，可能没人能发现，怪不得会出现“有时候连不上，过一会又好了”的灵异现象。
wuosuper 说：“至于探测，老用户是没法探测的，只有新装宽带的用户在前一周内可以探测，并且经过多年迭代体验与真实 IP 无异。厂商并不想推这项技术，是某地运营商要他们做的，后来被各地运营商看中，并且已经已经部署了 40+城市。”
假到足够以假乱真时，是不是就可以把它当成残血的正牌货了？
 |
1
Marionic0723 OP 或者是开放全部端口，然后进行端口扫描？最好跨运营商操作，避免处于同一防火墙规则或者网关之下。
一可看公网是不是真实的，顺便也测试哪些端口是被运营商阻止的了。据我测试，离用户最近的网关是不会丢 80 的包的，因此我可以扫描自己家这一段公网地址上的任意端口而不被运营商丢包，能到达别人的 80 端口。 |
 |
2
100240v 2022-08-27 21:18:28 +08:00
挖槽，测了下，上海联通 cgn 假公网。上海电信应该真的，还能 rdns ，怪不得联通的公网 ip 那么好申请....
|
 |
3
NXzCH8fP20468ML5 2022-08-27 21:28:42 +08:00  11
我猜其实就是 NAT+，只不过传统的 NAT 技术利用四元组原理，这个 NAT 还加上了应用层的特征，比如 FTP ，TLS 等。
想想冲突的可能性，首先要求同一个 IP 的池子里，有两个以上用户打开相同的端口，用相同的协议 /应用处理，才会有冲突。 然后看看如何解决冲突。 在网络层，TCP 本来就会丢掉 SEQ 不对的包，一旦哪方没有 ACK ，后续就能充分利用 srcip 和 src port 四元组进行 NAT ，那么后续 TCP 流就不会丢包多包。UDP 多包漏包在正常不过。 在应用层，TLS 或 QUIC 等加密流，也会丢弃无法加解密的包。即使不加密，一般应用（比如游戏）也会进行鉴权。 这么看来，出现冲突的可能性微乎其微，只觉得想出 NAT4444 这个技术的人真牛逼！我爱这项技术。 不过话说回来，无论如何改善 IPv4 ，都不过是苟延残喘罢了，不如大力推广 IPv6 ，争取 IPv4 早日退网。 |
 |
4
Windn0 2022-08-27 21:34:30 +08:00 via iPhone
这个技术用户获取的公网 ipv4 ，拥有真正的 ipv4 体验吗？不会吧？换句话说，它不能被当成和服务器一样被外界找到，对吧？
|
|
5
NXzCH8fP20468ML5 2022-08-27 21:38:16 +08:00 1
如果真的考虑到冲突，以后就有两个选择了。
要稳定，不接受一切波动的小白客户，老老实实选择内网 NAT 。 要功能，可以接受概率波动的高级玩家，选择可能冲突的假公网 IP 。 |
|
6
NXzCH8fP20468ML5 2022-08-27 21:39:57 +08:00
@Windn0 肯定是可以在外界连上了的，看我上面分析就知道了。
视情况而定，有小概率到微小概率的网络波动。 |
 |
7
LnTrx 2022-08-27 21:40:25 +08:00
关键看是什么需要吧？低位端口本来就是封的，高位端口如果外网主动访问正常，很多人也不会在意。
|
|
8
Marionic0723 OP @100240v 天津联通默认给公网 IP ，不过同一时刻并发拨号，拨到的 IP 能差五六百个，估计是很紧张，我实测远程桌面啥的正常，路由跟踪也没多余的跳数，不知道是不是假公网。
@xxfye 但是真的出问题了绝大部分人都不会往公网 IP 的真假上想，更何况这个几乎天衣无缝。 话说以后会变成纯 v6 吗？我觉得 v4 始终不会淘汰，因为一大优势就是手打方便而且略微好记一点……就比如 1.1.1.1 ，shua 一下打完了，v6 还要按 shift 输入 2606:4700:4700::1111…… @Windn0 可能会分一部分独享的端口给客户，其他的共享转化出去。主要看客户需求了，小白当然不会远程访问，所以可以默认给“公网”，就是完全不能被外界访问，公网私用。 |
 |
9
my2492 2022-08-27 22:21:12 +08:00 via iPhone
tracert 试试看，国内运营商中间节点一般不用内网 ip
|
|
10
my2492 2022-08-27 22:23:26 +08:00 via iPhone
假公网应该是比较少见的，发达地区 ip 就不缺啊，其他地区打死不给公网
|
 |
11
cnbatch 2022-08-27 23:16:30 +08:00 2
造成冲突的可能性，对某些应用来说还是比较高的，例如 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 。只有这样才能避免冲突。 |
 |
12
mikewang 2022-08-27 23:27:29 +08:00
没有用过 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 ，并且不能接受传入（无法从外部映射回去） |
|
13
cnbatch 2022-08-27 23:34:15 +08:00
甚至会不会有这种可能：
当客户发现并确认公网 IP 无法接受传入连接，或者发现 RDP 、SSH 连接到的并不是自己的机器，于是再打电话询问运营商客服时，运营商才真正将该客户分配到真·公网 IP 的池子中。 |
 |
14
joynvda 2022-08-27 23:36:35 +08:00
通过外网把一些端口抢占了，是否可以解决问题？
用不了那么多的端口，预留 100 个够了吧。 |
|
15
mikewang 2022-08-27 23:37:50 +08:00 23
我觉得大家缺的不是公网 IP ，而是开放端口。
假如运营商全程 NAT1 ，并且提供端口映射服务，可以解决 99% 的问题并且节省公网 IPv4 。 |
 |
16
duke807 2022-08-27 23:56:41 +08:00 via Android
@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 地址更短 |
 |
17
onion83 2022-08-28 00:01:37 +08:00
首先声明这也是网图，本人也非业内人士，不要找我喝茶：）
其次 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 的地址池搞定，但是毕竟很少数。 |
|
19
NXzCH8fP20468ML5 2022-08-28 00:18:37 +08:00 via Android 1
|
 |
20
Kowloon 2022-08-28 00:22:41 +08:00 via iPhone
@onion83
鹏博士是因为出口不够多，所以有流量穿透，实际分配的确实是公网 IP 只不过从鹏博士访问异网大概率会走穿透。 |
|
21
mikewang 2022-08-28 00:24:18 +08:00
|
|
22
cnbatch 2022-08-28 00:25:10 +08:00
@xxfye 那就来个现实的假设。
假设某个假公网（假设是 123.45.67.89 ）后面有 3 个 3389 （都是 Windows 远程桌面），那么外界某台机器发起请求，连接到 123.45.67.89:3389 的时候，应该连后面的哪台机器？ |
|
23
NXzCH8fP20468ML5 2022-08-28 00:29:06 +08:00 via Android
@mikewang 你说的运营商开放端口映射，据我所知移动已经在搞了，针对物联网，但目前不对个人用户开放。
比如说 A 买了 B 公司的产品 C ，C 连接上互联网后，B 会向移动申请开放 A 家出口 IP 的某个端口，所有入站的该端口的流量都会转发到 A 私网地址，同时 C 会在 A 的光猫上用 upnp 打通一个端口接受入站。这样 C 就能完整接受入站连接了。 |
|
24
NXzCH8fP20468ML5 2022-08-28 00:32:32 +08:00 via Android
|
 |
25
wuosuper 2022-08-28 00:43:06 +08:00 via Android
|
|
27
NXzCH8fP20468ML5 2022-08-28 00:46:32 +08:00 via Android
|
|
28
wuosuper 2022-08-28 00:52:35 +08:00 via Android 1
@xxfye 文档中：源 IP 地址 /目的 IP 地址 /源端口 /目的端口 /传输层协议 /L4 、L7 、传输内容或协议 /来源、响应端口标识号、用户标识号、连接标识号
|
 |
29
cocomaster 2022-08-28 00:54:46 +08:00
如果入站连接正常，对于目前没有公网 IP 的宽带来说倒是好事？
获得了"假"公网 IP ，起码能从外面访问家里的机器了，从无到有的提升。3389 冲突我换一个别的就行了 |
|
30
wuosuper 2022-08-28 00:57:07 +08:00 via Android
@cbatch 根据运营商的实际统计，每一组用户里面有开端口需求的用户每 10 个里面平均 1.5 个，所以运营商会记录下有频繁固定端口入向连接的用户做标记，均匀的分到每个池里面，保障这个平均数，比如让两个有开端口访问标记的用户与 8 个从未开端口的用户共享同一个池，即使后期普遍开放端口，也可以按照每个用户开的端口号不同分配不同的地址池，所以冲突的概率是低上加地，实在倒霉遇到冲突了，运营商也只会让你重启光猫，换一个 IP 就通了。
|
|
31
NXzCH8fP20468ML5 2022-08-28 01:02:35 +08:00 via Android
@wuosuper 看起来真的是利用某些应用层特征进行 NAT ，能透漏那家的设备吗，某兴还是某为？
感觉通信行业真是能人辈出，属实是针尖雕花了。 |
 |
32
wwbfred 2022-08-28 01:25:00 +08:00 23
@xxfye 坚决反对这种做法。网路层 /传输层设备去分析会话、表示、应用层数据，绝对不是一个正常的选择。分层是计算机网络的基础与核心，破坏了这一点会造成很多上层的未定义行为，后患无穷。另外下层协议的正常运行依赖于上层协议的设计，学过计算机网络的都会觉得这极其离谱。
计算机网络的本质是协议。而协议之所以称作协议，核心就是这件事大家要商量好。自己瞎搞出来的一个东西，谁都不告诉，这连协议都不能叫，又怎么能叫做"牛逼"。你可以告诉用户，哪些端口共享哪些端口独享，大多数人根本用不到几万个端口，分上几百个独享端口，剩下的端口做动态映射，比这样瞎 JB 搞要强得多。现在这么搞本质上不是解决问题，而是减少投诉，除此之外没有任何优势。为它洗地的，要我说不是计算机网络没学好，就是利益相关。 |
|
33
NXzCH8fP20468ML5 2022-08-28 01:39:42 +08:00 via Android
|
 |
34
52acca 2022-08-28 01:40:50 +08:00 via Android
刚测试一下自己的发现端口不通，惊呼自己也被骗了，后来才发现是 ddns 没更新，虚惊一场
|
|
35
wwbfred 2022-08-28 02:01:08 +08:00 12
@xxfye 我一点也不清高。只要你提出你的理由，有理有据地反驳我，我就承认我是那个学的不好的。阴阳怪气是一个人最后的保护伞，轻易不要使用。
|
 |
37
snw 2022-08-28 02:19:14 +08:00 via Android 4
鉴于外网连入是向内网广播的，你可以考虑监听所有端口，然后把所有目的地不是你使用的端口的包全都回 RESET ，看邻居会不会跳起来🐶
|
|
38
NXzCH8fP20468ML5 2022-08-28 02:33:54 +08:00 via Android 2
@wwbfred 别的不说，上来就扣帽子说利益相关和洗地，到底谁先开始阴阳怪气的？
况且这项技术就是牛逼啊，在我眼里，这和 ss 之类技术没什么不同。 但 gfw 越来越高时，有人发明了 ss ，大家称一句牛逼很正常。 那么当用户不满意时，运营商搞这一套技术可能解决大量问题，怎么就不能称一句牛逼了。 难道 SS 就是“商量好”的协议吗。 另外你的想法并不好，分配几百个独享端口就意味要收回公网 ipv4 ，怎么解决用户的投诉，怎么扭转用户的思维？谁来教他们配置指定范围的端口映射？ 我是数学出身的金融从业人员，计算机网络确实不太行，上面讨论也可以看出我确实犯了些基本错误。 但我很了解用户是什么，用户的要求比什么都重要，但很多时候只想要一个结果，并不在乎过程是什么。 |
|
39
wwbfred 2022-08-28 03:03:07 +08:00 3
@xxfye 你没有理解计算机网络里的"协商"是什么意思。用户层协议服务端与客户端之间要协商好，网络层协议路由器和路由器之间要协商好。所以 SS 当然是商量好的协议，要不怎么运行得起来。另外独享端口并不一定意味着回收公网 IPV4 ，你能理解伪公网 IP 的运行模式，怎么在这个基础上的独享端口就变成必须回收了呢？
我建议你在了解一件事物之前不要轻易批评它或赞美它，尤其在它是个专业问题的时候。用户想要一个好的结果，没有问题，但你的评论是站在技术的角度来评价的，还给它起了个 NAT+的名字，搞得它好像比 NAT 还牛逼一样。那你就别怪别人怼你技术不行了。 |
 |
40
QwQmoe 2022-08-28 04:54:54 +08:00 via Android 1
我们或许可以用 ping 回复的数据包进行感知。据我个人猜测，大部分人没有关闭路由器上的 ping 回复。而 NAT4444 是如何处理 ICMP Ping 数据包的？如果映射至内网中的所有主机，并保留所有来自主机的回复，那么 ping 客户端会有多包回复的提示。（前提是 ping 客户端不是 Windows ，Windows 会丢弃掉多包）那么是否是随机映射到内网中的一台主机？又或者是 CGNAT 网关自己做回复？通过在被分配了假公网 IP 的路由器上不断的修改 icmp 回复的 TTL ，用跨运营商的网络多 ping 几次，或许能找到些许猫腻。
|
|
41
NXzCH8fP20468ML5 2022-08-28 05:55:55 +08:00 via Android 1
@wwbfred
谁告诉你 NAT+是比 NAT 牛逼的意思？这完全是你自己脑补的东西。这里的+仅仅是意味着在 NAT 四元组基础上添加其他特征，比如后面所说的七元组。 我考虑问题并不是站在技术角度思考和评价的，而是基于现实思考和评价的。 我认为这组技术牛逼之处不在于和 NAT 比较到底谁更好用的问题。在于切实解决了现实问题--当公网 ipv4 紧缺时，运营商面临大量客户投诉，运营商应该如何解决。 我也深思熟虑过这个问题，得到唯一的解决方法就是全面转型 ipv6 ，所以我多次在 v2 呼吁应尽快淘汰 ipv4 。当我得知这种方法还能再续命一波 ipv4 ，震撼感让足矣让我喊出牛逼俩个字。 记住，这个牛逼不是比 NAT 更好，而是它在我的思维框架内打破传统思路，并且能切实解决现实问题。 所以我说你清高一点问题都没有，站在技术的高处指指点点，丝毫不顾及现实情况。（当然我原本希望的纯 ipv6 也是很清高） 回到你提出的技术在现实里的情况。如果你的意思是说，给每个用户分配部分的公网 ipv4 端口。 那么你让本来有完整的公网 ipv4 的用户怎么想，又让本来准备杠客服拿公网 ipv4 的人怎么想。 告诉他们：“抱歉，原本你完整的公网 ipv4 已经是共享的啦”（这就是运营商回收并重分配的过程），或者告诉他们：“抱歉，现在我们只能提供半残的公网 ipv4”。 你觉得用户能接受吗？ 不，这些用户都不能接受，得到的投诉数量只会更多。甚至不如某些地区一刀切，只允许私网地址，以绝用户幻想。 另外，你凭什么说 NAT4444 没有“协商”？ 如果说没协商是没有通知用户就部署，那么部署 SS 时候也没有通知运营商吧？ 如果说没协商是网络层设备越权插手应用层，抱歉，早有案例了，最常见的就是带探测的应用规则防火墙和负载均衡网关。只不过用在 NAT 上我还是第一次见，真是震惊到我了。 |
|
42
wwbfred 2022-08-28 07:04:33 +08:00 12
|
|
43
wwbfred 2022-08-28 07:11:53 +08:00 3
@xxfye 如果你有机会系统学习下计算机知识，然后再来会看你的发言，你就会知道为什么这个方案的问题在哪儿了，在此之前没有人能说的动你。
而且你可以反过来想想，这个方案早就有了，要是真有你说的那么强大，早就和 NAT 一样部署到全球了，它必然是有什么致命的弱点在里面。这个逻辑总能理解吧。 |
 |
44
luckycatio 2022-08-28 07:13:03 +08:00 via iPhone
既然自己平时感觉不到，又何必去纠结自己是不是假公网 ip ，遇到相关问题再投诉呗。
|
|
45
luckycatio 2022-08-28 07:25:28 +08:00 via iPhone
@wwbfred 冷知识，日本也部署了 nat444 ，一个很简单的逻辑，用户觉得网络有问题就会去投诉，不管是自己路由器接错了，还是账号密码输错了，只要上不了网，到达不了自己的预期就会去投诉，降低投诉率的直接体现就是用户都满意了。要是没 nat444 ，公网 ip 肯定是不够用的，运营商为了避免某些用户拿到 ip 对外大肆宣扬，提高投诉率，估计会一刀切，禁止向所有民用宽带提供公网 ip ，到时候大家都只能用反代
|
|
46
luckycatio 2022-08-28 07:40:44 +08:00 via iPhone
@luckycatio 我的问题，日本部署的是 nat444 ，和文中提到的不同
|
|
47
wwbfred 2022-08-28 07:45:10 +08:00 5
@luckycatio 这个知识不冷我知道，中国几个省，日本某个运营商。这能说明什么，部署范围很广泛么？
你们啊有个毛病，三句话不离投诉率，这是站在用户角度看问题么。要是站在用户角度考虑问题，我会告诉你这种方案玩的就是信息差。那些投诉要公网 IP 的用户，知道了你搞了个假的骗他，大概率继续投诉你。你要不告诉他，让他两眼抹黑，鬼知道连自家 IP 的 SSH 有可能跑到别人家里去，这不是坑人么？ |
|
48
luckycatio 2022-08-28 07:56:53 +08:00 via iPhone
@wwbfred 提供公网 ip 并没有写在你和运营商的合同里，当然可以继续投诉啊，最坏的结果运营商出公告明确不受理公网 ip 业务，然后大家都没得用，ssh 连不上就投诉呗，之前说过，用户家里耗子把网线咬断上不了网都要运营商去处理，这是听群里某个运维说的，同端口应用发生冲突导致是运营商改操心的问题，用户遇到问题直接投诉就好了，剩下的让运营商那边去排查。
|
 |
49
zanzhz1101 2022-08-28 08:02:31 +08:00
@wwbfred 事是这么个事，问题也确实是这么个问题， 能降低投诉率为什么不做呢，不过现在基本开始向 ipoe 发展了，同样是降低投诉率的好办法
|
|
50
luckycatio 2022-08-28 08:03:36 +08:00 via iPhone
@wwbfred 已知运营商公网 ip 不多，需要公网 ip 的用户太多，你觉得这个问题可以用用什么技术解决？现在这个方案已经让用假公网 ip 的用户大部分都满意了，甚至没之前那个帖子，这个比普通用户需求更多的论坛网友都没发现。
|
|
51
wwbfred 2022-08-28 08:05:44 +08:00
@luckycatio 我说句实在话，这种连安全性没有经过系统分析的方案，直接就抬上来给客户用，还不告诉客户，根本就是离大谱，更何况这还是垄断运营商。有些运营商做的 NAT 不标准，为了提高利用率不遵循四次挥手的 TIME-WAIT ，我这儿都已经遇到问题了。你要是搞这个方案，我还不如用标准的 100.64.0.0/10 呢，因为至少我知道发生了什么。
|
|
52
wwbfred 2022-08-28 08:09:14 +08:00
@zanzhz1101 咱别成天投诉率了成么，咱分析下这个方案会给用户带来什么样的影响吧？
|
|
53
luckycatio 2022-08-28 08:15:22 +08:00 via iPhone
@wwbfred 用 100.64.0.0 我不乐意啊，现在这个已经可以满足包括我在内的大部分人的需求，不用再特地整个服务器做反代，我在这件事上支持运营商是因为假公网 ip 要是再有哪个博主到处宣传，呼吁大家去投诉，最后的结果显而易见是大家都没公网 ip 用。在没有一个所谓的能完美解决问题的技术出现前，留给运营商的路显然只有一条切都禁用
|
|
54
wwbfred 2022-08-28 08:18:05 +08:00 2
@luckycatio 说白了就是为了让大家都能过得好，就明里暗里剥夺大家的知情权呗？一个公网 IP 搞得跟国家机密一样，这个逻辑恕我不能认同。
|
|
55
wwbfred 2022-08-28 08:28:17 +08:00 6
@luckycatio 而且最关键的是，这个方案有安全隐患的。我的 TCP 连接会被别人抢答，后面的数据就会流过去。如果是例如 SOCKS5 之类的明文，直接用户名密码就发给人家了。这要不是蜜罐还好，大范围部署了有人开蜜罐，怎么搞？你的 SOCKS5 密码给人家了，要是没做好内网隔离，直接在你家内网爆破。还有上面提到的 RST 抢答，怎么搞？还有一大堆你想到没想到的问题，不是你说的这玩意大范围铺开了，大家就都能用上公网 IP 那么理想的。
|
|
56
NXzCH8fP20468ML5 2022-08-28 09:13:07 +08:00 via Android
|
|
57
Marionic0723 OP 我…一觉醒来 70 条回复，原来是吵起来了…待会在慢慢回复，昨天看几位大佬的观点也给了我一点新的想法。
|
|
58
NXzCH8fP20468ML5 2022-08-28 09:20:05 +08:00 via Android
@wwbfred 行啊，你不想要投诉率，只要你能让工信部用不用投诉率考核运营商，你说任何都成立。
|
|
59
wwbfred 2022-08-28 09:21:46 +08:00 9
@xxfye 你要明白，这个不安全的代价不是天然的，而是这个方案引入的。
针对游戏需求，某些地区的移动已经做到了高等级 NAT ；针对外网服务需求，也有端口映射的选择，只是运营商没有动力去做。而且你不能说天气太热，为了凉快我就把内裤都脱了，这已经远远超出"代价"的范畴了。 |
 |
61
Damn 2022-08-28 09:28:50 +08:00
有个疑问，查水表的时候怎么分辨到底是哪个客户？
七元组的信息长期记录？ |
 |
62
Zy143L 2022-08-28 09:35:37 +08:00 via Android
个人认为这是不错的技术
有效复用公网 IP 资源 大部分人用公网 IP 只是需要对外监听端口 低位固定端口 往往都是封禁的 高位基本都是随机的 大家都有的用 |
 |
64
guazila 2022-08-28 09:48:53 +08:00 via Android
ipv4 地址既然现在这么稀缺，运营商为什么不单独为 ipv4 地址出个包，一个月收 10 块钱。我觉得无非是国内的市场和商业环境被运营商给做烂了，怪不了用户。另外，小白用户既然花了一样多的钱，不管有什么理由需要申请 ipv4 地址，那都是他的权力。有些人看不起小白用户，觉得他们配不上用过公网 ip ，这大可不必。
|
 |
65
delpo 2022-08-28 09:52:08 +08:00
广播 syn 可太秀了,真是脑溢血才能想出的方案,干脆内网直接用组播地址算了
我是真的不理解,与其搞这个,运营商搞个端口映射不是简单地多? |
|
66
Marionic0723 OP @Zy143L 同意你说的只需要几个监听端口。而这样那完全可以在 100.64 上开独享端口，运营商做固定的端口映射，分配几百个端口，不够再加，允许内网有限度的从公网连入。但是现在它要搞共享公网，那我觉得是骗小白的概率更大，而且很容易被误解。比如“为什么就这几个端口能连上？”继而发现是共享的。
@Damn 如果 IP 很多年来都是同一个区域分配的话，能找到 IP 地址，就这么几个人了，社会工程学也能找到了。 日志估计也就存半年，要不然一天上网多少流量，就是光记录最基本的信息，估计也记录不过来。 @xxfye “普通用户根本就不会去开公网 ipv4 ，既然想要开放，就要承受不安全的代价”，但是小白跟风要公网可不管安全，估计就是想要那个虚荣心。这套方案对付完全不需要远程访问的小白，可谓天衣无缝（也就是 100.64 换个皮，加强下，完全不允许外部访问。）这一招直接让小白不会去投诉了，但是懂一点的，爱折腾的，遇到问题就麻烦了，完全不能访问还好说，就怕变成玄学，一会通一会断，可能费很大劲才会想到是 IP 地址的问题。 @QwQmoe 或许是算法啥的来选择，具体我也不懂。不过完全随机的话，很快就会发现不对劲。Ping 还好，是小事，真的需要远程连接那可是无法伪造的，容易发现问题，就包括 Socks5 代理把明文密码发给别人或者进了蜜罐。 |
 |
67
jousca 2022-08-28 10:16:57 +08:00
@guazila 一个月 10 块钱你想多了。跟专家说县城房价仅 1500 元一样不食人间烟火。一个地址最少一个月 100 元，运营商才愿意给出来用。运营商不是不给公网地址，是你们用的最便宜的家宽他们不愿意给而已。
企业专线，别说 1 个公网地址，你要一个 C 段地址他都给你。 我在北京联通当时拉了一条紫金专线，合同里免费给了我 128 个公网地址，半个 C 段。钱到位了没有什么不给的。 |
|
68
Marionic0723 OP 1
@guazila 同意你说的，但是小白要公网一没有远程访问需求，二不会配防火墙，暴露在公网容易变肉鸡，运营商也不可能专门给小白配防火墙（否则和内网有啥区别，不就是路由器显示的公网 IP 不是 100.64 了），三还会占用宝贵的 v4 资源，原来 nat 就很好，有需要的申请，不需要的就用内网。
而现在这套方案是，不跟风 /无需求的用内网，跟风的以及刚需的，第一次申请到共享公网，真的是刚需的发现不对劲再申请成独享公网。 至于你说加钱的问题，这个也可行，但是现实中主要问题是小白无脑跟风去申请公网，运营商用这套方案治理他们，这招可以让大部分人满意，但是对刚需玩家就不友好了，从共享到独享这一段就会绕弯子，然后才会发现是共享。 而目前还不知道运营商怎么处理多端口冲突之类的问题。 |
|
69
Damn 2022-08-28 10:44:45 +08:00
@Marionic0723 我觉得影响最大的还是可用连接数降低，本站玩 pt 的可不少。我等普通用户开迅雷影响也挺大的。
开端口除非约定好范围，不然 upnp 不好做，但用脚趾头想运营商也不会满足个性化需求。 |
 |
70
HugeToon 2022-08-28 10:54:14 +08:00 via Android 1
@wwbfred 别的不发表意见，关于安全隐患的问题，socks5 的例子不太恰当，你自己上面也说了计网分层思想，上层协议的安全性本来就不该由下层来保证啊。
|
 |
71
msg7086 2022-08-28 11:22:29 +08:00
@guazila 这么稀缺为什么只卖 10 块钱一个月？为什么不抬价卖给企业或者用在机房？
国内的 IP 总数是固定的，机房在加服务器，各种云计算，然后移动设备也要共享出口 IP ，设备数量只增不减。你要是一个月收 10 块钱，分分钟把你几个省的公网 IP 全部挤兑光。 |
|
72
wwbfred 2022-08-28 11:37:30 +08:00 1
@HugeToon 我的意思是你不能主动创造这个攻击条件啊。信道不能保证是否安全和主动去创建一个危险的信道，这是完完全全的两码事。就好比你不能确定你收到的外卖是否有毒，这个风险的确要用户自己承担，但这不代表外卖公司可以给小哥人手发一瓶砒霜。
|
|
74
guazila 2022-08-28 12:06:49 +08:00
@msg7086 因为卖贵了根本没人买，就不说普通用户了，V 站里你可以问问如果家宽公网 IPV4 一个月需要加 20 块钱，一年 240 ，有多少人会付费，有这个钱我为什么不买个 VPS 呢？家宽有了公网 IPV4 只是方便而已，在现在 IPV6 普及程度越来越高的情况下，访问内网有很多解决方案。电信如果真给我改个内网地址，然后一个月便宜 20 元，我觉得没什么问题。
|
 |
75
acbot 2022-08-28 12:13:31 +08:00 5
这个技术很大程度就是运营商自己在给自己挖坑或者说不是运营商在骗用户而是厂家在骗运营商。电联这么多省强制收回 v4(很多老用户都是强制收的)所以运营商何时卑微成这个样子了需要满足哪些无知小白的一些无意义的需求的？这种要求本身你就可以直接拒绝（大多数省都是直接以合约为由拒绝）但你偏要以这种所谓高明的方案来解决问题，那么如果后续人家出新的打假教程了你运营商怎么办，那个时候理亏的就是你运营商了。我不觉得会有多少运营商领导会采用这样的逻辑来解决问题。
|
 |
77
dicc 2022-08-28 13:09:00 +08:00
我四川电信, 大概一年多前开设的服务它就时而能用时而不能用,恶心死我了
|
 |
78
ChenYFan 2022-08-28 13:12:44 +08:00
现在已经不是什么 natv4 的问题了，最扯淡的是 natv6 要来了
|
|
79
Kowloon 2022-08-28 13:35:40 +08:00 via iPhone
@Marionic0723
天津联通可不是默认公网了，根据你所在电话局决定公网私网。 |
 |
80
dxppp 2022-08-28 15:18:22 +08:00 via Android
测速不应该是挂着自己的服务器打开测速网址测或者直接 iperf3 么...
|
 |
81
fan88 2022-08-28 16:25:26 +08:00
这不是欺诈是什么，这不是欺诈是什么？ 国企就可以欺诈了？
|
 |
82
NSAgold 2022-08-28 16:55:17 +08:00 via Android 1
@wwbfred 说的有道理，这玩意确实会有安全问题
但是另外几位说的也对，这套方案确实对运营商和（应该是）大部分需要公网 ip 的用户而言是个好的解决方案。毕竟现在不少跟风要公网 ip 的人不需要对外开放端口，部分人也只需要开放少量端口。 这些人是 nat4444 完全能满足的，那么省下的公网 ip 就可以给我们这些投诉要真公网 ip 的“特殊用户”了（笑） 问题其实还是多个同端口怎么处理了。 直接在光猫里给个界面，和上级网关联通，自行填开放端口都比现在的广播方案强。 （暴论：运营商直接起个 frp ，每个宽带号给 10 个映射，端口自选先到先得，这安全性都比现在强。） |
|
83
fan88 2022-08-28 17:09:08 +08:00
@xxfye 解决问题的方式有很多种，但这种靠“欺诈”和违法行业常识的方法，并不能认定为牛逼，甚至可以说是无耻。 没钱是问题吗？ 那我这样，我去抢银行呗，我去偷邻居家的呗，我去贪污纳税人的呗？
|
|
84
acbot 2022-08-28 17:26:49 +08:00
@NSAgold “... 直接在光猫里给个界面，和上级网关联通，自行填开放端口都比现在的广播方案强。...” 问题就是这个方案自己把自己整别扭了。NAT1 与公网对于大多数用户来说区别也就是 NAT 后端口范围不可控而已，并不是他开放的服务非得要用某个端口，所以其实就在现在 NAT 的基础上稍稍调整一下让 NAT 后端口范围可控，让用户直接在这个端口范围开放服务不就可以了吗？
|
 |
85
realpg 2022-08-28 17:48:59 +08:00 2
@Marionic0723 #8
不用疑问了 北京联通 天津联通 辽宁池化 IP 数量够给全省所有家宽一人 10 个还有得剩 搞啥假 IP 南方联通 北方电信这种没有历史沿革的，IP 100 户一个都不太够用还得省吃俭用 前几天看我市联通的家宽 IP 池子里的 IPv4 闲置数量还大幅度增加 而且一直不断增加。。。 因为 辽宁电信移动疯狂扩张 联通宽带贵 大量用户退网 2019 年至 2022 年 沈阳联通的家宽 IP 池剩余可用一直是不断增加不断增加 2022 年增加略微放缓 但还是增加 北京联通天津联通应该也是一样的 很多时候不是不爱给你 只是资源少 给你就别玩了 |
|
86
NXzCH8fP20468ML5 2022-08-28 18:27:57 +08:00
@fan88 欺诈你什么了，是宽带协议上写明了要给你独享的公网 IPv4 地址了？那我肯定支持你维权。
但就说这个假公网 IP ，1. 是不是公开的 IPv4 地址？ 2 .能不能从外网访问？ 至于外部访问不稳定，家宽也从没做过保证。 本来就算是某种“福利”的东西，不能因为别人没做到符合你心目中的样子，就给自己加戏——啊，别人一定在欺诈我。 |
 |
87
huihuilang 2022-08-28 19:23:13 +08:00 via Android
艹怪不得我的阿狸 ddns 一直获取地址失败，强烈怀疑是假公网。。。不过也无所谓了，100 年外面连不了一次，以后有时间研究下 v6 公网
|
 |
88
Akariiin 2022-08-28 19:36:20 +08:00
nat4444 没问题，cgnat 也没问题，至少能在 IP 资源紧张的情况下实现有限端口的 fullcone ，但是运营商不明确告知用户可用端口，不做隔离，做了这个技术最不应该拿来做的事情
|
 |
89
paramagnetic 2022-08-28 19:41:04 +08:00
@xxfye 欺诈行为常见的一个解读是“行为人明知自己的陈述是虚伪的，并会导致对方陷入错误认识，而希望或放纵这种结果的发生”。从题图来看，我认为这个导致用户陷入错误认知的故意是存在的。
|
|
90
NXzCH8fP20468ML5 2022-08-28 19:49:10 +08:00 via Android
@paramagnetic
运营商有陈述公网 ipv4 是什么吗，承诺过什么东西吗，难道不是用户主动提出的？ |
 |
91
liulongquan 2022-08-28 19:54:47 +08:00
公网 ip 可遇不可求
|
|
92
paramagnetic 2022-08-28 19:55:49 +08:00
@xxfye 没有，于是正确的解答应该是“不知道，我这解决不了，不行你换个 ISP 吧”。或者“我们这有 NAT4444 ，虽然有一些访问稳定性和安全方面的风险，但是能几乎完美解决游戏和视频 NAT 的问题，你要不要试试？”而不是不声不响地让用户对自己享受到的服务的质量和安全性产生误解。
|
 |
93
shikkoku 2022-08-28 20:01:15 +08:00
🙃运营商能确保我从外部能连接我的主机 /传统监控设备我就不纠结那么多了。
|
|
94
wuosuper 2022-08-28 20:45:43 +08:00 via Android 1
@xxfye @Akariiin @fan88 @acbot @NSAgold @Marionic0723
无论如何也无法改变现状，运营商作为完全看中投诉量 kpi 的企业，如果因为这个方案导致运营商投诉量剧增的话，运营商也只会停止使用，就像前段时间投诉不给余量的结果一样，只能是大家都被改为内网没有公网可以用。 跟某运营商建维聊过，其实这个技术相当早了，最早在运营商现网部署的地区到现在已经 5 年多了，到现在已经有数十个省份接近四十个城市都在部署使用，经过现网反馈的各种问题也都已经解决，由于这套业务设计的相当巧妙，楼上提到的问题也都基本解决，当然作为厂商自己的机密也不会提供出具体的方案说明。如果不是这张图的流出，至今不会有人察觉到运营商使用了这项技术，也许你正在使用的公网地址已经就是这种方案改造过的，如果不是有人告诉你，根本不会发现，因为用起来与真正的公网没有明显差异，真公网能做到的共享 IP 95.0%能做到，楼上提到的一些判断方法也只能针对早期版本（图也很老了，不过由于这项技术某厂独有，如果你的 BRAS 不是该厂就无需担心，是 100%真公网）。 因为这套技术是实实在在的为运营商降低了投诉量，很受到运营商的欢迎，某些部门也默许了这种做法，各地纷纷效仿都在采购，而且现网部署后投诉率也很低，可以忽略到不计的程度，所以观望的那些运营商也在采购。 这种技术在按闹分配、用户动不动就投诉的情况下诞生也不奇怪，当然，最差的结果就是投诉直到运营商停用该系统，全都用 NAT444 私网地址，这样就平等了。 |
|
95
wuosuper 2022-08-28 20:53:27 +08:00 via Android
@acbot #84 直接在光猫里给个界面，和上级网关联通，自行填开放端口。这个方案已有，现网可用，部分地区即使是 100 段 CGNAT 地址，也可以通过光猫路由的模式，在天翼网关那个界面配置端口映射向外开放端口，每个网关限制 20 个端口，内部端口自己定，外部端口动态分配，使用的是 PCP 协议，当然改桥接用路由模式就不能映射了。
|
 |
97
qdmooo 2022-08-28 21:30:12 +08:00
用远程桌面，ddns 和 nas 试一下不就行了。如果内网也可以通过域名访问家里的 nas 和远程桌面，那公网和内网有什么区别呢。就算是固定 ip 家宽也封 80 的
|
|
98
wwbfred 2022-08-28 23:08:36 +08:00 via iPhone
@wuosuper 我都不用管什么机密不机密的，你就告诉我，三个 SSH 开到一个 IP 的 22 上了，你连哪个？我开全端口服务回答所有 SYN 包，你怎么办？其实根本不用问，知道了有这么个玩意，测试一下就知道了。土加密最怕见光，一曝光就死的透透的，这玩意也是一样。你说没有明显差异，完全是因为这个方案足够奇葩，发现问题了也不可能往这上面去想。本质上玩的还是信息差。
|
|
99
wwbfred 2022-08-28 23:24:04 +08:00
@wuosuper 关于如何发现是假的公网 IP ，不玩投机取巧，我就玩概率。直接扫我所在的网段的所有端口，开了服务的和没开服务的分成两组。然后反复重播反复扫，只要拨到了有服务的 IP 上，就高度怀疑假公网。测试自己拥有这个公网 IP 时有服务 port(s)的情况，再测试自己释放了该 IP 时有服务 port(s)的情况。写脚本反复测上半个月，概率学上可以获得极高置信的结果。如果再对有服务端口做针对性监听，就可以完全确定是否为假公网了。运营商再怎么投机取巧，别人一步一个脚印走路你是拦不住的。
|
 |
100
wsph123 2022-08-28 23:26:51 +08:00 via iPhone
沈阳联通也大概率是假的，写了定时脚本有时候重新拨号十次才能在外网连回自家
|
Select Language