这篇用 Wireshark 复现了哪两个经典场景？

一是复现 NAT 模式下虚拟机 Ping 不通宿主机的问题，二是抓一次 TCP 三次握手。目的是把「课本上的包」落到屏幕上眼见为实，验证此前用防火墙规则解决的 NAT/ICMP 问题。

NAT 模式 Ping 不通宿主机，抓包看到什么？

在宿主机抓 VMnet8 流量，虚拟机 Ping 宿主机 VMnet8 IP 时：请求包（ICMP echo）发出去了但无任何响应，Wireshark 标「No response seen」。说明不是不通，而是回显被挡。

No response seen 通常哪两种原因？

要么防火墙拦截了 ICMP 请求，要么目标主机禁用了 Ping（回显开关关掉）。实验环境目标没禁 Ping，故锁定为防火墙拦截。验证：临时关防火墙能通→确认；再建入站规则放行 ICMPv4 永久解决。

ICMP 的 Type 8 和 0 是什么？

ICMP 的 Type 字段区分请求与响应：Type 8 是 Echo Request（请求回显），Type 0 是 Echo Reply（回显响应）。记住「8 出去、0 回来」，以后看 ICMP 包一眼懂方向。

怎么用 Wireshark 抓 TCP 三次握手？

虚拟机发 HTTP 请求产生 TCP 连接，Wireshark 过滤 tcp.flags.syn==1 只看握手包。三包：①客户端→服务器 SYN（带初始 SEQ）；②服务器→客户端 SYN&ACK；③客户端→服务器 ACK，完成建连。

抓包在运维排障中的价值？

ping 只能知道「通不通」，Wireshark 能看清「包怎么走的、卡在哪一跳、谁回了什么」。复现 NAT/防火墙/握手异常时，抓包是最硬的证据，避免靠猜。建议把抓包纳入固定排障套路。

Wireshark 抓包复现：NAT 模式 Ping 不通定位

前面我们用防火墙规则解决了 NAT 模式下 Ping 不通宿主机的问题，也讲清了三种虚拟网络模式的原理。但这篇还欠一个"眼见为实"的环节：用抓包工具，亲眼看看那些数据包到底是怎么走的。 这篇就用 Wireshark 复现昨天的 Ping 问题，再顺带抓一次经典的 TCP 三次握手，把"课本上"的东西落到屏幕上。

一、环境准备

• 宿主机：Windows

• 虚拟机：Ubuntu Server 24.04，处于 NAT 模式

• 抓包工具：Wireshark

二、复现昨日问题：NAT 模式 Ping 不通宿主机

1. 确认双方 IP

先用命令确认宿主机的 IP：

宿主机 Windows
ipconfig

再确认虚拟机的 IP：
虚拟机 Linux
ip addr

2. 用 Wireshark 抓包，看 Ping 到底卡在哪

在宿主机用 Wireshark 抓取 VMnet8 网卡流量，然后在虚拟机里 Ping 宿主机的 VMnet8 IP。

这时会看到：请求包（ICMP echo）发出去了，但没有收到任何响应 —— Wireshark 标记为 No response seen（未收到响应）。

3. 判断原因：防火墙拦截，还是目标禁用 Ping？

No response seen 通常只有两种可能：

1. 防火墙拦截了 ICMP 请求

2. 目标主机禁用 Ping（回显 ICMP reply 的开关被关掉）

实验环境下目标主机没有禁用 Ping，那就锁定为防火墙拦截。

✅ 验证思路：先临时关闭防火墙再 Ping，通了 → 确认是防火墙问题；再用"新建入站规则放行 ICMPv4"的方式永久解决。具体操作见上一篇博客。

4. 成功后的 ICMP 包长什么样

新建规则放行后重新 Ping，抓包就能看到一唱一和的完整 ICMP 交互：

• 请求包（request）：Type: 8（Echo Request，请求回显）

• 响应包（reply）：Type: 0（Echo Reply，回显响应）

💡 小知识点：ICMP 的 Type 字段就是用来区分"这是请求还是响应"的。你看到的 8 和 0 是两个最基础的类型号，记住它们，以后看 ICMP 包都是"8 出去、0 回来"。

三、抓一次 TCP 三次握手

搞定 Ping，再来抓网络最经典的 TCP 三次握手。

1. 发起一次 HTTP 请求

在虚拟机里访问一个网站，用它来产生 TCP 连接：
curl -v www.qianwen.com

2. 用过滤表达式筛选握手包

Wireshark 里输入过滤条件，只看 SYN 相关的包（TCP 握手的第一步）：

tcp.flags.syn == 1

这个过滤会把 SYN 和 SYN & ACK 两种包都留下来（它们都带 SYN 标志）。

3. 看三次握手的三个包

① SYN 包（客户端 → 服务器）

• 源端口：55896

• 目的端口：80

• SEQ（序列号）：1683731675

📌 客户端想和服务器建连，先发一个 SYN，并带上自己的初始序列号。

② SYN & ACK 包（服务器 → 客户端）

• 源端口：80

• 目的端口：55896（回给上面对应的客户端端口）

• SEQ：1209019034

📌 服务器响应："我收到你的请求了"，同时带上自己的初始序列号，一并回给客户端。

③ ACK 包（客户端 → 服务器）

• 源端口：55896

• 目的端口：80

• SEQ：1683731676

📌 注意看：客户端的序列号从 1683731675 变成了 1683731676（+1），这正是三次握手的精髓 —— 客户端确认"我接上了"，握手完成，正式进入数据传输阶段。

4. 三次握手小结

顺序	方向	标志	作用
1	客户端 → 服务器	SYN	我能连吗？带上我的序号
2	服务器 → 客户端	SYN + ACK	收到，我准备好了（也带上我的序号）
3	客户端 → 服务器	ACK	好，我们开始传输

为什么叫"三次"而不是"两次"？因为客户端和服务器双方都要确认"对方能收到我的包"，三次是让双方都完成确认的最小次数。

四、写在最后

这一组实验下来，你会发现：那些抽象的课本概念（防火墙、ICMP、TCP 握手），用 Wireshark 一抓，全都变成了肉眼可见的数据包。

• 防火墙 → 表现为 "No response seen" 的 ICMP 孤儿包

• ICMP 类型 → Type 8 请求 / Type 0 响应

• TCP 握手 → 序号 +1 的微妙变化

网络排查的门道，就藏在"多看包"这三个字里。下次再遇上网不给力，先开 Wireshark 看一眼，很多问题当场就水落石出了 👋

一、分层排障模型（从物理层到应用层）

网络故障排查最忌”乱试”。按 OSI 自底向上：物理层（网卡/线缆/光模块/端口灯）→ 数据链路层（VLAN、MAC、STP、协商速率）→ 网络层（IP、网关、路由、ARP）→ 传输层（TCP/UDP 端口、ACL）→ 应用层（DNS、代理、证书）。先确认链路通断（网卡 up、协商速率正常），再 ping 网关，再 traceroute 看断点在第几跳，最后查应用端口与日志。

二、排障工具箱

ping / pathping / mtr：看连通性与逐跳丢包延迟。
traceroute / tracert：定位故障跳点，区分运营商侧还是内网侧。
Wireshark：抓包看 TCP 重传、RST、DNS 超时、ARP 风暴，可复现 NAT 穿透与三次握手异常。
交换机端口：err-disable、CRC 错包、双工不匹配、loop guard 是端口故障高频原因，show interface 看 counters 是第一步。
防火墙：iptables/firewalld/nftables/ufw 规则顺序与默认策略决定放行，改前先备份规则、确认 SSH 不会被锁死。

三、工程经验

交换机端口频繁 err-disable 多因 BPDU guard 或线缆接触不良；无线与有线混排时优先固化上联端口；变更防火墙前在测试环境验证并保留回滚命令。运维类故障的闭环是：复现 → 定位 → 临时恢复 → 根因修复 → 复盘沉淀。