网络里最容易把人绕晕的一组词公网、私网、内网、外网绝对排得上号。我自己刚入行那会儿配个端口映射能对着路由器后台发呆半小时明明本机服务跑得好好的外面就是访问不进来后来做远程办公、搭家庭小服务器、给门店装监控回传这类问题更是反复出现。这篇就围绕NAT、内网穿透与远程访问这条主线把公网私网内网外网这几个概念彻底掰开揉碎讲清楚它们各自指什么、为什么会打架、NAT 到底在背后做了什么、内网穿透又是怎么在限制条件下把路打通的。内容偏实战适合刚接触网络配置的运维新手、想在家里搭服务的技术爱好者、需要做远程访问方案的技术负责人也适合那些被为什么我这边能访问、你那边访问不了折磨过的朋友。看完你至少能做到拿到一个访问不通的场景能快速判断问题卡在哪一层而不是盲目重启路由器和改防火墙。1. 先把四个词摆正公网私网内网外网到底在说什么1.1 四个词不是同一维度的概念混着用必然乱很多人把公网和外网当同义词、私网和内网当同义词日常沟通勉强能用一旦落到配置层面就会出问题。原因在于这四个词其实分属两个不同的分类维度。第一个维度是地址属性公网地址和私网地址。这是 IP 地址规划层面的概念说的是这个地址在全球范围内是否唯一、是否可被路由。公网地址由地址分配机构统一管理全球唯一任何接入互联网的设备理论上都能路由到它私网地址则是 RFC 1918 预留的三段地址空间只在局部网络内有意义不同局域网里可以重复出现。第二个维度是网络位置内网和外网。这是拓扑和视角层面的概念说的是你站在哪个网络的边界内侧还是外侧。对一家公司来说办公网是内网互联网是外网但对运营商来说它自己的承载网也算内网。所以内网是相对的取决于你以谁为参照系。把这两个维度交叉起来就出现了四种组合其中最常见也最容易混淆的是私网地址的内网和公网地址的外网。真正让人头大的是中间地带一个私网地址的设备通过 NAT 借用一个公网地址出去它到底算内还是外答案是地址是私有的出口是公有的位置是内网但对外表现为公网。这一层借壳关系就是后面所有问题的根源。1.2 三段私网地址的来历与选择习惯RFC 1918 划定的三段私网地址做网络规划的人几乎天天见地址段掩码范围可用地址数量级典型使用场景10.0.0.0/8约 1677 万大型企业、云上 VPC172.16.0.0/12约 104 万中型网络、容器网络192.168.0.0/16约 6.5 万家庭、小型办公为什么家庭路由器和门店设备清一色用 192.168 段不是技术上更优而是习惯和默认值。几乎所有消费级路由器的出厂 LAN 口配置都是 192.168.0.1 或 192.168.1.1厂商为了降低用户上手成本把这个段做成了事实标准。而云上环境偏爱 10 段是因为 /8 的空间足够划分大量子网做多 VPC 互联时不容易撞车。这里有个实操细节值得说如果你要做多地组网或者和合作方做专线互联提前确认对方用的私网段两边都用 192.168.1.0/24 是最常见的翻车点。地址重叠之后路由表里同一个目标网段指向两个方向流量要么走错要么直接丢弃排查起来非常费劲。我一般建议内部规划时避开 192.168.0/24 和 192.168.1/24 这两个重灾区用 192.168.100.0/24 之类不那么热门的段。1.3 内网外网是相对的别拿绝对视角套再强调一遍内网外网的相对性因为这是判断能不能访问的关键。你家里的电脑访问自家 NAS走的是内网速度快、延迟低、不消耗公网带宽你在公司访问家里 NAS对家里来说这是来自外网的访问必须经过公网绕一圈。判断一个访问是不是内网访问看的是源和目的是否在同一广播域或同一路由可控的私有网络内而不是看设备长什么样。同一个交换机下两台机器互访是内网跨城市两个分支机构通过专线互访物理上走了很远但逻辑上仍在同一个私有网络体系内通常也按内网对待。这个相对性带来的直接后果是同一个服务内网能访问不代表外网能访问反过来也一样。很多新手在家里的电脑上测试服务正常就以为大功告成结果同事从外面访问不了然后开始怀疑代码。其实代码没问题是 NAT 和防火墙把路挡住了。养成分内外两个视角各测一遍的习惯能省掉大量无效排查。2. NAT 到底做了什么地址借用的完整逻辑2.1 没有 NAT 的世界会怎样要理解 NAT先想象没有它的世界。IPv4 地址总共约 43 亿个全球联网设备早就超过这个数量。如果每个设备都必须有独立公网地址地址池早就枯竭了。NAT网络地址转换的核心使命就是让多个私网设备共享少量公网地址上网本质是一种地址复用机制。打个生活化的比方一栋写字楼只有一个对外收发室公网地址楼里几百个工位私网设备都要寄收快递。寄件时收发室把每个工位的寄件统一盖上写字楼的地址章发出去收件时收发室根据自己记录的这单是哪个工位寄的把回件分派回去。NAT 设备就是这个收发室它维护一张转换表记录内网某地址某端口和外网某地址某端口的对应关系。这个机制解决了地址短缺但也带来一个根本性限制外部主动发起的连接NAT 设备不知道该转给谁。因为转换表里没有这条记录收发室没见过这个工位寄过件自然不知道怎么派。这就是为什么家里电脑不配置任何东西就能上网但外面的人想主动连进来却连不上——不是网络不通是 NAT 没有对应的映射条目。2.2 SNAT 与 DNAT出方向和入方向的两套规则NAT 具体分两种方向理解这两者是后面所有配置的基础。SNAT源地址转换处理的是内网主动访问外网的场景。内网设备发包出去NAT 设备把源地址从私网地址改成公网地址同时改源端口并在转换表里记一笔。回包到达时NAT 设备查表把目的地址改回原来的私网地址和端口。这是家用路由器默认就在做的事用户完全无感。DNAT目的地址转换处理的是外部主动访问内网的场景也就是常说的端口映射、端口转发。管理员手动配置一条规则访问公网地址的 8080 端口转发到内网 192.168.1.100 的 80 端口。外部请求到达时NAT 设备按规则改目的地址转发进内网。这条规则是静态的、需要人工配置的这也是为什么端口映射不能自动生效。两者的关键差异在于触发方式SNAT 由内网流量自动触发转换表动态生成、有老化时间DNAT 由管理员预先配置规则常驻。搞不清这个区别就会出现我能上网为什么别人连不上我的困惑——上网走的是 SNAT别人连你走的是 DNAT两码事。2.3 转换表的生命周期与端口耗尽问题NAT 转换表不是永久的每条记录都有老化时间TCP 连接通常几分钟到几小时不等UDP 更短。连接空闲超时后记录被回收端口释放。这个机制本身合理但会带来两个实战问题。第一个是长连接被中途掐断。某些应用需要长时间保持连接如果中间有 NAT 设备且老化时间短于应用的心跳间隔连接会被静默回收表现为用着用着突然断了重连又好了。解决办法是在应用层加心跳间隔小于 NAT 老化时间。很多即时通讯和远程控制软件都有这个机制不是多余设计。第二个是端口耗尽。一个公网地址理论上可用的端口约 6.4 万个如果内网设备多、并发连接多端口可能不够分。家用场景基本遇不到但企业出口、高并发代理场景要留意。缓解手段包括增加公网地址、缩短老化时间、限制单设备并发数。我见过一个内网爬虫集群把出口 NAT 端口打满导致整个办公网访问外网间歇性失败最后靠限流加多出口解决。注意排查NAT 相关问题时先确认是 SNAT 侧还是 DNAT 侧。SNAT 侧问题表现为上不了网DNAT 侧问题表现为外面连不进来两者排查路径完全不同别混着查。3. 内网穿透在 NAT 限制下把路打通3.1 为什么端口映射经常配不了理论上配个 DNAT 就能让外部访问内网服务但现实中大量场景根本配不了端口映射原因主要有三类。第一类是没有公网地址的控制权。很多宽带接入方式下用户拿到的所谓公网 IP其实是运营商级 NAT 后面的地址路由器 WAN 口显示的地址和实际出口地址不一致。这种情况下你在自己路由器上配端口映射映射的是运营商 NAT 内侧外部根本到不了这一层。判断方法很简单查一下路由器 WAN 口地址再对比外部看到的出口地址不一致就是处在运营商 NAT 后面。第二类是没有权限改上游设备。租房、共享办公、校园网等环境你只能碰自己的设备上游路由器和防火墙不归你管端口映射无从谈起。第三类是安全策略不允许。即使有公网地址和控制权很多单位的安全规范也不允许随意开放入站端口暴露面越大风险越高。这三类场景催生了内网穿透这套方案既然从外往里主动连不进去那就让内网设备主动向外建立一条连接把这条连接当作通道外部流量顺着通道反向送进来。这正好绕开了 NAT 只允许内网主动发起连接的限制。3.2 反向连接的核心思路内网穿透的基本模型是内网侧运行一个客户端主动连接公网侧的一个服务端建立一条持久通道外部用户访问公网服务端的某个入口服务端把流量通过已建立的通道转发给内网客户端客户端再转给本地服务。整个过程中连接始终是内网主动发起的NAT 转换表里有对应记录回包能正常通过。这个模型和端口映射的本质区别在于谁先发起连接。端口映射是外部先发起需要 NAT 有静态规则内网穿透是内部先发起NAT 的动态转换表就够用。理解了这一点你就明白为什么内网穿透几乎不受 NAT 类型限制——它压根不依赖入站规则。通道建立后还要解决多路复用的问题一条 TCP 通道上要承载多个外部请求需要协议层做分帧和标识。常见实现有基于长连接的隧道协议也有基于标准加密传输的方案。选型时关注三点通道稳定性断线重连机制、传输效率是否有多路复用和压缩、以及是否支持多种协议TCP、UDP、HTTP。3.3 常见方案的类型划分与取舍市面上的内网穿透方案大致分三类各有适用边界方案类型典型特征优点局限自建中转服务自己租公网服务器跑服务端数据自主可控、无第三方限制需要维护服务器、有带宽成本托管穿透服务使用第三方提供的穿透平台开箱即用、免运维依赖第三方、免费额度有限点对点直连借助信令协商后两端直连延迟低、不占中转带宽NAT 类型苛刻时打洞失败需回退自建方案适合对数据流向有要求、且有一定运维能力的场景比如企业内部服务远程访问。托管方案适合个人快速验证、临时演示。点对点直连在两端 NAT 都较宽松时体验最好但对称型 NAT 下打洞成功率低必须有中转兜底。选型时我一般建议先问三个问题数据敏感度如何、预算多少、运维人力有没有。三个答案基本能锁定方案类型。别一上来就追求最先进的点对点很多场景下稳定的中转反而更省心。4. 远程访问实战从需求到落地的完整流程4.1 需求拆解先想清楚访问谁、从哪访问、要多稳动手配置前把需求拆成三个维度能避免大量返工。访问对象是单台设备的某个端口还是一整个内网网段单端口用端口映射或简单穿透即可整个网段需要网对网隧道配置复杂度高一个量级。访问来源固定办公点、移动设备、还是不确定的第三方来源固定可以加白名单安全性好来源不固定要考虑认证机制。稳定性要求临时调试、日常使用、还是生产依赖临时调试怎么快怎么来生产依赖要考虑冗余、监控、故障切换。这三个维度定下来方案基本就清晰了。我见过最常见的错误是需求没想清楚就开干配到一半发现还要支持手机访问还要能传大文件推倒重来。4.2 环境准备与前置检查清单正式配置前按这份清单过一遍能挡掉大部分低级问题确认出口地址类型路由器 WAN 口地址与外部探测到的出口地址是否一致判断是否在运营商 NAT 后。确认本地服务正常在内网另一台设备上访问目标服务的 IP 和端口确保服务本身没问题。确认防火墙放行目标设备本机防火墙、内网安全组、上游防火墙三层都要检查任何一层拦截都会导致不通。确认端口未被占用netstat -tunlp或ss -tunlp查看监听状态避免端口冲突。记录当前网络拓扑画一张简单的地址和连接关系图出问题时对照排查。第 2 步特别重要。太多人跳过本地验证直接配穿透结果折腾半天发现是服务压根没起来。永远先证明内网能通再解决外网能通这是排查的基本顺序。4.3 端口映射的配置要点与验证方法在有公网地址和控制权的场景下端口映射是最直接的方案。以常见家用或小型办公路由器为例配置路径通常在端口转发虚拟服务器NAT 设置这类菜单下。配置时需要填四项外部端口、内部地址、内部端口、协议类型。外部端口建议不要用 80、443、22 这类常见端口减少被扫描的概率内部地址填目标设备的固定 IP所以目标设备要先做静态地址绑定或 DHCP 保留否则重启后地址变了映射就失效协议类型按服务实际用的选 TCP 或 UDP不确定就两个都配。配完之后的验证顺序很关键# 第一步内网验证服务本身 curl -v http://192.168.1.100:8080/ # 第二步从外部网络验证映射是否生效 curl -v http://公网地址:外部端口/ # 第三步确认端口在外部是否可达 nc -zv 公网地址 外部端口如果第一步通、第二步不通问题在映射或上游拦截如果第二步通但应用异常问题在应用层配置比如 Host 头校验、跨域限制。分层验证能快速定位比盲目改配置高效得多。提示部分路由器修改端口映射后需要重启生效部分即时生效。改完先测不通再考虑重启别养成改啥都重启的习惯会掩盖真实问题。4.4 内网穿透的部署与联调以自建中转方案为例完整流程分服务端和客户端两侧。服务端部署在具有公网地址的服务器上核心是监听一个入口端口接受客户端注册并按规则转发流量。部署时注意服务端防火墙要放行入口端口服务端本身要有足够的带宽和稳定的网络建议配置进程守护异常退出能自动拉起。客户端部署在内网目标设备或同网段设备上配置中转服务端地址、认证凭据、本地服务地址和端口。启动后观察日志确认已连接服务端隧道建立成功这类状态。客户端要配置断线重连网络抖动后能自动恢复。联调阶段按这个顺序走客户端日志确认隧道建立成功。服务端日志确认收到客户端注册。从外部访问服务端入口观察服务端是否收到请求、是否转发。客户端日志确认收到转发请求、是否成功连本地服务。本地服务日志确认收到请求。任何一环断了日志都会告诉你卡在哪。这套逐跳看日志的方法比抓包更省时间尤其适合新手。4.5 安全加固别让通道变成后门穿透通道一旦建立等于给内网开了一个入口安全加固不能省。认证客户端与服务端之间必须有强认证别用默认凭据别用弱口令。有条件上证书或密钥对。最小暴露只映射真正需要的端口不要图省事把整个网段或管理端口暴露出去。管理后台、数据库端口这类高危服务尽量不直接暴露需要时通过跳板或临时开启。访问控制服务端入口加来源白名单或额外认证层减少被扫描利用的可能。日志与监控记录连接来源、访问目标、流量大小异常访问能及时发现。定期看日志别等出事才翻。及时更新穿透软件本身也是攻击面保持版本更新关注安全公告。我踩过的一个坑早期图方便把内网一台测试机的所有端口通过穿透暴露出去结果被扫描到弱口令的数据库端口虽然只是测试数据但教训很深。暴露面永远比你想象的危险能少开一个端口就少开一个。5. 常见问题排查与避坑经验5.1 典型故障速查表现象可能原因排查方向内网能访问外网不能端口映射未配或未生效检查 DNAT 规则、上游是否拦截映射配了仍不通处在运营商 NAT 后对比 WAN 口地址与出口地址时通时不通NAT 老化或链路抖动查转换表老化时间、加心跳穿透客户端连不上服务端服务端端口未放行或地址错检查服务端防火墙、地址端口隧道建立但访问无响应本地服务地址或端口配错核对客户端本地目标配置访问慢中转带宽不足或绕路看中转节点位置和带宽规格连接被重置安全策略或协议不匹配检查防火墙规则、协议类型这张表覆盖了大部分高频问题遇到故障先对号入座能快速缩小范围。5.2 三个容易忽略的细节MTU 问题。穿透隧道封装会增加包头如果链路 MTU 本来就接近上限封装后可能超限导致大包被丢弃表现为小请求正常、大文件传输卡死。解决办法是调整隧道 MTU 或开启分片。这个坑很隐蔽因为 ping 小包永远正常。DNS 与 Host 头。通过穿透访问 Web 服务时如果应用做了 Host 头校验或域名绑定用 IP 直接访问可能被拒。需要在应用层配置允许的 Host或在客户端做 Host 重写。时间同步。涉及证书认证的穿透方案两端时间偏差过大会导致认证失败。确保两端都配置了时间同步别忽略这个看似无关的细节。5.3 我的排查心法排查网络问题我总结成一句话先分层再逐跳最后看日志。分层是指按物理、地址、路由、端口、应用逐层确认别跳层猜。逐跳是指沿着数据路径一段段验证找到第一个不通的点。看日志是指优先看设备和应用的日志比抓包快得多抓包留到日志说不清的时候用。还有一条改动一次只改一个变量。同时改三个配置然后测试通了不知道哪个起作用不通不知道哪个搞坏。这个习惯在复杂环境里尤其重要。6. 方案选型的决策框架6.1 按场景对号入座把前面内容收拢成一个决策路径实际选型时按这个走有公网地址且有控制权需求简单端口映射最直接。有公网地址但不想暴露入站端口自建穿透内网主动外连。无公网地址或无控制权穿透方案自建或托管按数据敏感度选。两端网络条件好、追求低延迟点对点直连失败回退中转。临时演示、快速验证托管穿透服务省事优先。6.2 成本与可控性的权衡自建方案的前期投入是服务器和配置时间长期看可控性最好托管方案前期几乎零投入但依赖第三方免费额度、带宽、稳定性都受制于人。数据敏感的场景我倾向自建哪怕多花点运维精力纯个人临时用托管更划算。带宽成本常被低估。中转方案下所有流量都走中转服务器带宽费用和延迟都取决于中转节点质量。如果传输量大这笔账要提前算清楚别等账单出来才后悔。6.3 可扩展性预留方案落地时留一点扩展余地地址规划别用满、端口分配留余量、隧道配置支持后续加节点。我见过不少小项目一开始图省事硬编码地址后来加设备加分支改得鸡飞狗跳。前期多花十分钟规划后期少花十小时返工这话在网络上尤其成立。7. 最后分享几个实操心得配置这类东西文档看再多不如自己动手搭一遍。我的建议是找一个周末用一台旧电脑或云上最低配的服务器把端口映射、自建穿透、点对点直连各搭一次每个方案都故意制造一次故障再修好。这一轮下来你对 NAT 和穿透的理解会比看十篇文章都扎实。另外一个习惯给每个配置写注释和记录。路由器上的映射规则、穿透客户端的配置项过三个月你自己都未必记得为什么这么配。写清楚这条规则是给哪个服务用的、什么时候加的、谁维护团队协作时能救命。还有遇到玄学问题别急着归因于网络不稳定。绝大多数所谓玄学背后都是某个没注意到的配置或策略。静下心按分层逐跳的方法查基本都能找到根因。网络这东西看着抽象其实每一步都有迹可循把路径理清楚问题就无处藏身。