NAT类型和穿透技术方案
1. NAT
NAT 全称是 Network Address Translation（网络地址转换）。
简单来说，就是你的路由器把家里所有设备（手机、电脑、游戏机）的私有内部地址，转换成一个运营商分配的公网地址，以便与互联网通信的技术。
而我们常说的 “NAT 类型 “，其实是指：你的路由器对于 “ 外面的数据想进入你家 “ 这件事，管得有多严。
1.1 示例题
想象你住在一个名为 “ 局域网花园 “ 的封闭小区里。
- 你（设备）：住户，住在 101 室。
- 公网 IP：小区的正门地址。
- NAT 类型：小区的传达室大爷（保安）。
大家都共用小区的正门地址收发快递。当你买东西（访问网页）时，大爷会把快递转交给你。但如果是陌生人要来拜访你（联机游戏请求），大爷会让进吗？这就取决于大爷的 “ 脾气 “（NAT 类型）：
- NAT 1 / Open（开放）： 大爷不在岗。任何人只要说是找你的，直接进。
- NAT 2 / Moderate（中等）： 大爷很尽职。如果是你刚才打过电话（发过数据）的人，大爷就让进；陌生人会被拦住。
- NAT 3 / Strict（严格）： 大爷极其古板。外人一概不许进，除非你使用了极其特殊的手段。
1.2 NAT 类型
在技术上，NAT 这种 “ 阻拦策略 “ 主要分为四种：
- Full Cone NAT (全锥型)：最宽松，一旦建立映射，外部任何 IP 任何端口通常都能通过该洞口发进来。
- Restricted Cone NAT (地址限制锥型)：只允许 “ 我之前主动发过消息的那个 IP” 回消息给我。
- Port Restricted Cone NAT (端口限制锥型)：最常见的中等类型。只允许 “ 我之前主动发过消息的那个 IP 且必须是那个 端口 “ 回消息给我。
- Symmetric NAT (对称型)：最严格。每次连接不同的目标，路由器都会分配不同的端口，导致外部很难预测并连接你。
| 专业术语 (核心技术) | 索尼 PS4/5 | 微软 Xbox / Win | 任天堂 Switch | 解释 |
|---|---|---|---|---|
| Full Cone NAT (全锥型) | Type 1 | Open(开放) | A | 极其开放，不用验证身份直接进。 |
| Restricted Cone NAT(IP 限制锥型) | Type 2 | Moderate (中等) | B | 只要 IP 对了就能进。 |
| Port Restricted Cone NAT(端口限制锥型) | Type 2 | Moderate (中等) | B | 最常见的家用类型。 IP 和端口都要对才能进。 |
| Symmetric NAT(对称型) | Type 3 | Strict (严格) | C / D / F | 最严格，每次端口都变，极难联机。 |
graph TD
A[外部数据包到达路由器] --> B{"这也是你刚才<br>主动联系过的那个IP吗?"}
B -- No (完全陌生人) --> C{"你是 Full Cone (全锥型) 吗?"}
C -- Yes --> D["允许通过 (OPEN)"]
C -- No --> E["丢弃数据包 (STRICT/FAIL)"]
B -- Yes (回头客) --> F{端口也对应吗?}
F -- Yes --> G[允许通过]
F -- No --> H{"你是 Restricted Cone (地址限制) 吗?"}
H -- Yes (只要IP对就行) --> G
H -- No (必须IP和端口都对) --> E1.3 提问
怎么判断自己的 NAT 类型
https://github.com/HMBSbige/NatTypeTester
1 | pip install pystun3 |
全锥型也需要先与外部建立关系吗
需要先 “ 开洞 “，但不需要与 “ 特定的人 “ 建立关系。用传达室大爷的例子：
- 动作：你在家（内网）必须先对外发一个数据包（比如你去访问百度）。
- 开洞：因为你发出去了，大爷（路由器）为了让你能收到回信，必须在记录本上写一行字：”101 室的人正在用小区的 8000 号信箱 “。这个 “8000 号信箱 “ 就是那个洞。
- 区别来了：
- 其他 NAT：大爷会盯着这个信箱，只有百度寄回来的信才塞进去，谷歌寄来的直接扔掉。
- 全锥型 NAT：大爷一旦把 “8000 号信箱 “ 分配给了你，任何其他人（谷歌、黑客、陌生网友）只要往这个 8000 号信箱塞东西，大爷全都会转交给你。
总结：全锥型 NAT 需要你先发起一个动作来 “ 占坑 “（分配映射端口），一旦坑占好了，谁都可以跳进来。
NAT 安全性
安全性：Symmetric (Type 3) > Restricted (Type 2) > Full Cone (Type 1)
Type 3 最安全，因为它把所有想主动访问你的请求都拒绝了，但也导致很多应用无法通过。
Type 1 最不安全，相当于告诉全世界：” 我家大门没锁，谁想进来看看都可以 “。
家里 NAT 类型建议
在现代家庭网络中（光猫 + 路由器），要实现 Type 1 通常需要把光猫设为桥接，路由器设为 DMZ 指向游戏机，甚至要在游戏机上直接通过 PPPoE 拨号。
对于 99.9% 的玩家，NAT 2 是最完美的状态——既安全，又能正常联机。只有当你完全无法匹配到人（NAT 3）时，才需要通过 UPnP 或 DMZ 去优化到 NAT 2。
多数现代路由器的默认行为——Port Restricted Cone NAT（端口限制锥型）。它既不像 Open 那样随便进，也不像 Strict 那样谁都不让进。
如何改善 NAT
如果你发现自己的 NAT 类型很差（Strict/类型 3），可以尝试以下操作（按推荐顺序）：
- 开启 UPnP (通用即插即用)：这是最简单的方法。进入路由器后台，找到 UPnP 并开启。它允许设备自动申请端口。
- 设置 DMZ 主机：把你的游戏机 IP 填入路由器的 DMZ 设置中。这相当于把这台设备完全暴露在公网，注意：只对游戏机用，千万别对电脑用，有安全风险！
- 申请公网 IP：这是终极大招。如果你是光猫拨号且没有公网 IP（被 ISP 套了一层大内网），你怎么设置路由器都没用。你需要打电话给宽带运营商申请公网 IP。
双重路由陷阱
双重路由 (Double NAT) 是初学者最容易犯的错误。你买了一个超贵的电竞路由器，但 NAT 依然是 Strict。
原因：光猫（自带路由功能） -> 你的路由器 -> 你的设备。
这就好比小区大门有保安，你家楼栋门口还有一个保安。即便你贿赂了楼栋保安（设置了你的路由），小区大门的保安依然会拦住数据。
解法：将光猫改为桥接模式 (Bridge Mode)，让你的电竞路由器负责拨号；或者把你的路由器设为 AP 模式（但这会牺牲路由功能）。
2. 穿透方案
内网穿透 (Tunneling / Port Forwarding)：这是一种应用场景或解决方案。目的是将处于内网（无公网 IP 或被防火墙阻挡）的服务暴露到公网上。实现方式既可以使用 NAT 穿透技术（P2P），也可以使用中继服务器（Relay/Proxy）。
NAT 穿透 (NAT Traversal)：这是一组技术手段（通常指 P2P 打洞）。目的是让两个都在 NAT（特别是锥型 NAT）设备后面的节点，能够在没有公网 IP 的情况下直接建立通过 UDP/TCP 的连接。典型协议包括 STUN、TURN、ICE。
假设你住在高档封闭小区（内网），你的朋友想给你送文件。
- 没有穿透：门卫（NAT 网关）不仅不认识你朋友，还禁止一切外人进入，文件送不到。
- 中继模式 (Relay/Tunneling)：你在小区门口（公网服务器）租了个储物柜。你自己把文件放进去，或者让门口的快递员（FRP/Ngrok 服务端）帮你把朋友给你的东西转交进来。
- NAT 穿透 (P2P 打洞)：你和朋友约好暗号。你先往小区大门扔一块石头（发出出站包），门卫以为你要出去，打开了一道缝。你朋友立刻趁着这个缝还没关，把文件扔进来。门卫以为这是你 “ 出去 “ 的回应，所以放行了。
| 概念/工具 | 类型 | 核心原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|---|
| FRP / Ngrok | 中继隧道 | TCP 端口转发 | 极其稳定，协议支持全（HTTP/TCP/UDP） | 依赖中继服务器带宽，延迟较高 | 对外发布 Web 服务，临时 SSH |
| Tailscale / ZeroTier | 虚拟组网 (Overlay) | 基于 WireGuard 或自定义协议的 P2P + 打洞 | 配置极其简单，就像在同一个局域网，安全性高 | 握手通过第三方，极少数情况打洞失败会慢 | 个人/团队多设备互联，访问内网资源 |
| SSH Remote Forward | 纯隧道 | ssh -R | 任何 Linux 自带，无需安装额外软件 | 功能单一，断连需脚本维护 | 临时急用 |
| STUN / TURN | 协议标准 | NAT 映射发现 / 中继 | WebRTC 的基石 | 是底层协议而非直接工具，开发难度大 | 开发音视频应用，P2P 软件 |
2.1 中继隧道方案
(以 FRP/Ngrok 为例)，这是最稳定但带宽成本最高的方式。
sequenceDiagram
participant User as "公网用户"
participant Server as "公网中继服务器 (FRP Server)"
participant NAT as "NAT防火墙/路由器"
participant Local as "内网机器 (FRP Client)"
Local->>NAT: "建立长连接 (TCP)"
NAT->>Server: "转发长连接请求"
Server-->>Local: "连接建立，保持心跳"
User->>Server: "访问 Server端口 (如 8080)"
Server->>NAT: "通过已有长连接转发数据"
NAT->>Local: "透传数据给内网服务"
Local-->>Server: "响应数据"
Server-->>User: "最终响应"2.2 NAT 穿透技术
NAT 穿透 (NAT Traversal) 是一组旨在让位于 NAT 设备（如家用路由器、企业防火墙）后的两台主机建立直接或间接网络连接的技术集合。它主要解决私网 IP 无法在公网被直接路由，以及 NAT 会丢弃非请求入站流量的问题。
NAT 穿透目前主流技术与方案概览：
- 技术手段： UDP Hole Punching（打洞）、TCP Hole Punching（较难）、ALG (Application Layer Gateway)、UPnP/NAT-PMP/PCP。
- 标准协议/方案： STUN (Session Traversal Utilities for NAT)、TURN (Traversal Using Relays around NAT)、ICE (Interactive Connectivity Establishment)。
NAT 就像一家大公司的总机，员工（内网主机）只有分机号（私网 IP）。员工可以打出去，对方看到的来电显示是总机号（公网 IP）。但是，外面的客户无法直接拨打分机号找到员工。
- STUN 就像员工打电话给这就公司的 “ 去电显示查询台 “，问：” 喂，我现在打出去，外人看到的号码和端口是多少？” 然后员工把这个外显号码告诉客户，让客户回拨。
- TURN 就像如果公司防火墙太严（比如对称型 NAT），禁止外部回拨，员工只能找一个中间人（中继），说：” 所有给我的信都发到你那里，我时刻保持和你的连接，你去帮我转发。”
- ICE 就是一个极其聪明的通讯录管理器，它会自动尝试上面所有的方法：先试着直连，不行问分机号，再不行找中继，直到打通为止。
sequenceDiagram
participant A as "Client A (NAT A)"
participant S as "STUN Server"
participant B as "Client B (NAT B)"
Note over A, B: "目标：A 和 B 在各自 NAT 后建立直连"
A->>S: "1. 绑定请求 (Binding Request)"
S-->>A: "2. 绑定响应 (你的公网IP:Port是 1.2.3.4:1000)"
Note right of A: "A 知道了自己的公网映射地址 (Server Reflexive)"
B->>S: "3. 绑定请求"
S-->>B: "4. 绑定响应 (你的公网IP:Port是 5.6.7.8:2000)"
Note right of B: "B 知道了自己的公网映射地址"
Note over A, B: "A 和 B 通过信令服务器(Out-of-Band)交换这些公网地址"
A->>B: "5. A 向 B 的公网互发 UDP 包 (Punching Hole)"
Note right of A: "NAT A 此时记录：允许来自 B 的回包通过"
Note left of B: "该包通常会被 NAT B 丢弃，因为 NAT B 还没见过 A"
B->>A: "6. B 向 A 的公网互发 UDP 包"
Note left of B: "NAT B 此时记录：允许来自 A 的回包通过"
Note right of A: "NAT A 检查记录，发现 A 曾联系过 B，放行！"
A->>B: "7. P2P 连接建立，直接通信"- STUN: 告诉客户端它在公网的样子。
- TURN: 当第 5、6 步失败（如遇到对称 NAT）时，充当数据中继。
- ICE: 协调整个过程，收集所有可能的地址（Host, Srflx, Relay），按优先级测试连通性。
| 概念 | STUN (Session Traversal Utilities for NAT) | TURN (Traversal Using Relays around NAT) |
|---|---|---|
| 角色 | 咨询师 (Consultant) | 中继者 (Relay) |
| 数据流 | 仅用于信令交互，数据不经过服务器 | 所有数据流量都经过服务器转发 |
| 带宽消耗 | 极低 | 极高 (昂贵) |
| 适用场景 | 锥型 NAT (Full Cone, Restricted Cone) | 对称型 NAT (Symmetric NAT) 或 防火墙极严 |
| 成功率 | 约 80% | 接近 100% (只要开放端口允许连出) |
| ICE 角色 | 生成 Server Reflexive Candidate | 生成 Relay Candidate |
2.3 提问
TURN 和中继隧道的区别
| 特性 | TURN 协议 (RFC 5766) | 中继隧道 (如 SSH Tunnel/FRP) |
|---|---|---|
| 核心目的 | Assist P2P (辅助 P2P) | Port Forwarding (端口转发/内网穿透) |
| 连接生命周期 | 临时、动态。仅在通话/会话期间，Client 申请一个临时端口，用完即弃。 | 持久、静态。Client 长期维持一条连接，通常绑定固定的公网端口或域名。 |
| 寻址方式 | 动态分配。Client 发送 Allocate 请求，Server 返回一个随机端口。 | 配置指定。配置文件写死：把公网 8080 映射到内网 80。 |
| 主要载荷 | 音视频流 (RTP/RTCP)，基于 UDP 居多。 | TCP 流 (HTTP, SSH)，或整个 IP 包 (VPN)。 |
| 报文开销 | 大。每个 UDP 包都要加 4 字节的 TURN 头部（ChannelData）指明发给谁。 | 小。建立好隧道后，通常直接透传数据流，或者是自定义的极简封装。 |
一句话总结： TURN 是为了让两个动态的端点（人）临时能说话；中继隧道是为了让一个静态的服务（服务器）能长期被访问。
中继隧道实现 TURN 协议了吗？
通常没有。
- 中继隧道 (Relay Tunnel) 属于一种泛称的功能描述，不是一个具体的协议名。
- 大多数隧道工具（SSH Rplay, FRP, Ngrok）使用的是自定义协议或标准的 SOCKS5 / HTTP CONNECT 协议来实现中继，而不是使用 TURN 协议。
- 为什么不用 TURN？ 因为 TURN 太重了，而且设计初衷是 UDP/P2P。对于像 “ 把内网的 Web 服务暴露到公网 “ 这种 TCP 业务，TURN 并不是最优解，自定义的长连接多路复用协议（Multiplexing）效率更高。
FRP / Ngrok, Tailscale 实现了 TURN 协议吗
FRP / Ngrok (反向代理/隧道工具):
没有，它们使用自定义的私有协议（通常基于 TCP 或 KCP）。
它们在公网服务器和内网客户端之间建立一条持久的控制通道（Control connection）。当有用户访问公网端口时，通过这条通道 “ 透传 “ 流量。它们不涉及 TURN 的 Allocation/Permission 机制。
Tailscale
没有，Tailscale 它是 UDP 打洞（STUN 逻辑）的集大成者。它会尽一切可能建立 P2P 直连。当 UDP 打洞彻底失败时，Tailscale 不使用 TURN，而是使用它自己研发的 DERP (Designated Encrypted Relay for Packets) 协议。
Tailscale 官方认为 TURN 协议为了通用性（兼容 SIP, WebRTC 等）带有很多历史包袱。
总结
- FRP/Ngrok = 自定义 TCP 隧道协议（非 TURN）
- Tailscale = 自定义 DERP 中继协议（非 TURN，但功能对标）
- 只有 WebRTC 应用 (Zoom, Google Meet) = 标准 TURN 协议。
- TURN 是 WebRTC 领域的标准中继协议。
- FRP/Tailscale 是具体的软件，它们不做 TURN，它们有自己更适合自身业务的 “ 私有中继协议 “。
WebRTC 的 TURN 每次都必须经过服务器消耗流量？
只有当 P2P 打洞失败 时，TURN 才会被激活。根据业界的统计数据（如 Google 和 Zoom 的公开报告）：
- 约 80% - 90% 的 WebRTC 连接可以成功建立 P2P 直连（通过 STUN 或内网）。在这种情况下，TURN 服务器的流量消耗几乎为 0（你只是和它握了个手，没发数据）。
- 仅 10% - 20% 的连接因为网络环境太恶劣（对称 NAT + 对称 NAT），被迫走 TURN 中继。
ICE 完全是一个协调者吗
- ICE 不是一种传输协议： 它不负责搬运数据包（数据包是 UDP/TCP 搬运的）。
- ICE 不是一种探测协议： 它自己不产生探测包（探测包是 STUN/TURN 产生的）。
- ICE 是一个逻辑框架 (Framework)：
- 它定义了 “ 流程 “：什么时候收集地址？什么时候测试连通性？
- 它定义了 “ 优先级 “：Host > Server Reflexive (STUN) > Relay (TURN)。
- 它定义了 “ 决策 “：如果 A 通路通了，B 通路也通了，选哪个 RTT 更低？
打洞的原理是什么
打洞的核心在于欺骗 NAT 设备，让它以为这是一次 “ 正常 “ 的出站请求回应。原理步骤（以 UDP 为例）：
- 预备（中间人）：内网机器 A 和 B 无法直接对话，它们必须连接一台公网服务器 S（信令服务器）。A 和 B 通过 S 交换了彼此的公网 IP 和端口。
- 僵局：此时，A 知道 B 在哪，B 也知道 A 在哪。但如果 B 直接给 A 发包，A 的路由器（NAT A）会查路由表/Session 表，发现：” 我不记得 A 刚才给 B 发过请求啊？这肯定是外部攻击！” 于是直接丢弃 (Drop)。
- 出拳（Punching）：
- A 率先向 B 的 IP:Port 发送一个 UDP 包。
- 关键点：虽然这个包大概率会被 B 的路由器（NAT B）丢弃，但是，A 的路由器（NAT A）会在本地的 Session 表（几元组映射表）里记录一条规则：
允许 A <-> B 通信。这就是 “ 在 A 的墙上打了个洞 “。
- 回击：
- B 紧接着向 A 发送一个 UDP 包。
- 当这个包到达 NAT A 时，NAT A 查表发现：” 哦！A 刚才确实想联系 B，这是 B 的回复。” 于是放行。
- 握手成功：A 收到 B 的包，连接建立。
工程师总结：打洞本质上是利用 NAT 的 “ 出站包建立入站白名单 “ 机制。
打洞时间窗口
双方需要在 “ 同一个时间窗口内 “ 相互发送数据包。至于双方如何感知，关键在于一个第三方的协助者（中间服务器）。
- 场景： A 在家里，B 在家里，他们都想互相去对方家里玩。但是他们的小区门口各有一个守门大爷（NAT）。
- A 发送给 B：
- A 对守门大爷说：” 我要给 B 发个包。” A 的守门大爷记下了：” 好，A 出去找 B 了，如果 B 回信，我会放行。”（A 的洞打通了）。
- 然而，当这个包到达 B 的小区门口时，B 的守门大爷此时还不知道 A 是谁，直接把包扔了（丢包）。
- B 发送给 A：
- B 也对自己的守门大爷说：” 我要给 A 发个包。” B 的守门大爷记下了：” 好，B 出去找 A 了，如果 A 回信，我会放行。”（B 的洞打通了）。
- 当这个包到达 A 的小区门口时，A 的守门大爷查了一下记录：” 哦！A 刚才确实出去给 B 发过信，这是 B 的回信，放行！”
- 通道建立：
- A 收到了 B 的包，A 再给 B 回信，B 的守门大爷一看：”B 刚才找过 A，这是回信，放行！”
- 至此，双向通信建立。
如果不 “ 同时 “ 会有什么问题？如果在 A 发送后，等了很久（比如几分钟）B 才发送，A 的守门大爷可能因为超时把那条 “ 放行记录 “ 给删掉了（NAT Session Timeout）。所以，双方通常会约定在几秒钟内互相发送一连串的 UDP 包，以确保双方的 “ 门 “ 都是开着的。
打洞双方感知
既然 A 和 B 都在只有内网 IP 的 NAT 后面，他们一开始是怎么知道对方的公网 IP 和端口的呢？这时候就需要中间人（信令服务器/STUN 服务器）。
感知流程：
- 汇报信息： A 和 B 启动时，都会先连接公网上的服务器 S。服务器 S 会看到 A 和 B 的公网 IP 及端口。
- 交换信息：
- A 告诉 S：” 我想连 B。”
- S 告诉 A：”B 的公网地址是 1.2.3.4:8000。”
- S 告诉 B：”A 的公网地址是 5.6.7.8:9000，A 马上要连你了，你也赶紧连它！”
- 开始打洞： 拿到对方地址的瞬间，A 和 B 就开始利用上述原理向对方的地址疯狂发包。
- 感知成功：
- 一旦 A 成功收到了来自 B 的 UDP 包，或者 B 收到了来自 A 的包，程序内部就会触发回调（Callback），判定 “ 连接已连通 “。
- 之后他们就可以抛弃服务器，直接 P2P 聊天了。
UDP 打洞不能突破对称型 NAT 吗
在工程实践中，我们通常认为不能，直接放弃并切换到中继模式。对称型 NAT（Symmetric NAT），通常认为无法打洞。但如果不仅预测端口，而是同时发送大量探测包（Port Prediction），在某些特定路由器实现下，可以通过暴力猜测端口实现打洞。
TCP 打洞是什么意思
TCP 打洞比 UDP 难得多，因为它是有状态的（Stateful）。
UDP 难点：NAT 只要记录 IP:Port 映射。
TCP 难点：TCP 有三次握手（SYN, SYN-ACK, ACK）和序列号。大多数防火墙会在看到不符合握手顺序的包（比如没见 SYN 就来了 ACK）时直接发送 RST 重置连接。
TCP 打洞的黑科技：SO_REUSEADDR 与 Simultaneous Open（同时打开）
- 常规 TCP 是
Client Connect -> Server Listen。 - TCP 打洞利用了 TCP 协议标准中一个冷门的特性：Simultaneous Open。
- A 和 B 互相同时发送
SYN包（而不是一个 SYN 一个 Listening）。 - 如果时机配合得完美，双方的 NAT 都会看到一个出站的
SYN，从而在防火墙上创建 Session。 - 当对方的
SYN到达时，NAT 认为这是 “ 针对刚才出站 SYN 的回应（虽然它也是 SYN）”，从而放行。
- A 和 B 互相同时发送
现状：由于实现极其复杂，且对 NAT 设备的行为要求很高，现代 P2P 软件（如 WebRTC）主要依赖 UDP，TCP 打洞在实际中很少作为首选。
UPnP 和 DMZ 是什么意思
这两个是路由器上的功能，都不属于 “ 打洞 “ 技术，而是属于 “ 端口映射 (Port Forwarding)” 的自动化或暴力版。
UPnP (Universal Plug and Play) - “ 自动申请钥匙 “
- 定义：一种局域网协议。
- 场景：你下载了一个 BT 软件或玩游戏。
- 流程：软件启动时，向局域网广播：” 我是 BT 软件，我的内网 IP 是 192.168.1.5，请网关大哥帮我把公网的 6881 端口映射给我！”
- 结果：路由器收到请求，自动添加一条端口映射规则。无需人工登录路由器后台配置。
- 缺点：安全性差，恶意软件也可以用它悄悄开启对外端口。
DMZ (Demilitarized Zone) - “ 把人扔到大门外 “
- 传统定义：企业网络中，位于外网和内网之间的隔离区（放 Web 服务器的地方）。
- 家用路由器/光猫定义（你常看到的）：” 全端口映射主机 “。
- 操作：你在路由器里把内网 IP
192.168.1.5设为 DMZ 主机。 - 结果：路由器把所有外网发来的、没有特定映射规则的流量，全部一股脑转发给
192.168.1.5。这台机器相当于直接裸奔在互联网上。 - 警告：除非极特殊情况（如配置硬路由做二级路由），千万不要把你的个人电脑设为 DMZ，否则会被黑客扫成筛子。
没有公网 IP 开启 UPnP 功能，外网能访问吗？
- UPnP 的作用范围：UPnP 协议只能控制你自己的那台路由器。它确实会在你的路由器上自动创建一条映射规则。
- 光猫/运营商大网关（CGNAT）：” 没有公网 IP”，意味着你的路由器 WAN 口得到的是一个内网 IP（比如 10.x.x.x 或 100.64.x.x）。你的路由器连着运营商的超级大路由器（NAT 网关）。
- 结果：即使你在自己家大门（路由器）打开了锁，但是小区的大门（运营商网关）是锁死的，且你没有权限去配置运营商的路由器。外网请求被挡在运营商那里，根本到不了你家门口。
结论：没有公网 IP，UPnP 毫无作用。UPnP = 仅仅打开你自家的防盗门。
FRP 或 Ngrok 时 需要公网 IP，而 TeamViewer 不需要
- 基础设施归属：
- FRP/Ngrok：通常是自托管 (Self-hosted) 或透传工具。由于你自己没有其他的 “ 信令服务器 “ 来协助打洞，最简单粗暴的方法就是你自己架设一个中继服务器，强制走中继。你需要公网 IP 是因为你是服务提供商。
- TeamViewer：是 SaaS (软件即服务)。TeamViewer 公司在公网上部署了成千上万台服务器（信令服务器 + 中继服务器）。你不需要自己搭建，是因为你连的是 TeamViewer 公司的服务器，他们帮你完成了握手或转发。
- 连接策略：TeamViewer 采用 ICE 机制：它会优先尝试直连 (P2P) 以节省带宽、降低延迟；如果打不通，自动回退到官方的中继服务器。
内网数据库端口通过 FRP 映射到公网，和 Tailscale 区别
本质区别在于 “ 暴露面 (Attack Surface)” 的大小：
- FRP/端口映射：属于 “ 公网暴露 “。
- 你把内网数据库的 3306 端口映射到公网服务器的 8080。
- 结果：互联网上任何人（包括黑客的扫描脚本）只要扫描到你的公网 IP:8080，都可以尝试发起连接、暴力破解密码或利用漏洞。
- Tailscale/WireGuard：属于 “ 私有验证网络 “。
- 它们构建了一个虚拟局域网。
- 结果：端口只在这个虚拟网络内部开放。外网黑客扫描你的公网 IP，什么都看不到（端口是关闭的）。只有持有合法密钥、并通过了身份验证（Auth）的设备，才能看到并连接这个服务。这就是当下流行的零信任 (Zero Trust) 理念。