企业官网建设流程全解析

两个不同网段的 IP 地址要通起来，靠的从来不是"网线插对了就行"，而是主机判断、ARP 解析、二层封装、路由器查表、回程路由这一整条链路每一环都成立。我见过太多人卡在 ping 不通上，一会儿怀疑网线，一会儿怀疑交换机，最后发现是掩码少写了一位或者网关填错了网关地址。这篇就把 192.168.1.10/24 找 192.168.2.20/24 这个最典型的场景从头拆到尾，把每一步"谁在做什么决定、为什么这么决定"讲清楚，同时把抓包验证的方法和常见配置坑一并摆出来。适合刚接触网络排障的朋友，也适合做过几年但一直靠 ping 和重启解决问题的同行对着梳理一遍思路。

1. 跨网段通信这件事，先别急着敲命令

1.1 把实验场景固定下来，后面所有讨论才有落点

聊跨网段通信最怕场景含糊，一会儿说公网一会儿说内网，一会儿说 VLAN 一会儿说路由，最后谁也说不清包里到底装了什么。所以我先把场景钉死：主机 A 的地址是 192.168.1.10，掩码 255.255.255.0，网关 192.168.1.1；主机 B 的地址是 192.168.2.20，掩码 255.255.255.0，网关 192.168.2.1；中间一台路由器，两个接口分别落在 192.168.1.0/24 和 192.168.2.0/24 这两个网段里。A 和 B 之间不直连，中间隔着这台路由器。

这个拓扑看着简单，但它是所有跨网段问题的原型。你后面遇到的跨 VLAN、跨机房、跨专线、跨云上 VPC，本质上都是这个模型的放大版，只是中间的"路由器"从一个物理盒子变成了三层交换机、防火墙、云网关或者一堆路由器的组合。把两台主机和一台路由器之间的交互搞透，复杂环境里你也能一层一层剥开看。

我特别建议刚开始动手的时候真的搭一次这个环境，用模拟器也行，用两台虚拟机加一台软路由也行。原因很实在：跨网段通信的关键动作发生在"你平时看不到的地方"——ARP 请求、路由表查询、TTL 递减，这些东西只看文档很难形成直觉。自己搭一遍，抓一次包，那些概念才会落地。

提示：搭实验环境时，务必确认两台虚拟机的网卡分别桥接到不同网段，或者干脆用三个虚拟网络。如果图省事把两块网卡都挂在同一个虚拟交换机上，后面观察到的一切现象都是假的，白折腾。

1.2 同网段靠广播直达，跨网段必须有人"转手"

同一网段内的两台主机通信，逻辑上非常朴素：A 用自己的掩码算出目标也在本网段，于是直接在本地网络里喊一声"谁是 192.168.1.20"，对方应答，A 拿到对方的 MAC 地址，把数据封装成以太网帧直接丢出去，交换机按 MAC 地址表转发，事情就完了。整个过程没有任何"第三方"参与判断，二层设备只负责把帧送到对应的端口上。

跨网段就完全是另一套玩法了。A 用掩码算出目标不在本网段，它自己没有任何办法直接把帧送到目标所在的网络里——因为以太网帧的作用范围就是本地广播域，出去就没了。这时候 A 只能把包交给一个"有路子的人"，也就是默认网关。网关收到之后，拆开看目的 IP，查自己的路由表，决定从哪个接口、发给哪个下一跳，重新封装成新的帧再发出去。

所以两种通信的本质区别在于：同网段是端到端直接交付，跨网段是逐跳接力转发。这个区别直接决定了后面所有行为——ARP 请求谁、帧的 MAC 地址填谁、TTL 会不会变、出问题时该在哪一层排查。很多人排错排不下去，根子就在于脑子里没有这根弦，把跨网段当成同网段在查。

还有一个容易被忽略的点：跨网段通信里，源 IP 和目的 IP 全程不变，但源 MAC 和目的 MAC 每一跳都在变。这是理解整个转发过程最关键的一把钥匙。如果你抓包时看到 MAC 变了就以为出问题了，那说明这层还没打通。

2. 掩码与运算：主机自己先做的那道选择题

2.1 一次按位与，决定了包是"自己送"还是"交给别人送"

主机在发包之前做的第一件事，不是查路由表，而是回答一个非常朴素的问题：这个目的地址跟我在不在同一个网络里？回答方式就是把目的 IP 和自己的掩码做一次按位与，再把自己的 IP 和自己的掩码做一次按位与，两个结果比一比。

拿 A 找 B 举例。A 的 IP 是 192.168.1.10，掩码 255.255.255.0，与运算之后网络号是 192.168.1.0。目的地址 192.168.2.20 与 255.255.255.0 做与运算，得到 192.168.2.0。两个网络号不一样，结论就是"不在本网段"。于是 A 不会去 ARP 192.168.2.20，而是转去查自己的路由表，找一条能到达 192.168.2.0 的路径。

这里有个细节值得说清楚：主机判断"在不在同一网段"只看掩码，不看网关，也不看路由器怎么想。也就是说，掩码是主机自己的世界观，它认为世界长什么样，就按什么样去发包。如果两台主机的掩码认知不一致，就会出现一方认为"咱俩是邻居"，另一方认为"咱俩得靠网关联系"，通信行为立刻错位。

按位与的计算其实不难，难的是很多人只记结论不记过程，一出问题就懵。我一般教人的时候会让对方手算一遍：把 192.168.1.10 和 255.255.255.0 写成二进制，逐位与，前面三段全保留，最后一段清零，得到 192.168.1.0。多算几次，掩码长度和网段边界的关系就刻在脑子里了，看到 /22、/23 这种也能一眼估出范围。

2.2 掩码差一位，通信行为可能完全反过来

掩码配错是跨网段问题里最隐蔽的一类，因为它经常表现成"有时候能通有时候不通"或者"能 ping 通网关但 ping 不通对面的主机"。下面这张表是我整理过的几种典型错配，以及它们导致的后果，可以对着自己的环境核一遍。

表里第二行是最容易踩的：两台机器都配了 /16，各自认为 192.168.1.x 和 192.168.2.x 属于同一个大网段，于是 A 直接发 ARP 广播找 B。问题是 ARP 广播出不了路由器，B 永远收不到，A 就一直卡在"解析中"。表现出来就是 ping 一直不通、ARP 表里目标条目是 incomplete，而网关却 ping 得通。这时候如果你去查路由、查防火墙，方向全错，问题就出在掩码上。

还有一种更绕的情况：同一台交换机下两台主机，一台 /24 一台 /25。192.168.1.10/25 认为自己的网段是 192.168.1.0 到 192.168.1.127，而 192.168.1.200/24 在它眼里属于"别的网段"，于是它把包丢给网关。可网关如果没配好或者根本没有，包就死在半路。两台机器网线插在同一个交换机上，物理上近在咫尺，逻辑上却隔着一条不存在的河，这种问题不查掩码是查不出来的。

提示：排查跨网段问题时，第一件事永远是把两端的 IP、掩码、网关三项抄出来并排列在一张纸上。别嫌土，这一步能省掉后面至少一半的无效排查。

3. 交给网关之前，主机还要做一轮准备工作

3.1 为什么 ARP 的是网关，而不是最终目标

A 判定目标不同网段之后，接下来要把包交给网关 192.168.1.1。但"交给网关"这句话在以太网里得落到实处——必须封装成一个帧，帧的目的 MAC 得是网关接口的 MAC 地址。问题是，A 手上只有网关的 IP，没有网关的 MAC，所以要先做一次 ARP。

这里是最容易让人转不过弯的地方：A 在整个过程中根本不知道 B 的 MAC 地址，也不需要知道。它只需要知道网关的 MAC。最终目标 B 的 MAC 是在最后一跳由路由器去解析的，跟 A 没关系。这也解释了为什么跨网段抓包时，A 发出的帧目的 MAC 是路由器的，而源 IP、目的 IP 仍然是 A 和 B 的——三层地址端到端，二层地址逐跳。

ARP 请求本身是一个广播帧，目的 MAC 全 F，内容是"谁的 IP 是 192.168.1.1，请告诉我你的 MAC"。这个广播只在本地广播域内传播，路由器接口收到后发现问的是自己，就回一个单播的 ARP 应答，把自己的 MAC 告诉 A。A 把这个映射存进 ARP 缓存，带老化时间，一般几分钟到几十分钟不等，老化之后再通信要重新解析。

如果 A 的 ARP 缓存里已经有网关条目，这一步就跳过了。所以你会看到一种现象：第一次 ping 的时候丢一两包或者延迟偏高，后面就稳定了。这不是网络不稳，是 ARP 解析和缓存建立的过程。用arp -a（Windows）或ip neigh（Linux）能看到这些条目，超时状态一般标成 REACHABLE，正在解析的标成 INCOMPLETE。

3.2 帧封装完成之后，交换机只认 MAC 不认 IP

A 拿到网关 MAC 之后，把数据封装成一个完整的以太网帧：源 MAC 是自己的网卡 MAC，目的 MAC 是网关接口 MAC，帧里装的是 IP 包，IP 包的源地址 192.168.1.10、目的地址 192.168.2.20、协议号 1（ICMP）、TTL 初始值通常是 64 或 128，取决于操作系统。

封装好之后帧被送到交换机。交换机只看目的 MAC，查自己的 MAC 地址表，找到对应端口，把帧从那个端口送出去。整个过程它完全不看 IP 地址，也不知道里面装的是 ICMP 还是 HTTP。如果 MAC 地址表里查不到目的 MAC，交换机就泛洪到同 VLAN 的所有端口，等应答回来再学习。

这里有个实践中的观察点：如果 A 和网关之间隔着交换机，而网关 MAC 学习不到，帧就会被泛洪甚至丢弃。表现是 A 的 ARP 表里有网关条目但状态异常，或者 ARP 请求发出去了没有应答。这时候要查的就不是 IP 层，而是链路层和 VLAN 配置——比如网关接口和 A 是不是在同一个 VLAN 里，交换机端口是不是划错了，有没有做端口隔离。

还有一种情况是网关配置了"ARP 代理"或者中间有设备在做二层隔离。代理 ARP 的效果是让主机以为目标就在本网段，实际由代理设备代为转发。这种做法在某些老环境里能见到，好处是主机不用配网关，坏处是排错时现象和正常情况完全不同，容易误判。我个人不太建议在新环境里用代理 ARP，出了问题排查成本太高。

4. 路由器拿到包之后，真正的转发决策才刚开始

4.1 拆帧、查表、重封装，三步走完一个转发

路由器从接口收到帧，第一件事是校验并剥掉以太网头部，把里面的 IP 包取出来。然后看目的 IP 是 192.168.2.20，不是自己的接口地址，说明需要转发。接着查路由表，找一条匹配 192.168.2.20 的路由条目。

路由表的匹配规则是从掩码最长的条目开始比，这就是最长前缀匹配。假设路由表里有这么几条：一条是直连的 192.168.1.0/24 出接口是 eth0，一条是直连的 192.168.2.0/24 出接口是 eth1，还有一条默认路由 0.0.0.0/0 指向某个上游。目的地址 192.168.2.20 会同时匹配 192.168.2.0/24 和 0.0.0.0/0，因为 /24 比 /0 长，所以选中直连那条，从 eth1 出去。

选定出接口之后，路由器把 TTL 减 1，从 64 变成 63，重新计算头部校验和，然后重新封装以太网帧：源 MAC 换成 eth1 接口的 MAC，目的 MAC 填 B 的 MAC。B 的 MAC 怎么来？还是 ARP。如果路由器 ARP 缓存里没有，就发 ARP 请求，这个请求只在 192.168.2.0/24 这个广播域里传播，B 收到后应答。拿到 MAC 之后，帧从 eth1 发出去，B 收到，发现目的 IP 是自己，剥掉帧头，把 ICMP 报文交给上层处理，一个完整的"去程"才算走完。

这个过程中有几个数字值得记住：TTL 每过一跳减 1，源 IP 和目的 IP 一个字节都不变，源 MAC 和目的 MAC 每一跳都换。抓包时按这三个特征看，就能判断包走到了哪一跳、有没有发生路由。如果 TTL 没变，说明包根本没被路由，可能还在同一个广播域里打转。

4.2 默认路由不是万能钥匙，直连路由优先级更高

很多人配网络时习惯性把所有流量都甩给默认路由，觉得配了 0.0.0.0/0 就万事大吉。这在只有一个出口的环境里确实好使，但一旦环境里有多个网段、多条路径，默认路由就会变成背锅侠。

路由表的优先级逻辑是这样的：先比掩码长度，长的优先；掩码长度一样再比管理距离（不同来源的路由可信度不同，直连最高，静态次之，动态路由协议再往后）；管理距离也一样才比度量值。所以一条直连路由永远比默认路由优先，哪怕默认路由指向的路径更"短"。

这个规则带来的一个实用推论：只要路由器接口上配了 IP 并启用，就自动生成一条直连路由，不需要你手动加。所以两个网段分别接在两个接口上时，路由器天生就知道怎么去这两个网段，你什么都不用配。反倒是很多人画蛇添足，手工加一条静态路由指回直连网段，结果管理距离冲突或者下一跳写错，把本来正常的转发搞坏了。

我见过一次典型的误配：某台路由器上手工加了一条 192.168.2.0/24 指向一个不存在的下一跳，管理距离设得比直连还小，结果所有去 192.168.2.0/24 的包全被送到黑洞里。查了半天接口状态、查了半天 ARP，最后show ip route一看，路由条目指向的下一跳根本不可达。所以排错时看路由表不能只看"有没有"，还得看"指向哪""谁给的"。

5. 回程路径：只打通一半的通信等于没打通

5.1 请求能到、响应回不来，是跨网段排错里最常见的一幕

B 收到 ICMP 请求之后要回一个应答。B 构造应答包，源 IP 192.168.2.20，目的 IP 192.168.1.10，然后用自己的掩码判断目标在不在本网段。192.168.1.10 与 255.255.255.0 与运算得到 192.168.1.0，跟自己所在的 192.168.2.0 不一样，于是 B 也要把包交给自己的网关 192.168.2.1。

接下来的流程跟去程对称：ARP 网关、封装帧、发出去、路由器收到、查表、找到去 192.168.1.0/24 的路由、TTL 减 1、重新封装、发给 A。这条回程路径必须完整存在，通信才算真正建立。

问题就出在这里：很多人只验证了去程，没验证回程。表现是 A ping B 不通，但在 B 上 ping A 通，或者 A ping 网关通、网关 ping B 通，唯独 A 到 B 不通。这种情况十有八九是回程路由缺失或者回程路径上的策略拦截。

回程路由缺失的典型场景是：路由器只有一条指向 192.168.2.0/24 的路径，没有回 192.168.1.0/24 的路由。这听起来很蠢，但在多设备组网里经常发生——比如 A 侧的路由器把包转给了 B 侧的路由器，B 侧的路由器却不知道 192.168.1.0/24 怎么走，只好丢给默认路由，默认路由又指到一个不认这个网段的地方，包就消失了。

还有一种更隐蔽的情况：回程走了另一条路径，也就是所谓的非对称路由。去程走线路一，回程走线路二。如果中间有状态防火墙，防火墙只看到单向流量，会把回包当成非法连接直接丢掉。表现出来就是"去程抓包能看到，回程抓不到"，或者"TCP 握手发出去没有回应"。这类问题在有多出口的环境里特别常见，排查时必须同时在两端抓包对比。

5.2 用双向抓包快速判定问题出在哪一侧

判断回程问题最直接的办法是两端同时抓包。A 侧抓到 ICMP request 发出去了，B 侧抓到 request 进来了、reply 也发出去了，但 A 侧没抓到 reply，那问题就在回程路径上，跟 A 的配置基本无关。反过来，如果 B 侧根本没抓到 request，问题在去程。

我习惯的排查顺序是这样的：先在 A 上 ping 网关，通不通；再在网关上 ping B，通不通；最后 A ping B。这三步能把问题切成两段。A 到网关不通，问题在接入侧，查掩码、查 VLAN、查 ARP；网关到 B 不通，问题在另一侧或者路由器本身，查接口状态、查路由表；两头都通但 A 到 B 不通，问题几乎一定在转发策略或者回程路径上。

这个顺序的价值在于它把一个大问题拆成了几个小问题，每一步的结论都能排除掉一大片可能性。比一上来就在 A 上反复 ping B、看"请求超时"四个字干着急要高效得多。

6. 把整条链路"看见"：命令行与抓包的验证手法

6.1 主机侧几条命令，足够定位到具体哪一跳

在 Linux 上，我会按这个顺序敲几条命令。先看地址和掩码配得对不对，ip addr show一眼就能看到；再看路由表里默认网关在不在、指向谁，ip route show的输出里应该有一行default via 192.168.1.1；然后看 ARP 缓存里网关的 MAC 有没有解析出来，ip neigh show里对应条目状态是不是 REACHABLE。

# 查看本机地址与掩码 ip addr show # 查看路由表，确认默认网关 ip route show # 查看邻居缓存，确认网关 MAC 是否解析成功 ip neigh show # 跟踪到目标的路径，看在哪一跳断掉 traceroute 192.168.2.20

Windows 上对应的命令是ipconfig /all、route print、arp -a、tracert。功能一样，只是名字不同。新手容易忽略的是arp -a的输出——如果网关那条记录显示的是"无效"或者 MAC 全是零，说明二层根本没通，后面查三层全是白费。

traceroute和tracert的原理值得说一下，因为它能直接告诉你包走到了哪。它发出去的包 TTL 从 1 开始递增，第一跳的路由器收到后 TTL 减到 0，会回一个 ICMP 超时报文，工具就把这一跳的地址打印出来。TTL 加到 2，第二跳回超时，依此类推，直到目标回应。所以输出的每一行就是一个真实的路由器接口地址。如果某一跳之后全是星号，说明那一跳之后的路由器不回 ICMP 超时，或者路径在那里断了。

还有一个小技巧：ping 的时候看返回的 TTL 值。Windows 默认初始 TTL 是 128，Linux 常见是 64。如果 A ping B 收到 TTL 是 127，说明中间过了 1 跳；收到 63 说明过了 1 跳但源是 Linux。如果 TTL 跟预期对不上，说明路径跟你以为的不一样，可能绕路了。这个判断不精确，但作为快速验证很够用。

6.2 抓包看 MAC 和 TTL 的变化，比看文档直观十倍

在 A 上抓包，你看到的是：一个 ARP 广播问网关的 MAC，一个 ARP 应答回来；然后是一串 ICMP echo request，源 IP 192.168.1.10、目的 IP 192.168.2.20、源 MAC 是 A 的、目的 MAC 是网关的、TTL 64。在 B 上抓包，你看到的是：一个 ARP 广播问 B 的 MAC（发起方是路由器接口），一个 ARP 应答；然后是一串 ICMP request，源 IP 和目的 IP 跟 A 上抓的一模一样，但源 MAC 变成了路由器接口的、目的 MAC 是 B 的、TTL 变成了 63。

把这两个抓包结果并排放，跨网段通信的所有抽象概念一下子全具体了。三层地址端到端不变，二层地址逐跳重写，TTL 每跳递减，ARP 只在本地广播域内发生。我强烈建议每个学网络的人都亲手做一次这个对比，比看十篇文章都管用。

# 在 A 上抓包，只看 ICMP 和 ARP tcpdump -i eth0 -n -e icmp or arp # -e 参数会打印出 MAC 地址，这是观察二层变化的关键

-e这个参数很多人不知道，不加它只能看到 IP 层，加了才能看到帧头里的源 MAC 和目的 MAC。跨网段排错时，MAC 的变化恰恰是最有信息量的部分。抓包时还可以用-c限制数量，用-w直接存文件拿回本地用图形工具看，比在终端里滚屏舒服。

如果发现 A 发出了 ARP 请求但没有应答，说明二层不通或者对方不在线；如果 ARP 有应答但 ICMP 发不出去，多半是路由表没配默认网关；如果 ICMP 发出去了但 B 那边收不到，问题在中间设备；如果 B 收到了但 A 收不到回包，查回程。这一套判断逻辑串起来，大部分跨网段问题都能在十分钟内定位到大致范围。

7. 那些年踩过的跨网段配置坑

7.1 掩码、网关、回程这三类错误占了绝大多数

我把这些年遇到的跨网段问题归了归类，九成以上落在三个地方：掩码不一致、网关配错或没配、回程路由缺失。下面这张表可以直接当检查清单用。

"网关配错"这件事听起来低级，但实际发生的频率高得惊人。常见的一种是把网关填成了对端主机的地址，另一种是网关地址和自己不在同一网段——比如本机 192.168.1.10/24，网关填了 192.168.2.1。后一种情况在不少系统上会直接提示配置无效，但也有些系统照单全收，然后在发包时因为无法 ARP 到网关而静默失败，表现就是"配置看起来没问题，就是不通"。

还有一种坑是双网关。主机上如果同时配了两个默认网关（比如有线一个、无线一个），系统会按度量值选一个，但某些情况下会出现来回切换，导致连接时断时续。这种情况在笔记本上特别常见，插着网线又连着无线，路由表里两条 default，谁优先取决于接口度量值。排错时如果看到ip route里有两行 default，先把这个理清楚再谈别的。

7.2 从下往上查，比从上往下猜有效得多

我自己的排查习惯是从物理层往上推，一层一层排除。先看链路状态，接口 up 不 up、有没有 CRC 错误、光模块有没有告警；再看二层，VLAN 对不对、MAC 表里学没学到、ARP 能不能解析；然后看三层，IP 掩码网关对不对、路由表有没有对应条目；最后看四层以上，端口通不通、策略放没放行。

这个顺序的好处是每一步的结论都很确定，不会出现"好像是这方面又好像是那方面"的模糊状态。相反，如果一上来就怀疑防火墙、怀疑路由协议、怀疑运营商，往往会在错误的方向上耗掉大半天，最后发现是网线没插紧或者 VLAN 划错了。

还有一条经验：改配置之前先记录。把当前的 IP、掩码、网关、路由表、ARP 表都存一份，改完不通了能快速回滚。我见过有人排查问题时随手改了一堆参数，改到最后自己都不记得原来是什么，本来只是个掩码问题，硬生生折腾成了全网中断。这种事发生一次，记忆能管好几年。

另外一个实用建议是准备一个最小的验证闭环：两台主机加一台路由器，配好之后先 ping 通，再故意改错一处，观察现象并抓包。把掩码错、网关错、回程缺这三种情况各演练一遍，你对现象的敏感度会完全不一样。以后遇到真实故障，看一眼 ARP 表状态基本就能猜个八九不离十。

最后分享一个我常用的小技巧：如果怀疑是掩码问题，别急着改配置，先在主机上加一条临时路由，把目标网段明确指向网关，看能不能通。能通就基本坐实了是掩码判断出了偏差，这时候再回头统一掩码，比直接改来改去稳妥得多。改完记得把临时路由删掉，否则下次排查又会被自己埋的雷绊一跤。