1. 静态NAT究竟在解决什么问题

1.1 从一次内网服务器上线的需求说起

前阵子帮一个朋友处理他们办公网的一件小事：内网放了一台文件服务器，地址是 192.168.1.10，平时只在局域网里用。后来业务方希望出差在外的同事也能访问这台服务器上的资料，于是找运营商要了一个固定公网地址，问题就来了——内网地址在公网上根本不可见，外部请求打到边界设备上就断了。这类场景里，思科网络中的静态NAT配置就是最直接的一把钥匙：把内网某个私有地址永久地、一对一地映射成一个公网地址，外部访问公网地址时，边界设备自动把目标地址换成内网地址，回包再换回来。它不依赖地址池，不做端口复用，表项不会因为空闲而老化，配好之后就像一个固定的门牌号，什么时候访问都在。

静态NAT适合谁？适合手上有一台或几台需要对外提供服务的设备、公网地址数量够用、希望映射关系稳定可预期的场景。比如对外发布的网站、邮件服务器、监控平台、合作方专用的接口机。它不适合“全公司几百台电脑共享一个公网地址上网”这种需求，那是动态NAT加端口复用（PAT）的活。很多人一开始把这两件事混在一起，配了半天发现内网主机还是上不了网，其实就是方向搞反了。下面我按实际做项目的顺序，把规划、配置、验证、排错整条链路拆开讲，命令都是可以直接照着敲的，参数也会说明白为什么这么填。

1.2 静态NAT、动态NAT与PAT的边界在哪里

要把静态NAT配明白，先得清楚它和另外两种NAT的分工。动态NAT是从地址池里临时借一个公网地址给内网主机，借完要还，表项有老化时间；PAT更省，所有内网主机共用一个公网地址，靠源端口号区分是谁的流量。静态NAT则是“包办婚姻”，一条命令绑定一对地址，永久有效，而且双向都能发起连接——这一点很关键，既是它的价值，也是它的风险。

这张表我在给团队做培训时会反复拿出来讲。静态NAT的最大特征是“确定性”：外部客户拿到的是一个固定地址，防火墙策略、DNS 解析、合作方白名单都可以提前写好，不会因为表项老化而失效。代价是公网地址消耗大，并且一旦映射出去，外部就多了一条能主动打到内网的路径。所以我在做静态NAT配置时，习惯把它当成“开了一扇固定的门”，门开在哪、开多大、谁能进，必须和 ACL 一起设计，不能只敲一条映射命令就完事。

还有一个容易混淆的点：静态NAT和端口映射不是一回事。地址级静态映射会把整个 IP 的所有协议、所有端口都映射过去；端口级静态映射只放行指定的 TCP/UDP 端口。实际项目里，除非对方明确要求“整台设备暴露”，否则我更倾向用端口级映射，把 80、443、22 这些必要端口逐个放开，其余一律不映射。这样即使映射关系写错，暴露面也可控。

2. 配置前的网络规划与关键决策

2.1 先画图再敲命令：地址与映射表设计

我见过太多人一上来就敲ip nat inside source static，敲完发现不通，再回头翻拓扑，结果发现公网地址根本不在边界设备上，或者内网服务器的网关指错了地方。静态NAT的配置量不大，但前置规划决定成败。我的习惯是先画一张最简单的图：内网网段、边界设备两个接口的地址、运营商给的公网地址段、需要映射的服务器地址，四样东西写清楚，再列一张映射表。

假设一个典型的小型办公网：内网网段 192.168.1.0/24，边界路由器 G0/0 接内网，地址 192.168.1.1；G0/1 接运营商，地址 203.0.113.1/30，运营商网关 203.0.113.2；运营商额外路由过来一个可用地址 203.0.113.5，准备映射给内网文件服务器 192.168.1.10。映射表就写成下面这样，一行对应一条命令，后期排查时直接对照，不用凭记忆。

这里有个细节值得说：公网端口不一定和内网端口一致。上表把内网的 22 映射成公网的 2222，目的是降低被扫描的概率，同时也避免和边界设备自身的 SSH 管理端口冲突。端口号的选择没有硬性规定，但建议避开 22、3389 这类高频扫描端口，映射到 10000 以上的端口更省心。当然，如果对方是合作方固定访问，端口号要提前和对方对齐，不能自己拍脑袋改。

2.2 接口方向与路由：NAT 生效的两个前提

静态NAT配置里最不起眼、也最容易出错的就是接口的 inside/outside 标记。NAT 设备判断“从哪来到哪去”完全依赖这两个标记：从标记为ip nat inside的接口进入、从标记为ip nat outside的接口发出，才叫出方向转换；反过来叫入方向转换。少标一个，或者标反了，映射表里写得再对也不会生效。我的习惯是配置前先执行show ip interface brief，把两个接口的地址和状态确认一遍，再进接口敲标记，敲完立刻show running-config interface回读，确认没有敲到错误的接口上。

路由同样不能忽略。很多人以为配了NAT就不需要路由，这是误解。NAT 转换发生在路由查找之后，设备先根据目的地址决定从哪个接口出去，再在这个出接口上做地址转换。所以内网服务器要把默认网关指向边界设备的内网接口，边界设备要有一条指向运营商网关的默认路由，运营商侧也要知道 203.0.113.5 这个地址怎么走——最后这一点经常被忽略。如果运营商只给了地址但没做路由，外部请求根本到不了你的设备，你在设备上怎么抓包都看不到流量。遇到这种情况，先和运营商确认地址段的路由指向，别急着怀疑配置。

interface GigabitEthernet0/0 description LAN ip address 192.168.1.1 255.255.255.0 ip nat inside no shutdown ! interface GigabitEthernet0/1 description WAN ip address 203.0.113.1 255.255.255.252 ip nat outside no shutdown ! ip route 0.0.0.0 0.0.0.0 203.0.113.2

上面这段是地基，先把它敲稳，再谈映射。命令里的description不是摆设，过几个月回来看配置，一眼就知道哪个口是内网哪个口是外网，比翻 IP 地址快得多。no shutdown也别省，接口管理性关闭是排查时最常见的“低级原因”之一。

2.3 静态NAT不是防火墙：安全边界要单独设计

静态NAT把内网地址暴露到公网，但它本身不做访问控制。只要映射存在，外部任何来源都可以尝试连接这个公网地址对应的端口，NAT 设备只负责地址替换，不负责判断“该不该放行”。这一点必须提前和业务方讲清楚，否则很容易出现“映射配好了，结果服务器被扫”的情况。我的做法是：映射只开必要端口，同时在 outside 接口的入方向挂一条 ACL，只允许已知来源访问映射后的公网地址和端口，其余一律丢弃。

ip access-list extended OUTSIDE-IN permit tcp host 198.51.100.20 host 203.0.113.5 eq 443 permit tcp any host 203.0.113.5 eq 80 deny ip any any log ! interface GigabitEthernet0/1 ip access-group OUTSIDE-IN in

这条 ACL 的写法有讲究：先放行合作方固定地址访问 443，再放行任意来源访问 80，最后显式拒绝并记录日志。顺序不能反，ACL 是从上往下匹配的，一旦被前面的deny拦住，后面的permit就没机会了。另外，ACL 里写的是映射后的公网地址，不是内网地址，因为报文到达 outside 接口时还没做 NAT 转换，目标地址仍然是公网地址。这一点我踩过坑：早期把内网地址写进 ACL，怎么都不生效，后来抓包才看明白匹配顺序。

注意：ACL 末尾的deny ip any any log会产生日志，流量大时可能刷屏，建议配合日志级别或限速，别让日志把设备 CPU 拖垮。

3. 思科设备上的静态NAT完整配置实操

3.1 地址级一对一映射：最基础也最常用

地址级静态映射的命令只有一行，但参数顺序要记牢：ip nat inside source static 内网地址 公网地址。前半段inside source表示“转换内网源的地址”，后半段两个地址依次是转换前和转换后。敲完这条命令，设备会立即在转换表里生成一条永久表项，不需要等流量触发。

ip nat inside source static 192.168.1.10 203.0.113.5

这条命令的语义是：内网 192.168.1.10 发出的流量，源地址被替换成 203.0.113.5；外部访问 203.0.113.5 的流量，目标地址被替换成 192.168.1.10。两个方向共用一条表项，所以叫“双向静态”。配完之后用show ip nat translations能看到类似下面的输出，表项没有老化时间，--表示当前没有活动会话。

Router# show ip nat translations Pro Inside global Inside local Outside local Outside global --- 203.0.113.5 192.168.1.10 --- ---

地址级映射适合“整台设备对外”的场景，比如一台专用的邮件网关或者合作方要求全端口访问的接口机。但它把全部端口都暴露了，风险面大。我通常只在对方明确要求、且 ACL 能精确限制来源时才用地址级映射；否则优先用下一节的端口级映射。

3.2 端口级静态映射：把暴露面收到最小

端口级映射在地址级命令后面加协议和端口，格式是ip nat inside source static 协议 内网地址 内网端口 公网地址 公网端口。以网站和运维通道为例：

ip nat inside source static tcp 192.168.1.10 80 203.0.113.5 80 ip nat inside source static tcp 192.168.1.10 443 203.0.113.5 443 ip nat inside source static tcp 192.168.1.10 22 203.0.113.5 2222

三条命令分别把内网的 80、443、22 映射到公网的 80、443、2222。注意第三条内外端口不一致，这是允许的，也是推荐的。配置完之后，转换表里会出现三条带协议和端口的表项，外部访问 203.0.113.5:2222 时，设备会把目标改成 192.168.1.10:22，回包再改回去。

Router# show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 203.0.113.5:80 192.168.1.10:80 --- --- tcp 203.0.113.5:443 192.168.1.10:443 --- --- tcp 203.0.113.5:2222 192.168.1.10:22 --- ---

这里有个坑要提醒：同一个公网地址上，地址级映射和端口级映射不能混用。如果你先配了ip nat inside source static 192.168.1.10 203.0.113.5，再加端口映射，设备会报冲突或者行为不可预期。原因是地址级映射已经占用了整个 IP，端口级映射再想复用同一地址就没有空间了。解决办法是二选一：要么全用地址级，靠 ACL 限制；要么删掉地址级，全部改成端口级。变更时记得先no掉旧命令，再敲新的，别指望设备自动覆盖。

3.3 验证三件套：表项、统计、调试

配置敲完只是开始，验证才是见真章的地方。我常用的三条命令是show ip nat translations、show ip nat statistics和debug ip nat，分别看“有没有表项”“接口标记对不对”“报文有没有真的被转换”。

show ip nat statistics的输出信息量很大，重点看两处：一是Inside interfaces和Outside interfaces后面列的接口是不是你期望的那两个，二是Hits和Misses的计数。如果 Hits 一直是 0，说明流量根本没走到 NAT 逻辑，优先查接口标记和路由；如果 Hits 在涨但外部还是访问不了，说明转换发生了，问题可能出在回程路由或 ACL。

Router# show ip nat statistics Total active translations: 3 (3 static, 0 dynamic; 0 extended) Outside interfaces: GigabitEthernet0/1 Inside interfaces: GigabitEthernet0/0 Hits: 128 Misses: 4 ...

debug ip nat适合在测试窗口短时间打开，能看到每一条被转换的报文，包括转换前后的地址和端口。它的输出大概是这样：

Router# debug ip nat NAT: s=192.168.1.10->203.0.113.5, d=198.51.100.20 [12] NAT*: s=198.51.100.20, d=203.0.113.5->192.168.1.10 [12]

第一行是出方向，源地址被换成公网地址；第二行是回方向，目标地址被换回内网地址，前面的星号表示这是快速路径转发的报文。看到这一对出现，基本可以确认 NAT 工作正常。但debug在生产设备上要慎用，流量大时 CPU 会明显上升，建议配合 ACL 限制调试范围，或者干脆在业务低峰期做。

注意：测试前先执行clear ip nat translation *清掉旧表项，避免残留表项干扰判断。静态表项虽然不会老化，但手工清除后会在下一条流量到达时重新建立，不影响使用。

3.4 NVI 方式：新平台上的另一种写法

老式配置依赖接口的 inside/outside 标记，在新一代 IOS 平台上还有一种 NVI（NAT Virtual Interface）方式，接口上只敲ip nat enable，映射命令改成ip nat source static。它的好处是同一个接口可以同时处理两个方向的转换，适合地址重叠或者双向都需要 NAT 的复杂场景。

interface GigabitEthernet0/0 ip nat enable ! interface GigabitEthernet0/1 ip nat enable ! ip nat source static 192.168.1.10 203.0.113.5

NVI 和传统方式不能混用，同一台设备上要么全用ip nat inside/outside，要么全用ip nat enable，混着配会出现部分流量不转换的怪现象。我在一个迁移项目里就遇到过：老配置没删干净，新接口又加了ip nat enable，结果内网能出去、外部进不来，查了半天才发现两套逻辑在打架。迁移时的稳妥做法是先把旧 NAT 配置整体备份，再逐条删除，确认show ip nat statistics里没有残留表项，最后再上新配置。

4. 常见故障与排查技巧实录

4.1 一张速查表覆盖八成问题

静态NAT的故障现象翻来覆去就那么几类，我把实际项目中遇到过的整理成下表，按“现象—可能原因—确认方法”三列对照，排查时从上往下走，基本能在十分钟内定位。

这张表里最值得展开的是“有转换表项但回包不通”。很多人看到show ip nat translations有记录就以为 NAT 没问题，实际上转换只是第一步，回包能不能回到内网服务器，取决于服务器自己的路由表。如果服务器是多网卡，默认网关指到了别的设备，回包就会从另一条路走，NAT 设备根本看不到，外部自然超时。这种情况下在服务器上tracert一个外部地址，看第一跳是不是 NAT 设备的内网接口，一目了然。

4.2 用计数器定位“到底卡在哪一步”

排查 NAT 问题时，我习惯按“入向有没有包—有没有转换—出向有没有包—回包有没有回来”四步走，每一步都有对应的命令，不靠猜。第一步在 outside 接口抓包，确认外部请求确实到达了设备；第二步看show ip nat statistics的 Hits 是否增长；第三步看转换后的报文是否从内网接口发出；第四步在内网服务器上抓包，确认请求是否到达、回包是否发出。

Router# show ip nat statistics Router# show ip nat translations verbose Router# clear ip nat translation * Router# debug ip nat

show ip nat translations verbose会多出创建时间、剩余老化时间、使用的转换类型等信息。静态表项的剩余时间通常显示为--，如果看到某条表项带倒计时，说明它可能是动态产生的，和你预期的静态映射不是一回事，需要回头检查配置里是不是混进了overload或者地址池。

还有一个细节：clear ip nat translation *会清掉所有动态表项，静态表项也会被清掉但会立即重建。在变更配置后、测试之前执行一次，能避免“旧表项让新配置看起来不生效”的假象。我带新人时要求他们养成这个习惯，就像改完 DNS 记录要清缓存一样。

4.3 应用层协议的特殊处理

静态NAT工作在 IP 层，大多数 TCP/UDP 应用配好映射就能用，但有几类协议会把地址信息藏在载荷里，需要额外处理。FTP 主动模式就是典型：服务器在控制连接里告诉客户端“来连我的某个地址和端口”，如果服务器不知道自己在公网上对应的是哪个地址，它告诉客户端的就是内网地址，客户端自然连不上。解决办法是在设备上启用 NAT 的应用层网关功能，让设备在转发控制报文时替换载荷里的地址。

ip nat service ftp tcp port 21

SIP、H.323 这类语音协议也有类似问题，处理思路一样，启用对应的 ALG。但 ALG 不是万能的，复杂场景下更稳妥的做法是把服务器配置成被动模式，或者在应用层直接写死公网地址。我在一个监控平台项目里就遇到过：摄像头通过私有协议上报，载荷里带了内网地址，外部平台一直连不上，最后是在设备上抓包看到载荷内容才定位到问题，改成平台侧配置公网地址后解决。这类问题没有通用命令，只能靠抓包和分析协议。

注意：启用 ALG 会增加设备的处理负担，高流量场景下要评估性能影响。如果应用本身支持配置外部地址，优先改应用配置，少依赖 ALG。

5. 几条实战心得与变更注意事项

5.1 变更前留后路，变更后做回归

静态NAT的配置改动往往直接影响对外业务，一旦敲错，外部访问立刻中断。我的习惯是变更前先show running-config备份到本地，涉及远程操作的设备先开一个定时回滚，比如reload in 10，配完确认业务正常再reload cancel。这十分钟的保险，救过我很多次。尤其是改 ACL 和改映射这类操作，一条命令顺序错就可能把自己关在门外。

变更后不要只看“能 ping 通”，要按业务实际访问路径做回归：从外部用真实端口访问一次，用show ip nat translations确认表项建立，用show ip nat statistics确认 Hits 增长，再看服务器日志有没有正常记录。ping 走的是 ICMP，和 TCP 端口映射是两套逻辑，端口映射配错了 ping 照样通，但业务就是不通。这个坑我见得太多了，所以现在做验收一律要求“按真实业务端口测”。

5.2 双出口与策略路由场景下的顺序问题

当网络有两个出口，静态NAT又和策略路由同时存在时，顺序问题会把入搞晕。设备处理报文的顺序大致是：先查路由表决定出接口，再做 NAT 转换，最后转发。策略路由如果在路由查找之前把流量引到了另一个出口，NAT 的 outside 接口就可能和实际出接口对不上，导致转换不生效或者回包走错路。这种场景下，我一般把 NAT 和策略路由的匹配条件写得尽量一致，或者在策略路由里显式指定下一跳后，再确认 NAT 的 outside 标记覆盖了那个出接口。

另一个常见问题是公网地址不在直连接口网段。运营商给的可用地址和接口地址不在同一个子网时，需要在设备上为这个地址加一条指向内网或指定下一跳的路由，或者在接口上配 secondary 地址，否则设备收到目标为该地址的报文会认为“不是给我的”而丢弃。这个细节在地址段较小的时候特别容易忽略，配完映射一定要从外部实际访问验证，别只在设备上show命令。

5.3 记录与文档：比配置本身更重要

最后说一个不那么技术、但决定长期维护成本的事：映射表一定要落到文档里，和配置一起版本化管理。谁在什么时候、因为什么业务、把哪个内网地址的哪个端口映射到了哪个公网地址，这些信息在配置里只有一行命令，看不出业务含义。我习惯在每条静态映射上面加一行注释，写清楚用途和责任人，虽然 IOS 的注释不会显示在show run的 NAT 段里，但可以写在接口描述或者单独的变更记录里。

! 2024-06 文件服务器对外网站，责任人：运维组 ip nat inside source static tcp 192.168.1.10 80 203.0.113.5 80

过半年再回头看，这一行注释能省掉大量“这是谁配的、能不能删”的沟通成本。静态NAT的表项是永久的，但业务不是永久的，服务器下线、地址回收、合作方变更，都需要有人知道这条映射的来龙去脉。我现在做任何静态映射，都会同步更新一张共享的映射台账，包含内网地址、公网地址、端口、协议、业务方、上线时间、预计回收时间，配置和台账对不上就以台账为准去核查。这个习惯看起来笨，但在设备多、人员流动大的环境里，是最省事的办法。