1. 静态NAT究竟在解决什么问题1.1 从一次内网服务器上线的需求说起前阵子帮一个朋友处理他们办公网的一件小事内网放了一台文件服务器地址是 192.168.1.10平时只在局域网里用。后来业务方希望出差在外的同事也能访问这台服务器上的资料于是找运营商要了一个固定公网地址问题就来了——内网地址在公网上根本不可见外部请求打到边界设备上就断了。这类场景里思科网络中的静态NAT配置就是最直接的一把钥匙把内网某个私有地址永久地、一对一地映射成一个公网地址外部访问公网地址时边界设备自动把目标地址换成内网地址回包再换回来。它不依赖地址池不做端口复用表项不会因为空闲而老化配好之后就像一个固定的门牌号什么时候访问都在。静态NAT适合谁适合手上有一台或几台需要对外提供服务的设备、公网地址数量够用、希望映射关系稳定可预期的场景。比如对外发布的网站、邮件服务器、监控平台、合作方专用的接口机。它不适合“全公司几百台电脑共享一个公网地址上网”这种需求那是动态NAT加端口复用PAT的活。很多人一开始把这两件事混在一起配了半天发现内网主机还是上不了网其实就是方向搞反了。下面我按实际做项目的顺序把规划、配置、验证、排错整条链路拆开讲命令都是可以直接照着敲的参数也会说明白为什么这么填。1.2 静态NAT、动态NAT与PAT的边界在哪里要把静态NAT配明白先得清楚它和另外两种NAT的分工。动态NAT是从地址池里临时借一个公网地址给内网主机借完要还表项有老化时间PAT更省所有内网主机共用一个公网地址靠源端口号区分是谁的流量。静态NAT则是“包办婚姻”一条命令绑定一对地址永久有效而且双向都能发起连接——这一点很关键既是它的价值也是它的风险。类型映射方式地址消耗表项生命周期外部主动访问典型用途静态NAT一对一固定绑定每个内网地址占一个公网地址永久除非手工清除支持对外发布服务器动态NAT从池中动态分配池大小决定并发数有老化时间不支持临时上网、地址池充裕PAToverload多对一靠端口区分一个公网地址有老化时间需配合端口映射员工日常上网这张表我在给团队做培训时会反复拿出来讲。静态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.1G0/1 接运营商地址 203.0.113.1/30运营商网关 203.0.113.2运营商额外路由过来一个可用地址 203.0.113.5准备映射给内网文件服务器 192.168.1.10。映射表就写成下面这样一行对应一条命令后期排查时直接对照不用凭记忆。内网地址内网端口公网地址公网端口协议用途192.168.1.1080203.0.113.580TCP对外网站192.168.1.10443203.0.113.5443TCP加密访问192.168.1.1022203.0.113.52222TCP运维通道这里有个细节值得说公网端口不一定和内网端口一致。上表把内网的 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: s192.168.1.10-203.0.113.5, d198.51.100.20 [12] NAT*: s198.51.100.20, d203.0.113.5-192.168.1.10 [12]第一行是出方向源地址被换成公网地址第二行是回方向目标地址被换回内网地址前面的星号表示这是快速路径转发的报文。看到这一对出现基本可以确认 NAT 工作正常。但debug在生产设备上要慎用流量大时 CPU 会明显上升建议配合 ACL 限制调试范围或者干脆在业务低峰期做。注意测试前先执行clear ip nat translation *清掉旧表项避免残留表项干扰判断。静态表项虽然不会老化但手工清除后会在下一条流量到达时重新建立不影响使用。3.4 NVI 方式新平台上的另一种写法老式配置依赖接口的 inside/outside 标记在新一代 IOS 平台上还有一种 NVINAT 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.5NVI 和传统方式不能混用同一台设备上要么全用ip nat inside/outside要么全用ip nat enable混着配会出现部分流量不转换的怪现象。我在一个迁移项目里就遇到过老配置没删干净新接口又加了ip nat enable结果内网能出去、外部进不来查了半天才发现两套逻辑在打架。迁移时的稳妥做法是先把旧 NAT 配置整体备份再逐条删除确认show ip nat statistics里没有残留表项最后再上新配置。4. 常见故障与排查技巧实录4.1 一张速查表覆盖八成问题静态NAT的故障现象翻来覆去就那么几类我把实际项目中遇到过的整理成下表按“现象—可能原因—确认方法”三列对照排查时从上往下走基本能在十分钟内定位。现象可能原因确认方法外部完全连不上设备上抓不到包运营商未路由公网地址或线路问题在 outside 接口抓包看是否有入向流量设备上能看到入向包但没有转换接口未标记 inside/outside或标记反了show ip nat statistics看接口列表有转换表项但回包不通内网服务器网关错误或回程路由缺失在服务器上tracert公网地址端口映射不生效地址级与端口级映射冲突show run部分来源能访问、部分不能outside 入方向 ACL 拦截show ip access-lists看匹配计数映射刚改完行为异常旧转换表项残留clear ip nat translation *后重测大文件传输中断MTU 或分片处理问题调整 MSS 或检查链路 MTU这张表里最值得展开的是“有转换表项但回包不通”。很多人看到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 natshow ip nat translations verbose会多出创建时间、剩余老化时间、使用的转换类型等信息。静态表项的剩余时间通常显示为--如果看到某条表项带倒计时说明它可能是动态产生的和你预期的静态映射不是一回事需要回头检查配置里是不是混进了overload或者地址池。还有一个细节clear ip nat translation *会清掉所有动态表项静态表项也会被清掉但会立即重建。在变更配置后、测试之前执行一次能避免“旧表项让新配置看起来不生效”的假象。我带新人时要求他们养成这个习惯就像改完 DNS 记录要清缓存一样。4.3 应用层协议的特殊处理静态NAT工作在 IP 层大多数 TCP/UDP 应用配好映射就能用但有几类协议会把地址信息藏在载荷里需要额外处理。FTP 主动模式就是典型服务器在控制连接里告诉客户端“来连我的某个地址和端口”如果服务器不知道自己在公网上对应的是哪个地址它告诉客户端的就是内网地址客户端自然连不上。解决办法是在设备上启用 NAT 的应用层网关功能让设备在转发控制报文时替换载荷里的地址。ip nat service ftp tcp port 21SIP、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的表项是永久的但业务不是永久的服务器下线、地址回收、合作方变更都需要有人知道这条映射的来龙去脉。我现在做任何静态映射都会同步更新一张共享的映射台账包含内网地址、公网地址、端口、协议、业务方、上线时间、预计回收时间配置和台账对不上就以台账为准去核查。这个习惯看起来笨但在设备多、人员流动大的环境里是最省事的办法。