前面做过一台 USG6000V 配置全锥型 NAT（NAT1），成功了。这件事直接打脸运营商那句「我们的设备不支持全锥型 NAT」。为了让证据更充分，这次请出 eNSP Pro，真正模拟一台运营商级的 NE 设备——如果连这一级设备也能配出全锥，那「设备不支持」就彻底站不住了。
结果比预想的曲折。eNSP Pro 的坑一个接一个：设备卡死、配置丢失、明明配好了却完全不转发。折腾到最后，最有价值的发现不是「配出来了」，而是「为什么测不出来」——那里面藏着两个足以让所有人得出错误结论的陷阱。
一、实验环境
拓扑和上一篇 USG 那套保持一致，方便并列对照。
| 角色 | 配置 |
|---|---|
| 宿主 | Windows + VMware Workstation Pro |
| 虚拟网络 | VMnet1 = 模拟公网 192.168.65.0/24；VMnet9 = 模拟私网 192.168.66.0/24 |
| 网络仿真 | eNSP Pro（本身是一台 Linux 虚拟机） |
| 被测设备 | eNSP Pro 中的 NetEngine 8000 M14，拓扑标签 NE8000 |
| 公网服务器 | Rocky Linux 8.9，192.168.65.152 与 192.168.65.153 双 IP |
| 客户端 | Windows 10，192.168.66.130，网关 192.168.66.12 |
NE8000 侧接口：GE0/7/0 = 192.168.65.12/24 接公网侧 CLOUD，GE0/7/1 = 192.168.66.12/24 接私网侧 CLOUD。
二、先确认它到底是什么设备
这一步不能省。eNSP 拓扑里给它起名叫 NE8000，但标签是标签，设备是设备。
display version
Huawei Versatile Routing Platform Software
VRP (R) software, Version 8.251 (NetEngine 8000 V800R025C10SPC500)
HUAWEI NetEngine 8000 M14 ENSP uptime is 0 day, 0 hour, 5 minutesNetEngine 8000 M14，V800R025C10SPC500。 这是 2026 年的固件，运营商城域汇聚层在售型号——不是家用路由器，不是老设备，正是运营商 CGN 实际部署的那一级。
再看授权：
display license
Info: No license is activated.一条 License 都没有。 这一条对后面反驳「没买授权」很关键。
然后问设备自己支不支持 NAT：
[~NE8000]nat ?
address-group Set IP address group for address translation
alarm Alarm
alg Application Layer Gateway
distributed-policy Configure nat distributed policy
flow-defend NAT flow defend
instance Create a NAT instance or enter a NAT instance view
pure-ip-packet Pure IP packet
server Specify the internal server
session Session
static-mapping Static mapping view
syslog Text format log
tcp-mss Specify TCP MSS11 个子命令，address-group、instance、static-mapping、alg 全在。CGN 这套功能是完整编译进去的，零授权状态下就能配。
最关键的一句来自华为官方文档：
三元组NAT又称为全圆锥模式（Full Cone NAT），指以用户发出的协议报文的源IP、源端口、协议号为表项依据进行地址分配和报文过滤。
出处：NAT特性描述 — NetEngine 8000 M14K/M14/M8K/M8/M4 V800R024C00SPC500 配置指南。
华为对全锥型的叫法是「三元组NAT」。 全网搜 full-cone 搜不到任何东西，不代表这个功能不存在——是术语不同。这一句本身就足以否定「设备不支持全锥型 NAT」，因为文档白纸黑字把它定义为 Full Cone。
三、配置：每一步都在报错
真正开始配才发现，NE8000 的 CGN 配置模型和 USG 完全是两套东西，照抄 USG 的命令一步都走不通。
坑一：PNP 没关，接口配不了
[*NE8000]interface GigabitEthernet0/7/0
[*NE8000-GigabitEthernet0/7/0]ip address 192.168.65.12 24
Error: PNP State!!!PLEASE UNDO PNP enable for manual Setup! You can undo PNP in system view with "undo pnp enable"eNSP Pro 的 NE 设备出厂开着 PNP（即插即用），必须先关：
system-view
undo pnp enable坑二：三条互相否定的报错
建 NAT 地址池时，连续撞到三句看起来互相否定的错误：
Failed to run this command, because the simplified instance has not been configured.（在系统视图建池）The address pool cannot be configured in a simplified instance.（在简化实例里建池）The device already has a simplified instance configured.（想再建一个简化实例）
三句话字面互斥，任何一个按文档一步步配的人都会卡在这里，然后得出「配不出来」的结论。真正的解法只差一个 commit： VRP8 是两阶段提交，简化实例建完后停在候选配置里（提示符是 [*NE8000] 而不是 [~NE8000]），系统视图根本看不见它，所以才会报「还没配」。
正确顺序，commit 的位置不能动：
nat instance nat1 id 1 simple-configuration
commit
nat address-group ag1 group-id 1 192.168.65.211 192.168.65.211
commit坑三：高级 ACL 必须带协议
acl number 3000
rule 5 permit source 192.168.66.0 0.0.0.255
Error: Wrong parameter found at '^' position3000 段是高级 ACL（acl4-advance-3000），必须指定协议关键字：
rule 5 permit ip source 192.168.66.0 0.0.0.255最后绑到公网出接口：
interface GigabitEthernet0/7/0
nat bind acl 3000 address-group ag1
quit
commit到这里，配置三行齐全，display nat instance 也能列出对象了。看起来一切就绪。
四、真正的坑：eNSP Pro 是台 Linux
配完之后开始测。客户端 ping 192.168.65.152，通。tracert 两跳，网关 66.12 → 65.152，看起来完美。上 NatTypeTester 一测：
Binding test : Success
Mapping behavior : Direct
Filtering behavior: AddressAndPortDependent
Public end : 192.168.66.130:64159Mapping behavior = Direct，公网端点等于客户端自己的私网地址。 这不是「对称型」，这是「根本没有 NAT」。
回设备上看会话表，空的。看 ACL 计数：
display acl 3000
Advanced ACL 3000, 1 rule
ACL's step is 5
rule 5 permit ip (0 times matched)连 permit ip（匹配全部 IPv4 流量）都是 0 次命中。说明 ACL 匹配这段代码在转发路径上根本没被调用。
在 NE8000 的 GE0/7/0 上抓包，报文确实在这里过：
No. Source Destination Protocol Info
7 192.168.66.130 192.168.65.152 ICMP Type=8, Code=0
8 192.168.65.152 192.168.66.130 ICMP Type=0, Code=0
9 192.168.66.130 192.168.65.152 ICMP Type=8, Code=0
10 192.168.65.152 192.168.66.130 ICMP Type=0, Code=0
源地址从头到尾都是 192.168.66.130，一次都没被改成地址池里的 192.168.65.211。包过去了，NAT 没做。
卡了很久，最后在 eNSP Pro 那台 Linux 里找到了答案：
lensplite@ensp /]$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
lensplite@ensp /]$ ip route
192.168.65.0/24 dev eth1 proto kernel scope link src 192.168.65.154 metric 101
192.168.66.0/24 dev eth2 proto kernel scope link src 192.168.66.131 metric 102eNSP Pro 自己就在这两个网段里各有一个 IP，而且转发开关是开的。 客户端 66.130 找网关，它直接通过 eth2 收包，查路由表发现 65.0/24 直连 eth1，于是自己转发了——包连模拟设备的影子都没碰到。
这就解释了前面所有的异常：ACL 永远 0 匹配、tcpdump 只看到原始私网地址、Mapping = Direct。问题不在 NAT，在测量路径。 删掉这两条路由才让流量真正进入模拟拓扑：
ip route del 192.168.65.0/24 dev eth1
ip route del 192.168.66.0/24 dev eth2
注意每次重启 eNSP Pro 它都会重新生成这两条路由，必须重新删。
五、数据面：配置全对，就是不转换
路由删干净之后重测。包这次真的进 NE8000 了，GE0/7/0 上抓到报文，回包也正常——但源地址还是 192.168.66.130。
把所有变量逐个排掉：
- 接口绑定在公网出接口
GE0/7/0，display current-configuration | include nat三行齐全 commit成功，display nat instance能列出nat instance nat1 id 1 simple-configuration- ACL 从
permit ip source 192.168.66.0 0.0.0.255放宽到permit ip，全放通 precedence从默认 0 改成 1 再测一遍- 绑定挪到私网入接口
GE0/7/1也试过
无论怎么改，display acl 3000 永远是 0 times matched，display nat session table 永远是空表。
结论：这个镜像实现了 NAT 的控制面，nat bind 的 ACL 钩子没有挂进转发路径，数据面不执行转换。
这是模拟器的实现缺陷，不是你配置错了，也不是「华为设备不支持全锥型 NAT」——这是三件完全不同的事，混在一起就成了运营商最好的挡箭牌。
六、结论
这次实验没能复现出全锥型 NAT 的结果，但拿到了比结果更重要的东西。
设备有这个能力。 display version 显示 NetEngine 8000 M14 / V800R025C10SPC500，运营商城域汇聚层在售型号；display license 显示零授权；nat ? 列出 11 个 CGN 子命令；华为官方文档明确写着「三元组NAT 又称为全圆锥模式（Full Cone NAT）」。三份证据互相独立，任何一份都能单独反驳「设备不支持」。
「配不出来」和「不支持」是两件事。 这次在 NE8000 上摸索 simple-configuration、nat section、address pool is not bound to the simplified instance 这些报错误了整整一轮，其中三句报错字面互相否定，唯一的解只差一个 commit。一个按文档配不出来的人，很容易得出「设备不支持」的结论——运营商的技术人员大概率也是这么得出那个结论的。
测量环境的坑比设备配置的坑更致命。 eNSP Pro 本身是台 Linux，你给它加两块网卡接两个网段，它就顺手当了路由器。ip_forward=1 加两条直连路由，客户端到服务器的包完全绕过模拟设备——现象和「NAT 配错」一模一样，够让人在设备上改一整天配置。这和上一篇写的 ARP flux 是同一主题的两层：那次是「测出来必然是对称型，而这个结论是假的」，这次是「测出来的根本不是被测设备」。
两次都指向同一件事：先证明测量环境可信，再谈测量结果。
至于全锥型 NAT 到底能不能在 NE 设备上配出来——本文不给出行为结论。设备能力由文档和命令树证明，NAT 行为由上一篇 USG6000V 的实测证明。这个模拟器复现不了，仅此而已。
如果你觉得这篇文章不错，有用的话可以点击下面的“赞赏”支持作者，你的支持是我更新的动力（饿饿吃饭）。
Comments NOTHING