静态NAT在Cisco IOS上就那么两三条命令ip nat inside、ip nat outside、ip nat inside source static看起来十分钟就能搞定。但我见过太多案例配置敲完之后现象是时而通时而不通、内网能出去、外网进不来、抓包看到地址根本没变最后翻来覆去查了半天问题既不在NAT语句本身也不在ACL而是接口方向标反了、回程路由不对称或者对NAT在转发流程里到底排第几步没有概念。这篇就把静态NAT从规划、配置、验证到排错整条链路拆开讲重点讲清楚为什么这么配而不是给你一堆抄完还是不会改的命令。适合刚接触企业网出口配置、或者手上有台设备要做地址映射但不敢下手的同行也适合已经会配、但排错时总是靠重启和清翻译表蒙混过关的人。1. 静态NAT真正解决的是哪几类问题1.1 一对一地址替换发生在转发的哪一步静态NAT的本质非常朴素在数据包穿过路由器的过程中把IP报文头里的源地址或目的地址换成一个你指定的地址并且这个替换关系是永久存在、不依赖流量触发的。这一点和动态NAT有根本区别——动态NAT需要先有内网主机发起流量才会临时生成一条翻译表项超时后消失静态NAT只要配置写进running-configshow ip nat translations里立刻就能看到一条带---标记的常驻条目。理解它的关键是把地址替换这件事放回路由器的转发流水线里看。一台路由器收到包之后大致会经历入接口ACL检查、路由查找、出接口ACL检查、转发。NAT就插在这条流水线中间而且方向不同插入的位置也不同这是后面所有排错逻辑的根。Cisco官方给出的顺序是内网到外网方向先做路由查找再做NAT转换外网到内网方向先做NAT转换再做路由查找。这个差异带来的直接后果是——外网访问内网服务器时路由器其实不需要有一条去往那个公网映射地址的路由只要包能送到这台路由器上就行而内网访问外网时如果路由表里没有去往目的地的条目包在NAT之前就被丢了你在翻译表里什么也看不到。所以很多人遇到的配了NAT但不生效八成不是NAT写错而是流量压根没到能做NAT的那一步。先把这句话记住后面排查能省掉大量时间。1.2 静态NAT、端口映射、动态NAT的适用边界这三个东西经常被混着叫实际选型逻辑很清楚。整机一对一映射ip nat inside source static 私网地址 公网地址适合需要双向主动访问的场景比如内网有一台服务器既要对外提供服务又要主动往外发起连接而且对端需要看到固定的源地址。端口级映射带tcp/udp关键字适合只开放特定服务、公网地址资源紧张的场景一个公网IP可以映射几十个不同端口到不同内网主机。动态NAT加地址池适合内网大量终端上网、但不需要被外部主动访问的场景它解决的是地址复用不是服务发布。选型上有个很实际的判断标准问一句外部能不能主动发起连接。能就必须用静态不能动态或PAT就够了。反过来如果只是为了让大家上网却给每台机器配静态一对一那是在白白消耗公网地址而且会把内网拓扑结构暴露出去。还有一类常被忽略的用法地址重叠场景下的静态NAT。两家单位的地址段撞了或者收购整合时私网地址重复靠ip nat outside source static把对方的地址翻译成一个本地唯一的地址段让内网主机以为在访问一个正常的地址。这种配置不难但坑最多第4节会专门讲。1.3 比NAT更容易出问题的前提条件配置静态NAT之前有三件事必须先确认否则后面全是白工。第一公网地址是否真的路由到了你这台设备。如果运营商只给了你一个接口地址你却在NAT里写了一个同网段的其他地址那这个地址的流量根本到不了你手上NAT配得再对也没用。要么让上游把整段路由指向你要么老老实实用接口地址做端口映射interface GigabitEthernet0/1这种写法。第二内网服务器的默认网关是否指向这台做NAT的路由器。服务器回包如果走的是另一台设备就会出现请求到了、响应回不去的经典半通现象。第三服务器本机的防火墙。我遇到过不止一次NAT翻译条目正常建立、双向计数都在涨但业务就是不通最后发现是主机上的过滤策略只放行了内网网段。这三条都不属于NAT配置范畴但它们决定了NAT能不能生效。做出口改造时我习惯先画一张流量走向图把谁发起、经过谁、回程走谁标清楚再动手敲命令。2. 动手之前先画表地址与接口的规划方法2.1 inside和outside到底怎么判定ip nat inside和ip nat outside不是内网口和外网口这种物理概念而是相对于NAT转换的语义方向。标记为inside的接口其连接的网络被视为被转换的一侧标记为outside的接口其连接的网络被视为转换后看到的一侧。所以判定标准只有一个这个接口连的是需要被隐藏/被转换的地址空间还是转换后要对外的地址空间。这里有两个硬性约束必须知道。同一个接口不能同时既inside又outside一个接口如果没被标记经过它的流量不会被NAT处理哪怕全局配置里静态条目写得再完整。子接口、VLAN接口、隧道接口都可以标记但标记要打在实际承载流量的那个逻辑接口上——比如用子接口做单臂路由时ip nat inside要配在GigabitEthernet0/0.10上而不是物理口上。还有一个隐蔽的坑如果一台路由器有多个内网口每个内网口都要单独标inside。漏标一个从那个口进来的流量就绕过了NAT表现为这个网段能用、那个网段不能用非常容易被误判成路由问题。2.2 一张规划表能挡掉八成返工我建议在配置之前把下面这张表填完填不出来的地方就是还没想清楚的地方。表格内容不需要多复杂但每一项都要有明确答案。规划项示例值说明内网服务器地址10.1.1.10/24必须是静态地址不能DHCP对外发布地址200.1.1.10/29需上游路由可达或改用接口地址映射粒度整机 / 单端口决定用哪种static语句协议与端口TCP 80、443端口映射必须写协议服务器网关200.1.1.2NAT路由器内网口回程路径的唯一出口是否需要内网回环访问是 / 否决定要不要处理hairpin问题上游ACL/安全策略放行 200.1.1.10:80别忘了上游设备也要放行这张表里最容易被跳过的是最后一行。很多时候你这边配得完美无缺问题出在更上游的过滤设备上而你没有那个设备的权限只能干等。提前确认能省掉几小时的扯皮。2.3 掩码与写法的几个易错点ip nat inside source static默认按主机/32处理写两个地址就是一对一。如果你想做整段映射要用network关键字并带上掩码例如ip nat inside source static network 10.1.1.0 200.1.1.0 /24。注意这里的掩码写法在不同IOS版本上兼容性不完全一致/24和255.255.255.0两种写法都见过稳妥起见用点分十进制形式兼容性更好。另一个易错点是不要在这里写反掩码。ACL里用的是通配符掩码wildcard maskNAT的network语句用的是正常子网掩码两者规则相反混用不会报错但映射结果会完全错乱而且症状极其诡异——某些地址能通、某些不能。我见过有人把/24写成0.0.0.255结果映射出一堆莫名其妙的地址。端口映射的写法要注意协议关键字的位置ip nat inside source static tcp 10.1.1.10 80 200.1.1.10 80协议紧跟在static后面然后依次是内网地址、内网端口、公网地址、公网端口。两边的端口号可以不同这就是端口转换比如把内网的8080映射成对外的80。这个能力在做服务迁移时特别有用可以不改应用配置就把服务端口对整齐。3. 命令逐条拆解每一行的作用与副作用3.1 接口标记的顺序与常见误操作配置顺序上先标接口、再写static条目是最稳的。反过来的话静态条目会立刻出现在翻译表里但因为没有接口被标记流量不会命中它容易让人误以为条目有了就应该通。正确的骨架是这样的interface GigabitEthernet0/0 description LAN ip address 10.1.1.1 255.255.255.0 ip nat inside no shutdown ! interface GigabitEthernet0/1 description WAN ip address 200.1.1.2 255.255.255.248 ip nat outside no shutdown !标记接口时有个细节值得说ip nat inside和ip nat outside是接口级命令但NAT功能本身是全局开启的不需要额外的ip nat enable。如果你在某个平台上看到ip nat enable这种写法那是NVINAT Virtual Interface模式属于另一套机制和传统的接口标记模式不能混用。混用的结果是部分流量走NVI、部分走传统NAT排查起来极其痛苦。选一套从头用到尾。还有一点接口上如果有ip access-group标记NAT不会影响ACL的检查顺序两者是独立的。但它们在流水线里的先后位置不同第6节会专门讲这个因为它直接决定了你ACL里该写公网地址还是私网地址。3.2 static语句的参数逐个说清楚最基础的整机映射长这样ip nat inside source static 10.1.1.10 200.1.1.10前半段ip nat inside source表示转换从inside方向发起的流量的源地址后面的两个地址依次是本地地址local和全局地址global。这条语句配下去效果是双向的内网10.1.1.10出网时源地址变成200.1.1.10外网访问200.1.1.10时目的地址变成10.1.1.10。很多人以为它只管出方向其实入方向也一起管了这也是为什么它能支持外部主动访问。extendable这个关键字值得单独提。当你需要给同一个公网地址配多条映射时比如一条整机映射加几条端口映射或者同一个公网IP对应多台内网设备的服务IOS会报%Similar static entry already exists。加extendable就能绕过这个检查允许多条相似条目共存。但要清楚它只是关掉了重复检测不会帮你判断哪条优先——实际命中哪条取决于具体匹配逻辑配之前一定要想清楚别指望它自动选对的。route-map参数用于条件化NAT只在特定条件下才做转换。这个在双出口、或者同一个内网地址需要按目的地址映射到不同公网地址的场景下有用。用法是在route-map里match目的地址或接口然后在static语句末尾引用。它属于进阶用法日常发布服务用不上但如果你的出口有两条线路、想让特定流量走特定地址出去这就是标准解法。公网地址是动态获取的场景比如接的是拨号链路把公网地址换成接口名即可ip nat inside source static tcp 10.1.1.10 80 interface GigabitEthernet0/1 80这样即使接口地址变了映射关系依然有效。3.3 端口级映射的配置与冲突处理发布单个Web服务配置是这样的ip nat inside source static tcp 10.1.1.10 80 200.1.1.10 80 ip nat inside source static tcp 10.1.1.10 443 200.1.1.10 443同一个内网主机、同一个公网地址、不同端口这是最常规的组合不需要extendable因为端口不同本身就区分开了。冲突通常出现在两种情况一是同一个公网地址既做了整机映射又做了端口映射二是两台内网主机抢同一个公网地址的同一个端口。前者用extendable能过后者是逻辑上无解的必须换地址或换端口。端口映射还有一个容易忽略的点它只对指定的协议生效。写了tcpUDP流量就不会被转换。有些应用同时用TCP和UDP比如某些语音、监控、游戏类服务必须两条都写。我见过配置完只有部分功能可用的案例查了很久才发现是漏了UDP那条。3.4 验证命令的正确用法配置完之后不要急着从外部ping先在设备上看三个东西。show ip nat translations看条目是否按预期建立静态条目在没流量时也会显示源和目的都带---这是正常的不代表流量通过了。show ip nat statistics看Hits和MissesHits增长说明有流量命中了翻译规则Misses增长说明有流量进来了但没匹配上任何规则——后者通常意味着地址写错或者方向标错。show ip nat translations show ip nat translations verbose show ip nat statistics clear ip nat translation *verbose会显示剩余老化时间、转换前后的详细五元组排查端口映射时特别有用。clear ip nat translation *用来清空动态条目注意它不会删除静态配置条目只清动态的所以放心执行——但会中断现有会话业务时段慎用。判断NAT到底有没有生效最直接的办法是对比翻译表里是否出现了带公网地址的五元组。如果表里只有静态条目、没有任何动态会话那就说明流量没到NAT这一步别再盯着NAT配置看了去查路由和接口标记。4. 三个典型场景的完整配置过程4.1 单端口发布最保守也最常用的方案场景是内网一台Web服务器需要对外提供访问公网只有一个可用地址还要留给其他服务共用。这时用端口映射公网地址可以是接口地址本身interface GigabitEthernet0/0 ip address 10.1.1.1 255.255.255.0 ip nat inside interface GigabitEthernet0/1 ip address 200.1.1.2 255.255.255.248 ip nat outside ! ip nat inside source static tcp 10.1.1.10 80 interface GigabitEthernet0/1 80 ip nat inside source static tcp 10.1.1.10 443 interface GigabitEthernet0/1 443 ! ip route 0.0.0.0 0.0.0.0 200.1.1.1为什么用interface而不是写死地址因为这样配置和接口地址解耦线路变更、地址调整时不用回来改NAT。代价是公网端口被占用同一端口不能再给别的服务用所以规划端口时要留出余量。配套的入向ACL建议显式写清楚ip access-list extended OUTSIDE-IN permit tcp any host 200.1.1.2 eq 80 permit tcp any host 200.1.1.2 eq 443 permit icmp any host 200.1.1.2 echo deny ip any any log interface GigabitEthernet0/1 ip access-group OUTSIDE-IN in注意ACL里写的是公网地址不是内网地址。原因在6.1节会展开这里先记住结论外网进来的包在outside接口入向ACL检查时还没有被翻译目的地址仍然是公网地址。4.2 整机一对一双向主动访问的正确姿势如果服务器既要对外提供服务又要主动往外建立连接且对端需要看到固定源地址那就用整机映射ip nat inside source static 10.1.1.20 200.1.1.20前提是200.1.1.20这个地址要能路由到你。如果是运营商给的地址段比如/29通常整段都路由过来了直接用就行。如果只有一个接口地址那就没法做整机映射只能端口映射。整机映射配完内网主机出网的源地址会变成200.1.1.20外网访问200.1.1.20会落到10.1.1.20。验证时从外部telnet 200.1.1.20 端口同时在设备上盯show ip nat translations应该能看到一条从公网地址到私网地址的入向会话。这里有个副作用要提醒整机映射会把内网主机的所有端口都暴露出去。如果这台机器上有管理端口、数据库端口等于全部对公网开放。所以整机映射必须配合严格的入向ACL只放行必要的协议其余一律deny。这一点经常被忽略因为它不像端口映射那样天然只开一个口。4.3 地址重叠最麻烦但绕不开的场景两个私网地址段撞车时比如内网用10.1.1.0/24要访问的对端也用10.1.1.0/24直接访问必然混乱。解法是在outside方向做源地址转换把对端地址翻译成一个本地唯一的地址ip nat outside source static 10.1.1.10 192.168.100.10 ip route 192.168.100.10 255.255.255.255 200.1.1.1配置的含义是从outside方向来的、源地址为10.1.1.10的包源地址被改写成192.168.100.10再交给内网。内网主机访问192.168.100.10路由器把它还原成10.1.1.10送出去。这里的关键是那条明细路由。因为内网到外网方向是先路由后NAT内网主机发出目的地址为192.168.100.10的包时路由器必须先能查到一条去往该地址的路由否则包在NAT之前就被丢了。如果设备上有默认路由指向outside接口理论上也能出去但明细路由更可控也避免与其他流量混淆。另外内网主机解析对端服务时DNS返回的必须是翻译后的地址192.168.100.10而不是原始地址。这一点如果没协调好会出现配置全对但访问不了的假象。我的建议是能用其他方案就别用重叠地址转换比如在整合初期就把地址段重新规划或者用应用层转发绕开。这类配置维护成本高接手的人往往看不懂属于技术债。5. 排错链路从不通到定位到具体那一行5.1 五步排查法按顺序走不要跳遇到配了不通我固定按这五步走基本能在十分钟内定位。第一步确认流量有没有到这台设备在内网口和outside口分别看接口计数show interface的input/output packets或者直接抓包。如果outside口根本没收到包问题在上游或对端跟NAT无关。第二步确认接口标记show running-config | include ip nat看inside/outside是不是标在了正确的接口上有没有漏标。第三步确认翻译表访问的瞬间连续刷show ip nat translations看有没有对应的会话建立。有会话但业务不通问题在主机侧没会话继续往下。第四步看show ip nat statistics的Hits和Misses变化Misses涨说明流量进来了但没匹配规则回头核对地址和端口。第五步检查ACL和上游策略特别注意ACL里写的是公网地址还是私网地址。这个顺序的价值在于每一步都能排除掉一大片可能性而不是东一榔头西一棒子地改配置。改配置是最不可取的做法因为你不知道哪一改起作用了下次再出问题还是不会。5.2 症状与原因的对照表现象最可能的原因处置方向内网出网正常外网访问不进来outside入向ACL拦了或ACL写了私网地址核对ACL匹配的是公网地址翻译表只有静态条目无动态会话流量没经过该设备或接口未标inside/outside查网关、查接口标记会话建立但业务不通服务器本机防火墙、回程路由不对称查主机策略与回程路径内网用公网地址访问自家服务失败回环hairpin问题内网DNS直接解析私网地址报错Similar static entry already exists同一公网地址重复映射合并条目或用extendable部分功能可用、部分不可用漏配UDP映射或只开了部分端口补齐协议与端口配置后原有业务中断新增条目覆盖了原有映射检查条目优先级与地址冲突这张表里最值得记住的是第一行和第四行。第一行是最高频的错误很多人下意识在ACL里写内网地址觉得反正最后会翻译成内网地址结果包在翻译之前就被ACL丢了。第四行则是典型的架构问题不是配置能彻底解决的。5.3 抓包与debug的边界debug ip nat能看到每一次转换的详细过程输出形如NAT: s10.1.1.10-200.1.1.10, d...信息量很大。但它对CPU的消耗在流量大的设备上非常可观生产环境不要随手开。要用就在维护窗口配合undebug all随时准备关掉或者用ACL限制debug范围只抓特定地址的转换。更好的替代方案是在出口两侧做镜像抓包看原始包和转换后的包对比既直观又不影响设备性能。另一个实用技巧是看show ip nat statistics里的Dynamic translations和Extended translations数量如果这个数字一直在涨且不回落说明有大量短连接或异常流量可能与超时设置有关。默认TCP会话超时是86400秒UDP是300秒短连接场景下可以适当调小避免翻译表被占满。6. 几条文档里不会写的实操心得6.1 ACL和NAT在流水线里的先后决定了你写哪个地址这是我认为最容易踩、也最值得讲清楚的一点。不同方向、不同接口的ACL看到的地址是不一样的。外网进来的包在outside接口入向ACL检查时还没做NAT所以ACL里必须写公网地址内网出去的包在outside接口出向ACL检查时已经做完NAT所以ACL里要写公网地址转换后的源。而inside接口的入向ACL看到的是原始私网地址因为那时还没开始转换。记不住的话就记一句话outside口上的ACL一律按公网地址写。这个结论覆盖了绝大多数场景能挡掉大部分ACL写错的问题。我曾经为了一个外网访问不进来的问题查了两个小时最后发现ACL里写的是permit tcp any host 10.1.1.10 eq 80而流的真实目的地址是200.1.1.10。另外提醒一句NAT本身不做任何安全过滤。它只是地址替换不检查内容、不限制方向。很多人误以为内网地址对外不可见就安全了这是错觉。该配的ACL一条都不能少尤其是整机映射场景。6.2 变更前留后路变更后清会话NAT相关的变更有个特点改配置不会立即中断已有会话但清翻译表会。所以操作顺序应该是先备份、再改配置、验证新条目生效、最后在业务低峰清一次翻译表让旧会话重建。反过来做很可能在改配置的瞬间就把线上业务打断了。具体操作上我习惯先show running-config | section ip nat把现有条目导出留档改完之后对比差异。删除条目用完整的no形式注意端口映射的no语句必须把协议、端口全部带全少一个参数就删不掉会提示语法错误。这类细节看着琐碎但在紧急回滚时能省下关键的一两分钟。还有一个经验新增映射尽量用新的公网地址或新端口不要去改动已有的映射关系。改动意味着风险新增意味着隔离。地址资源紧张时宁可多规划几个端口也不要在一条正在服役的条目上做文章。6.3 规模、性能与回环访问的现实约束静态NAT条目本身对性能影响很小因为它是查表匹配不涉及复杂的会话管理。真正影响性能的是并发会话数和平台的转发架构。低端设备做NAT时可能从硬件快转退化为软件转发吞吐会明显下降中高端平台通常有硬件加速show ip nat statistics里的计数行为也可能和软件转发不一致排查时不要只看计数下结论。规模上要注意翻译表的上限可以用ip nat translation max-entries限制防止异常流量把表打满导致正常业务无法建立会话。这个值要根据设备内存和实际并发量来定没有通用数字建议先观察一段时间的峰值再设。最后说说回环访问这个老问题。内网用户用公网地址访问自己内网的服务器流量会从inside口进来、又需要从同一个inside口出去很多平台对这种同接口进出的处理并不理想表现为时通时不通或者完全不通。业内的常规做法是内网DNS分离内网用户解析到私网地址外网用户解析到公网地址从源头上避开回环。这比在设备上折腾NVI或者各种变通配置要干净得多也更容易维护。如果条件允许我强烈建议走DNS分离这条路别在NAT上硬扛。补一个小技巧收尾给每条静态映射加注释。Cisco的配置里可以用!开头的行写说明或者用description挂在接口上把这条映射是给谁用的、什么时候加的、找谁确认写清楚。半年后接手的人很可能就是你自己会感谢这个习惯。NAT配置最怕的不是配错而是配了一堆看不懂为什么存在的条目没人敢删也没人知道能不能删。