完全圆锥形NAT
- NAT 实现方式 ：是防火墙怎么配置、怎么转地址 → 管工程落地、地址 / 端口怎么换
- NAT 行为模式 ：是NAT 转换后，外部能不能访问、映射固不固定 → 管通信规则、P2P 能不能穿透
| 对比维度 | NAT 实现方式分类 | NAT 行为模式分类 |
|---|---|---|
| 本质 | 地址转换的配置方法 / 实现逻辑 | 转换后的通信行为 / 访问规则 |
| 解决什么问题 | 内网共享公网 IP 上网、发布内网服务器 | P2P 穿透、外网主动访问权限、安全控制 |
| 核心关键词 | 地址、端口、地址池、接口 IP、静态 / 动态 | 映射固定、访问限制、端点依赖、对称 / 圆锥 |
| 设备视角 | 防火墙怎么执行转换 | 防火墙允许谁访问转换后的端口 |
| 典型成员 | No-PAT、NAPT、Easy IP、NAT Server | 全锥、IP 受限锥、端口受限锥、对称型 |
| 是否厂商专属 | 是（华为 / 华三 / 思科叫法不同） | 否（IETF 国际标准，所有设备通用） |
| 配置位置 | 防火墙 NAT 策略、地址池、接口 | 防火墙 NAT 过滤模式（filter-mode） |
NAT 行为模式 = 门卫放外人进门的规矩（通信性格）
- 谁敲门都放进来（全锥型 Full Cone）
- 只有来过的人才能进（IP 受限锥）
- 只有来过的人 + 敲对特定门才能进（端口受限锥）
- 来一个陌生人，就换一把新锁（对称型 Symmetric）
NAT 行为模式（对称 / 圆锥）100% 是给【源 NAT】用的！跟目的 NAT、NAT Server 完全无关！
NAT 行为模式管的不是：外人能不能主动进门（目的 NAT/NAT Server）而是：内网人主动出门后，外人能不能顺着 "出门的通道" 找回来（源 NAT）！
1. 目的 NAT / NAT Server：外人主动敲门
- 场景：外网→内网服务器
- 映射：静态写死（公网 IP: 端口 → 私网 IP: 端口）
- 规则：天生就是全锥型（谁都能敲）
- 结论：**没有行为模式可言，不需要分类！**你家大门上贴了 "欢迎所有人来访"，这是固定规则，不用选 "规矩"。
2. 源 NAT（NAPT/Easy IP/No-PAT）：内网人主动出门
- 场景：内网→外网（上网、打游戏、连 QQ）
- 映射：动态临时生成（私网 IP: 端口 → 公网 IP: 随机端口）
- 关键：防火墙开了一个临时回访通道
- 行为模式：就是定义这个临时通道，外人能不能进、谁能进
行为模式 = 源 NAT 出门后，给外网留的 "回访权限"
这就是为什么它只属于源 NAT！
NAT 行为模式的前置知识点
1. NAT 行为模式，只针对「源 NAT（NAPT/Easy IP）」 目的 NAT、NAT Server 是静态固定映射，没有行为模式，不需要分类
2.它的唯一作用：定义「内网主动访问外网后，外网能不能顺着通道回访内网」
3. 分类的唯一标尺（所有区别都源于此） 对同一个内网源 IP + 源端口 ：① 访问不同外网目标，公网映射（IP + 端口）是否固定不变 ？② 外网主机能否主动回访这个映射，限制条件是什么？
一、为什么要区分这么多？（产生的核心缘由）
- IPv4 地址枯竭企业 / 家庭用私网 IP，必须靠 **NAPT（端口复用）** 共享少量公网 IP 上网。
- 传统 NAPT 是单向封锁 只有内网能主动访问外网，外网无法主动找到内网主机。
- P2P 应用爆发 QQ / 微信 / 网游 / VoIP/BT/ 视频会议：两个内网主机需要直接互通，不能全靠服务器转发。
- IETF 标准化（RFC 3489/5389） 为了兼容不同设备的 NAT 穿透能力，把 NAT 按映射规则 + 回访权限分成 4 种行为模式。
二、4 种 NAT 行为模式：本质 + 区别 + 场景
（一）圆锥型 NAT（Cone NAT）------ 核心：同一个内网端口，永远映射同一个公网端口
1. Full Cone NAT（全锥型）
华为 filter-mode ：
endpoint-independent（端点无关）本质 ：映射永久固定，无任何回访限制
映射规则
内网
192.168.1.10:8080→ 公网202.100.1.1:10000（终身不变）回访权限
全世界任何 IP、任何端口 ，主动发往
202.100.1.1:10000，都能到达内网应用场景
NAT No-PAT 默认、内网需要完全开放穿透、早期 P2P 服务
穿透性 ：最强
2. Restricted Cone NAT（IP 受限锥型）
- 华为 filter-mode ：
endpoint-dependent（仅端点 IP 依赖）- 本质 ：映射固定，只限制回访 IP，不限制端口
- 映射规则：同一个内网端口→固定公网端口
- 回访权限 只有内网主动访问过的外网 IP ，才能回访；该 IP 的任意端口都可以连
- 应用场景企业安全加固、视频会议、IP 白名单类 P2P
- 穿透性 ：强
3. Port Restricted Cone NAT（端口受限锥型）
- 华为 filter-mode ：
endpoint-and-port-dependent（端点 + 端口依赖）- 本质 ：映射固定，同时限制回访 IP + 端口
- 映射规则：同一个内网端口→固定公网端口
- 回访权限 只有内网主动访问过的「外网 IP + 端口」，才能回访
- 应用场景 家庭宽带 / 企业上网默认、微信 / QQ / 网游（最通用）
- 穿透性 ：中等（完美支持主流 P2P）
会话表 = 只管「你主动访问的那个目标 → 发回来的原有连接回包」
行为模式 = 管「所有主动发到你公网映射端口的 新连接」
（二）对称型 NAT（Symmetric NAT）------ 完全不同于圆锥型
- 华为 filter-mode ：
symmetric- 本质 ：映射不固定！每访问一个新外网目标，就换一个新的公网端口
- 映射规则（最特殊） 内网
192.168.1.10:8080访问A:80→ 公网10000访问B:80→ 公网10001访问C:443→ 公网10002- 回访权限 只有当前正在通信的对端 IP + 端口 ，能临时回访；其他任何主机都无法访问
- 应用场景 金融 / 政府 / 军工高安全场景，彻底禁止 P2P 穿透，杜绝外部攻击
- 穿透性 ：最差（几乎无法 P2P 穿透）
三、filter-mode 4 个参数 → 直接对应 4 种行为（必背）
| 华为 filter-mode 配置 | 对应 NAT 行为模式 | 核心特征 |
|---|---|---|
| endpoint-independent | 全锥型（Full Cone） | 映射固定，无回访限制 |
| endpoint-dependent | IP 受限锥型 | 映射固定，仅限制 IP |
| endpoint-and-port-dependent | 端口受限锥型 | 映射固定，限制 IP + 端口（默认） |
| symmetric | 对称型 | 映射不固定，安全最高 |
四、终极本质区别（一句话戳穿）
- 圆锥型（全锥 / IP 受限 / 端口受限） 映射固定不变 ，三者的区别仅在于：外网回访的限制松紧程度不同。
- 对称型 映射完全不固定 ，和圆锥型是两种完全不同的底层逻辑，安全拉满、穿透报废。
五、极简场景速记
- 家用宽带、打游戏、聊 QQ → 端口受限锥（默认）
- 企业视频会议、信任 IP 回访 → IP 受限锥
- 一对一地址转换、完全开放 → 全锥型
- 银行、政府、禁止 P2P → 对称型
六、最后补 1 个关键：
和实现方式的关系
- NAT No-PAT → 一对一固定映射 → 默认全锥型
- NAPT/Easy IP → 端口复用 → 可配 4 种模式，默认端口受限锥
- NAT Server / 目的 NAT → 静态映射 → 天生全锥，无 filter-mode 配置
**************************************************************************************************************
**************************************************************************************************************
家用宽带 99% 的流量（刷视频、看网页、刷抖音），只用会话表就够了，行为模式根本不干活！
一、先给 3 个不可推翻的核心总纲
- 家用 99% 流量（刷视频 / 网页 / 抖音 / 微信文字） ：全程只有你家内网主动访问外网 ，外网永远不会主动访问你家内网。
- 会话表的作用 ：专门管「内网主动发起连接 → 外网服务器回包」，这是普通上网的唯一需求。
- 行为模式的作用 ：专门管「外网主动发起新连接 → 找内网 」，普通上网完全没有这种流量，所以行为模式全程不干活、不参与、不判断。
二、前提：家用普通上网的流量本质 ------单向主动，无反向入侵
你在家做的所有事：
- 打开浏览器搜百度
- 刷抖音 / 小红书
- 看 B 站 / 腾讯视频
- 微信发文字、刷朋友圈全都是：你家设备 → 主动找外网服务器 没有任何一件事：外网服务器 → 主动找你家设备
这是行为模式不干活的根本原因------ 它管的流量，普通上网里根本不存在！
三、逐步骤拆解：刷抖音的完整流程（会话表全权负责，行为模式躺平）
你的设备：内网 192.168.1.10，家用路由器Easy IP，默认端口受限锥行为模式
抖音服务器：外网公网 IP 180.100.100.100
步骤 1：你主动发起请求（内网→外网）
你滑动抖音 → 手机主动发报文：192.168.1.10 → 180.100.100.100
路由器做Easy IP源 NAT：把内网私网 IP → 换成路由器公网 IP
步骤 2：路由器创建会话表（核心！）
会话表只记录 1 件事：
这个内网设备，主动找过这个抖音服务器，允许它回包
会话表示例：
bash
源(私):192.168.1.10 → 源(公):222.xx.xx.xx:10000 | 目的:180.100.100.100:80 → 允许回包步骤 3：抖音服务器回包（外网→内网）
抖音服务器给你发视频流 → 报文：180.100.100.100 → 222.xx.xx.xx:10000
路由器只查会话表：
✅ 这是我主动发起的连接的回包 → 直接转发给你手机
❌ 完全不看行为模式，行为模式全程休眠
步骤 4：全程结束
- 没有外网主动找你的流量
- 没有新连接
- 行为模式没有任何工作可做
四、彻底解决你的核心疑惑：服务器转发 = 主动找我好友？错！
我发消息给微信服务器，服务器不得转发给好友吗？那不就是服务器主动去找我好友吗？
五、行为模式到底什么时候干活？（普通上网里绝对没有）
行为模式的唯一工作：判断「外网主动发来的新连接」要不要放行 这种流量只有 1 种场景：P2P 直连（语音 / 视频 / 游戏联机 / 传文件）
- 你主动找抖音 / 百度 / 微信服务器：没有新连接 → 行为模式不干活
- 好友主动找你直连语音：外网主动新连接 → 行为模式才醒
家用 99% 的流量，没有这种主动入站的新连接，所以行为模式全程躺平！
**************************************************************************************************************
**************************************************************************************************************
**************************************************************************************************************
**************************************************************************************************************
Full Coone NAT STUN类型的报文
终极总纲（所有知识点的闭环）
- STUN = 老师说的简单 UDP 穿越 ，只干一件事：帮内网主机拿到自己在Full Cone NAT 上的公网 IP + 端口映射。
- Full Cone NAT（完全圆锥） = 源 NAT 行为模式，私网端口→公网端口永久固定 ，触发流量就生成 FullCone Server-MAP 表。
- Server-MAP 核心特权 ：优先级高于安全策略 ，直接绕过安全策略 ，放行所有外网入站 UDP 报文。
- TFTP 穿越 = 靠「STUN 获取映射 + Full Cone 固定映射 + Server-MAP 绕过策略」，解决 TFTP服务端随机 UDP 端口回包的致命问题。
一、先把 3 个核心基础讲透
1. STUN：简单 UDP 穿越（到底干啥的？）
- 全称：简单 UDP 穿透 NAT 协议，纯 UDP 轻量协议
- 作用：内网主机主动发 STUN 包→STUN 服务器返回「你的公网 IP + 端口」
- 本质：帮主机知道自己在 NAT 上的映射地址，为穿越做准备
- 特点：简单、只查映射、不建连接 ，所以叫简单 UDP 穿越
2. Full Cone NAT（完全圆锥）核心 3 特性
- 映射永久固定：同一个内网 IP + 端口 → 永远对应同一个公网 IP + 端口
- 必生成 Server-MAP ：触发一次出方向流量，自动生成FullCone 类型 Server-MAP 表
- 全开放入站 ：任何外网 IP + 任何端口，访问该公网端口都能进
3. TFTP 的致命痛点（为什么必须 Full Cone 才能穿？）
- 纯UDP协议（无连接、无握手）
- 服务端初始端口 UDP 69 ，后续传输全用随机高端口
- 普通 NAPT：会话表只认 69 端口，随机端口回包直接被丢
- 只有 Full Cone 的Server-MAP能放行随机端口
二、Full Cone NAT 下 TFTP 穿越 NAT完整工作原理（逻辑闭环）
左边：服务器侧 内网
- 内网 TFTP 服务器：
192.168.1.5 - 出口防火墙：配置 Full Cone 完全圆锥 NAT
- 作用：把内网 TFTP 服务器映射到公网，供外面访问
右边：客户端侧 内网
- 内网 TFTP 客户端：
10.0.0.8 - 出口路由器：默认端口受限锥 NAT（家用普通 NAT）
中间：互联网
两边都没有公网固定 IP，两边都要经过 NAT，互相看不到真实私网地址。
先把前提知识点极简讲透
1. TFTP 硬性特点（一切问题的根源）
- 基于 UDP 无连接
- 控制端口：UDP 69（只做初始请求）
- 真正传数据时，服务器自动换成 随机高端口（50000+ 随机）
- 致命问题：客户端只知道服务器 69 端口，不知道后续随机端口
2. 普通端口受限锥 NAT 最大短板
适合客户端主动上网、P2P 微信语音 ；不适合做内网服务器对外提供服务。
原因：
- 映射虽然固定
- 但只允许我主动访问过的 外网 IP + 端口才能进来
- 别人主动随机端口访问你 → 直接被拦死
- 不生成 Server-MAP，不能绕过安全策略
3. Full Cone 完全圆锥 NAT 三大核心（服务器侧必须用它）
- 内网同一个 IP + 端口 → 公网映射永久固定
- 只要内网有一出站 UDP 流量，自动生成 FullCone Server-MAP 表
- Server-MAP 表优先级高于安全策略 → 直接绕过安全策略检查
- 允许任意外网 IP、任意外网端口 主动访问进来
4. STUN（老师说的简单 UDP 穿越）
作用就一个：帮内网设备测出自己在 NAT 上的 公网 IP + 公网端口映射 不建立业务连接，只做探测，所以叫简单 UDP 穿越。
关键问题：
为什么内网 TFTP 服务器 不能用普通端口受限锥？
- 外网客户端发起 TFTP 请求 → 先连服务器 69 端口
- 服务器回应后，立刻切换随机高端口传数据
- 对服务器侧 NAT 来说：这个随机端口的入站包，不是服务器主动访问过的外网 IP + 端口
- 端口受限锥直接丢弃随机端口报文
- TFTP 只能连上目录，传文件必断
所以：内网要对外做 TFTP 服务，出口防火墙必须配 Full Cone。
标准完整流程
**************************************************************************************************************
**************************************************************************************************************
微信的视频语音通信过程
第一部分：手把手拆解 微信语音 / 视频 完整流程
全程只用端口受限锥，完全不用 Full Cone，我一步不跳给你讲透什么叫「双向主动打 UDP 洞」。
步骤 1：A、B 登录微信，先找 STUN 服务器拿自己的公网映射
- A 主动发 UDP 包给公网 STUN 服务器路由器 A（端口受限锥）给 A 分配一个固定公网映射 ：
192.168.1.10:5000 → 110.1.1.1:20000- B 主动发 UDP 包给公网 STUN 服务器路由器 B 给 B 分配固定公网映射：
192.168.2.20:6000 → 120.1.1.1:30000
STUN 只干一件事：把各自的公网 IP + 端口告诉 A 和 B。
步骤 2：微信信令服务器互换地址（当媒人）
微信服务器告诉 A：B 的公网地址是 120.1.1.1:30000
微信服务器告诉 B：A 的公网地址是 110.1.1.1:20000
现在 A 知道在哪找 B，B 知道在哪找 A。
步骤 3：最关键 ------ 双向主动发 UDP 包「打洞」
动作 1：A 主动发一个 UDP 小包 → 发给 B 的公网 120.1.1.1:30000
- 路由器 A 收到这个出站包
- 按端口受限锥规则做记录：
内网 192.168.1.10:5000 主动访问过 120.1.1.1:30000
以后只允许 120.1.1.1:30000 进来，别的一概不让
👉 这就给 B 开了一个专属的洞。
动作 2：B 同时主动发一个 UDP 小包 → 发给 A 的公网 110.1.1.1:20000
- 路由器 B 收到出站包
- 按端口受限锥规则记录：
内网 192.168.2.20:6000 主动访问过 110.1.1.1:20000
以后只允许 110.1.1.1:20000 进来
👉 这就给 A 也开了一个专属的洞。
步骤 4：直接 P2P 语音互通
现在：
- A 的路由器允许 B 的公网 IP + 端口 进来
- B 的路由器允许 A 的公网 IP + 端口 进来
双方直接互相发语音 UDP 包，完全符合端口受限锥的规则，畅通无阻。
第二部分：为什么微信不需要 Full Cone？
Full Cone 是什么？
不管是谁、不管什么端口，都能随便闯进内网，无任何限制。
微信根本不需要这么放开：
- 只是两个人互相通信，不是全世界陌生人都来连你；
- A、B互相主动发过包，已经在对方路由器的「允许白名单」里；
- 端口受限锥已经精准放行，没必要把大门完全敞开（不用 Full Cone）。
第三部分：TFTP 为什么必须要 Full Cone？
同样用端口受限锥拓扑，你一眼就看懂卡死在哪。
拓扑
- 内网 TFTP 服务器：
192.168.1.5→ 路由器 端口受限锥 NAT - 外网任意陌生客户端：随便一个公网 IP，想连内网 TFTP 服务器传文件
致命问题 1：TFTP 是纯 C/S 模式，只有客户端主动，服务器绝不主动
外网陌生客户端主动发起请求，想去连内网 TFTP 服务器。
但是：
内网 TFTP 服务器，从来没有主动发过包访问这个陌生客户端 IP
按端口受限锥铁律：
你没主动访问过人家 → 人家就绝对不能主动进你内网
→ 路由器直接丢包，连接都建不起来。
致命问题 2：TFTP 传数据会随机换端口
就算勉强连上初始 UDP 69 端口：
TFTP 传文件时会立刻换成一个全新随机高端口。
这个新随机端口：服务器没主动访问过、客户端也没提前报备→ 端口受限锥再次直接丢包，文件传不动。
只有 Full Cone 能解决
Full Cone 直接废掉端口受限锥的限制：
- 不管是不是陌生人、不管有没有主动访问过；
- 不管对方用什么随机端口；
- 生成 Server-MAP 表，绕过安全策略，任何人任何端口都能进。
完美适配 TFTP：对内网服务器被动接待全世界陌生人、还乱换端口的特性。
TFTP没法用ASPF创建server map表
