用Wireshark抓包实战，彻底搞懂OSI七层模型与网络排错

很多人对OSI七层模型的第一反应是“背完就忘”。物理层、数据链路层、网络层、传输层、会话层、表示层、应用层，顺序能背出来，但遇到“能ping通却访问不了共享文件夹”这种真实故障，依然不知道从哪里下手。我自己的转折点，是在一次Windows共享文件访问慢到无法忍受的排障里，第一次认真打开Wireshark，亲眼看着数据包从ARP到ICMP再到TCP、SMB2一层层封装、应答，从那以后，七层模型在我脑子里就从“考试提纲”变成了一张排错地图。

这篇文章就是照着这个思路写的一份可复现实战记录：Windows 10专业版客户端 + Windows Server 2022文件服务器，用Wireshark抓ICMP和SMB2流量，把OSI七层模型的每一层映射到真实数据包上，同时把“分层排错”的方法和网络安全视角下的字段观察点一起讲清楚。适合刚入行的网络运维、桌面支持工程师，也适合正在啃计算机网络教材、想把实验变成真实环境的学生。全文基于Windows环境，命令都能直接抄。

1. 为什么我要用抓包来理解OSI模型

1.1 理论模型和排障地图的差距

教科书喜欢把OSI七层画成整齐的堆栈，好像数据就是从上到下、再从下到上走一趟。但现实里，一个数据包从网卡出去，遇到的第一个问题往往不是“在哪一层”，而是“我该看哪一层”。比如共享文件夹访问失败，可能是网线松了（物理层），可能是IP地址配错（网络层），可能是防火墙拦了445端口（传输层），也可能是共享权限不对（应用层）。如果不把“现象”和“层次”对应起来，排查就是瞎猜。

抓包的价值就在于，Wireshark把每一层协议头都解析出来摆在你面前。帧头对应物理层和链路层的接收结果，以太网头部对应数据链路层，IP头部对应网络层，TCP/UDP头部对应传输层，再往上是应用层协议。当你亲眼看到“这个ping包确实从客户端发出了，服务器也回了，但客户端显示超时”，和你空想“可能是网络问题”是完全两种体验。抓包之后，故障定位从玄学变成了看证据。

1.2 实验环境怎么搭

我用的环境很简单：

• 一台Windows 10客户端，版本22H2，IP 192.168.10.10
• 一台Windows Server 2022服务器，IP 192.168.10.20，开了共享文件夹D:\Share
• 两台机器在同一网段，没有额外路由

为什么要强调同一网段？因为跨网段时，客户端发的第一个包通常是ARP请求网关MAC，IP包的源和目标IP不变，但帧头的MAC每跳都在变。如果第一次做实验就跨网段，容易把“网络层IP”和“链路层MAC”搞混。先用同网段把基础打牢，再去看跨网段反而更清楚。

你要是在虚拟机里搭，建议用VMware的Host-Only网络或者Hyper-V的内部网络。NAT模式虽然也能上网，但多了一层虚拟NAT，抓包时看到的IP地址映射关系会分散注意力。物理机直连交换机当然最好，没有条件就用虚拟机Host-Only，效果差别不大。

服务器上的共享权限建议这样设：先建一个普通用户test，密码Passw0rd，把D:\Share共享给test，NTFS权限和共享权限都只给test读写。这样后面抓SMB2认证包时，能看到完整的NTLM会话过程，不会被管理员权限的“旁路逻辑”干扰。

1.3 Wireshark安装与抓包前的关键设置

Wireshark从官网下载稳定版即可，目前用的4.x版本。安装时有个关键点：务必勾选安装Npcap驱动，这个驱动是Windows下抓包的数据源，不装它Wireshark只是一副空壳。

装完第一件事，不是急着抓包，而是完成下面几个设置：

1. 右键Wireshark图标，选择“以管理员身份运行”。Windows下抓包需要管理员权限，普通用户双击只能看到网卡列表，但抓不到实际流量。
2. 进入“捕获”菜单，检查“选项”里的网卡列表，找到实际通信的网卡。Wi-Fi就用WLAN，有线就用以太网。虚拟机的虚拟网卡经常有多个，选错网卡会抓到一堆噪音。
3. 有需要时勾选“混杂模式”。在有线网络里，混杂模式能让你抓到同一交换机下其他主机的流量，但Windows下很多无线网卡驱动根本不向上层上送别人的二层帧，这不是Wireshark能解决的，是硬件限制。

抓包操作本身很简单：选中网卡，双击开始抓包；执行完要分析的通信动作后，点红色方块停止；然后在显示过滤器里输入表达式，按回车过滤。整个过程不超过十秒，难的是看懂抓回来的包。

2. 从Wireshark看到OSI七层模型的投影

2.1 一包一世界：Packet Details面板

抓到一个ICMP包后，在包列表双击它，中间那块Packet Details面板就是一份“解剖图”。从上到下正好对应OSI模型的层次：

• Frame：这层不是协议，是Wireshark自身对物理帧的统计，包括捕获时间、帧长度、接口信息，对应物理层和介质访问控制层面的“接收事实”。
• Ethernet II：数据链路层。能看到源MAC、目的MAC、上层协议类型（0x0800代表IPv4）。MAC地址解决的是“同一根网线/同一个交换机范围内，下一个设备是谁”。
• Internet Protocol Version 4：网络层。能看到源IP、目的IP、TTL、协议号。IPv4头里的Protocol字段，1代表ICMP，6代表TCP，17代表UDP，这就是Wireshark判断上层协议的依据。
• ICMP：网络层的控制协议，这里没有端口号，只有Type、Code、Checksum，以及后方的一堆数据内容。
• 数据内容：应用层或负载部分，不同协议有不同表现。

如果你打开一个SMB2包，会发现面板多了一层TCP（传输层），然后是SMB2（应用层）。传输层的TCP头部里有源端口、目的端口、序列号、确认号、窗口大小，这些是处理“可靠传输”和“流量控制”用的，对应第四层。SMB2的头部里有Message ID、Session ID、Tree ID，处理的是“一次会话中的命令对齐”和“共享资源的归属”，这些概念正好对应会话层的管理思路。看到这里你就明白，OSI模型不是空中楼阁，它是在描述协议栈里真实存在的分工。

2.2 二层与三层：MAC地址和IP地址各管一段

很多新手问：数据包里既有MAC地址又有IP地址，到底看哪个？

答案是都看，但各管一段。IP地址解决的是“全局寻址”，从客户端到服务器，不管中间经过多少台路由器，源IP和目的IP在整个通信过程中基本不变。MAC地址解决的是“一跳一跳的接力”，经过一台路由器，以太网帧头里的源MAC和目的MAC就要换一次。

实际操作里，你在Wireshark里看同一网段的ping包：第一个包往往是ARP请求“谁是192.168.10.20，请告诉192.168.10.10”，然后服务器回一个ARP应答，紧接着才是ICMP echo request。ICMP包的目的MAC是服务器的MAC，源MAC是客户端的MAC。如果你跨网段ping一个远程主机，同样看这些包，会发现ICMP包的目的MAC是网关的MAC，而不是远程主机真实的MAC。这就是二层地址和三层地址最直观的区别。

2.3 过滤器的正确姿势：为什么你加了udp过滤还看到icmp

Wireshark里有两类过滤器，概念必须分清楚：

捕获过滤器（Capture Filter）在抓包时就生效，用的是BPF语法，不匹配的包直接不采集。它写在“捕获”菜单的“选项”里，典型写法是host 192.168.10.20 and port 445。这类过滤器一旦写错，抓回来的文件里就是缺数据的，事后没法补救。

显示过滤器（Display Filter）只在界面上起过滤作用，抓包文件里的数据一条都没少，只是把不符合条件的包折叠显示。它写在主界面的过滤栏里，语法是Wireshark自己的表达式，比如ip.addr == 192.168.10.20、tcp.port == 445、icmp。

很多人看到的现象是：我在显示过滤器里输入了udp，为什么还能看到icmp的包？

先说结论：如果显示过滤器真的生效，icmp包不应该出现在列表里。出现这种情况，按顺序排查三件事：

1. 过滤器语法是否有效。在过滤栏输入内容时，背景色是绿色表示语法正确，红色表示语法错误。语法错误时过滤器不生效，此时列表里显示的是全部数据包，当然会看到icmp。稍微改一下，用更严格的写法可以验证：_ws.col.protocol == "ICMP"。
2. 是不是把捕获过滤器和显示过滤器混用了。如果你在捕获选项里填的是udp，那采集回来的包里会有基于BPF的采集限制，理论上不会出现icmp，但如果你同时在显示过滤栏里又填了别的条件，或者你根本是在看一个之前已经抓好的pcap文件，那么“显示过滤器没生效”同样会带来困惑。
3. 有没有多个过滤条件叠加。Wireshark允许在显示过滤栏输入复杂表达式，比如udp or icmp、tcp.port == 53 or udp，这类表达式看着像“只要udp”，实际把icmp也算进去了。输入时多看几眼表达式，别凭记忆。

我的建议是，日常学习阶段只用显示过滤器，别碰捕获过滤器。显示过滤器灵活，改起来方便，也不会因为一时疏忽丢掉关键包。等熟悉了协议，再按需使用捕获过滤器减少噪声。

3. ICMP实战：一次ping请求的完整旅程

3.1 抓包操作步骤

打开Wireshark，选中客户端网卡，双击开始抓包。然后在显示过滤器里输入icmp or arp，因为同网段第一次ping对方，前面会有ARP解析，用这个过滤条件可以把解析过程也留下来。

接着在客户端打开命令行，执行：

ping -n 4 192.168.10.20

发送4个测试包后回到Wireshark，点红色方块停止抓包。此时列表里应该至少有10个左右的包，顺序是：ARP请求、ARP应答、ICMP echo request、ICMP echo reply，再重复三轮。

这里有个观察点：如果用的是无线网卡，很可能看不到ARP请求/应答那两行，只有ICMP。这不是抓包姿势错了，而是Windows下多数无线网卡驱动会把ARP解析放在网卡固件里处理，不上抛给抓包驱动。遇到这种情况，换有线网络最省心。

3.2 ICMP报文格式逐字段解读

双击任意一个ICMP echo request包，展开ICMP层，你会看到这些字段：

• Type：8，表示这是一个echo request；回复包Type为0，表示echo reply。
• Code：通常是0，和Type组合成具体语义。
• Checksum：校验和，用于检测ICMP报文在传输中是否损坏。
• Identifier和Sequence Number：客户端用来匹配“发出的哪个请求对应哪个回复”。在Windows里，Identifier一般就是进程ID，Sequence从1开始递增。

再往下的Data区，就是负载内容。Windows的ping默认发32字节数据，Linux默认发56字节数据。这个差异很有用：你ping一台服务器，从回包的TTL和Data长度能大概猜出对方操作系统。Windows默认TTL是128，Linux默认TTL是64，看到TTL在110多基本是Windows，在50多基本是Linux。

3.3 ping不通时，错误码已经告诉你在哪一层

ping不通时，很多人只看“Request timed out”，然后就不知道怎么办了。其实ICMP的错误消息已经把故障层次写得很清楚。

举个例子，如果ping返回“Reply from 192.168.10.1: Destination host unreachable”，说明你的网关192.168.10.1知道目标主机不可达，问题出在网关到目标主机这一段，而不是本机到网关这一段。这个信息价值很高，能直接把排查范围缩小。

还有一个很实用的MTU排查法：在Windows里执行ping 192.168.10.20 -f -l 1472。-f表示设置IP头的DF位，禁止分片；-l 1472指定ICMP数据长度为1472字节。加上20字节IP头、8字节ICMP头，正好1500，这是标准以太网MTU。如果1472能通，1473就不通，说明中间某段链路的MTU就是1500；如果你在PPPoE拨号环境下，可能需要把长度改成1464，对应MTU 1492。这个方法在排查“网页打不开但QQ能上”之类的MTU故障时特别好用。

3.4 用安全视角检查ICMP流量

ICMP本身是网络层的控制协议，但安全设备经常对它重点“关照”，因为攻击者可以拿它做文章。

• 扫描探测：攻击者向网段内批量发送echo request，通过是否有reply判断存活主机。抓包特征是一段时间内出现大量目的IP不同的ICMP请求，源IP可能相同或分散。
• ICMP隧道：把数据藏在ICMP的Data区里传输。正常ping的Data区内容是固定模式，如果看到Data区内容明显具备规律性、或者请求和响应的Data区长度不对称，就需要警惕。
• 拒绝服务：常见形式是大量ICMP请求集中到一个目标，消耗目标CPU和带宽。

在Wireshark里，用“统计”菜单下的“协议分级”和“端点”能快速发现异常。比如正常办公网里ICMP流量占比极低，如果协议分级里ICMP占了很大比例，就要回去看具体是哪些主机在通信。日常运维我有个习惯：ping命令只用来做连通性测试，测完就把数据关掉，不会一直后台跑着，尤其在生产网络里，持续高频的ping本身就是一种噪音。

4. SMB2实战：Windows共享访问的完整会话

4.1 抓SMB2流量的最佳姿势

SMB2是Windows文件共享用的应用层协议，固定跑在TCP 445端口。抓包时，显示过滤器直接写：

smb2 or tcp.port == 445

这样既能过滤到SMB2协议帧，也不会漏掉TCP握手包。

访问共享的方式，我推荐用命令行而不是资源管理器。资源管理器一打开会触发缩略图、预读、自动扫描一堆行为，产生大量无关的SMB2命令，干扰分析。命令行干净得多：

net use \\192.168.10.20\share /user:lab\test Passw0rd

在客户端执行这条命令，然后回到Wireshark看一眼，整个通信过程一目了然。想断开就执行：

net use * /delete

4.2 SMB2的完整交互流程

一次完整的SMB2会话，包顺序大致是这样的：

1. TCP三次握手：SYN、SYN-ACK、ACK，对应传输层。
2. Negotiate Protocol Request：客户端向服务器声明“我支持这些SMB方言版本”。
3. Negotiate Protocol Response：服务器选择其中一个方言返回，同时告知安全模式、最大传输大小等能力。
4. Session Setup Request：客户端开始认证，承载NTLMSSP协商数据，这里能看到用户名（要仔细找，有些版本是加密哈希）。
5. Session Setup Response：服务器返回认证结果。如果成功，会分配Session ID。
6. Tree Connect Request：客户端请求连接共享。
7. Tree Connect Response：服务器返回共享连接句柄。
8. Create Request：客户端请求打开某个文件或目录。
9. Create Response：服务器返回文件句柄。
10. Read/Write Request/Response：真正的数据读写。
11. 最后是Close、Tree Disconnect、Logoff以及TCP四次挥手。

在Wireshark里展开Negotiate Response，能看到一个关键字段：Dialect。如果显示0x0311，说明协商到SMB 3.1.1，这是Windows 10和Server 2016之后的主流版本；如果协商到0x0202或更老的SMB 2.0.2，说明某一端系统比较旧，或者有人为限制了协议版本。

很多人不理解SMB2和OSI的会话层、表示层有什么关系。其实SMB2的Session ID负责多命令之间的会话关联，Message ID负责请求和响应的一一对应，这就是“会话管理”的具体实现；SMB2里的Unicode字符串和可选的加密特性，对应“表示层”关心的数据编码和数据保密。虽然TCP/IP模型已经把这层合进应用层，但用OSI思路去理解SMB2的内部职责，反而更清楚。

4.3 SMB2错误响应与故障定位

共享访问失败时，Wireshark里的SMB2响应帧会直接告诉你失败原因。最常见的几个错误码：

在Wireshark里直接过滤错误响应：

smb2.nt_status == 0xc0000022

可以看到所有访问拒绝的包。这个字段在SMB2响应头里，不用一个个找。

有一次我在客户现场遇到共享文件夹访问慢，抓包后发现每读一个文件，都会先出现一个STATUS_ACCESS_DENIED，随后客户端又发一个Create请求，这次带上了不同参数，服务器才返回成功。这个重试过程每次要多花一两秒，文件多了自然慢。后来查下来，是杀毒软件在拦截Create请求，不是网络问题，也不是权限问题。如果不抓包，这种故障排查起来相当费劲。

4.4 SMB协议安全分析要点

聊到SMB，绕不开安全问题。SMBv1这个老协议因为设计过于简单，出现过极其严重的安全事件，很多勒索蠕虫就是靠它传播的。2017年那次全球性的勒索事件之后，业界普遍动作就是关闭SMBv1。在Windows Server 2022上，默认已经不再启用SMBv1，但如果你管理的是老环境，建议用下面命令检查并关闭：

Set-SmbServerConfiguration -EnableSMB1Protocol $false Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

从抓包角度，判断一台服务器是否还在用SMBv1很简单：在Wireshark过滤栏输入smb（注意不是smb2），如果过滤出大量SMB、而不是SMB2的协议帧，基本可以确定有客户端或服务器还在用老协议。

再进阶一点，可以检查SMB签名和SMB加密：

• 在Negotiate Response里，SecurityMode字段会显示是否要求签名。签名开启时，SMB2头部会带一个数字签名，能防止流量被中间人篡改。
• 在Session Setup Response里，SessionFlags字段如果包含ENCRYPT_DATA，说明本次会话启用了SMB加密，后面传输的数据在Wireshark里会显示为“Encrypted message”，看不清明文内容。看到这个是好事，说明数据在传输层之上还有一层保护，即使被截获也读不了内容。

有些运维第一次看到加密的SMB流量以为抓包失败了，其实不是，这是加密生效的信号。如果非要分析应用层内容，要么在服务器上关闭SMB加密，要么部署证书绑定等方式让Wireshark能解密，但生产环境不建议轻易关闭加密，安全优先级更高。

5. 分层排错实战：Win10无法访问Server 2022共享

5.1 从现象倒推，快速锁定可能的问题层

假设现在有一个经典故障：Windows 10客户端能ping通Windows Server 2022，但访问\\192.168.10.20\share时提示找不到网络路径。

按照分层排错的思路，我应该这样推：

• 能ping通，说明L1物理层、L2数据链路层、L3网络层的通路基本正常。
• 但SMB走的是TCP 445端口，ping通不代表445端口通，L4传输层的连通性需要单独验证。
• 就算445端口通，SMB2的应用层认证、共享权限、文件权限也不一定没问题，这是L7应用层的事。

所以排查不是从物理层开始一层层“往上查”，而是根据现象先跳过高概率没问题的层，从可疑层次入手。这就是分层排错真正的价值：它不是做题，是缩小范围。

5.2 分层排查命令与工具整理

我在Windows环境里习惯按这个顺序使用命令，每一步都对应一个OSI层次：

这里最实用的一条是PowerShell的Test-NetConnection。它相当于把telnet的端口测试封装得更漂亮，还会直接显示TcpTestSucceeded是True还是False。如果显示False，说明TCP 445根本没通，后面SMB2的细节都不用看。

5.3 一次完整排错过程演示

为了让你有真实感，我完整复盘一次我做过类似的排障。

现象：Win10客户端能ping通服务器，但映射网络驱动器失败。

第一步，我在客户端执行Test-NetConnection 192.168.10.20 -Port 445，结果TcpTestSucceeded返回False。这说明服务器445端口对客户端不可达。能ping通却连不上445，问题大概率在服务器防火墙或SMB服务状态。

第二步，远程到服务器，先看SMB服务状态：

Get-Service LanmanServer

服务在运行。然后看防火墙有没有放行SMB：

Get-NetFirewallRule -DisplayGroup "文件和打印机共享" | Select-Object DisplayName, Enabled, Profile

结果发现“文件和打印机共享(SMB-In)”规则被禁用了。启用后，445端口测试立刻通过。

第三步，客户端继续访问共享，这次报“拒绝访问”。再抓包，发现SMB2的Session Setup Response返回的是0xC0000022。这已经不是网络层问题，而是应用层权限问题。检查服务器上test用户的共享权限，发现共享权限给了test，但NTFS权限里test没有被添加。补上NTFS权限后，访问成功。

整个过程如果不用分层思路，很可能在“换网线”“重启服务器”“重装客户端”这类低级操作上浪费大量时间。而用Test-NetConnection加Wireshark，故障点明确，处理时间不到十分钟。

6. 高频问题速查与我的实操习惯

6.1 Wireshark/网络排错高频问题速查表

速查表里最后一条“Decode As”值得多说一句。很多应用层协议默认跑在固定端口上，比如SMB2跑445，但如果把SMB2改到别的端口，或者某个端口上跑了多种协议，Wireshark可能识别不出来。这时选中数据包，右键“Decode As”，手动指定协议，一般就能正常解析。大学里做Wireshark实验时，老师给一个pcap文件让你分析TCP，结果发现什么协议都识别不出来，多半就是没做协议识别处理。

6.2 几个让抓包效率翻倍的习惯

抓包这件事，经验比技巧更值钱。我总结几个自己一直在用的习惯：

第一，抓包前先写下“我要回答什么问题”。比如“客户端访问共享为什么慢”、”这台服务器445端口到底通没通”。明确问题后，再决定过滤条件，而不是打开Wireshark乱抓一通。抓包文件一大，光看包就能看晕。

第二，重大排障时，客户端和服务端同时抓包。很多时候，客户端发出的包和服务端收到的包并不一样，中间可能有防火墙、负载均衡设备在改动数据。两侧对比能快速定位问题是否发生在链路中间设备上。

第三，抓完包立刻停止，然后保存pcap文件，并记录抓包时间、抓包位置、过滤条件。这个习惯在回头写报告、或者一周后复盘时特别有用。很多时候你当时没看懂的数据，回头再翻反而能发现线索。

第四，多用“统计->流量图”功能。选中一个SMB2会话，流量图能按时间顺序展示每个包的交互方向，用来向同事解释“TCP三次握手在哪、认证在哪、文件读写从哪开始”非常直观，比自己一帧帧找高效得多。

第五，别只盯着Wireshark看包有没有到达，还要看包的响应码。很多“网络慢”“连接中断”的问题，真正原因在应用层错误响应里。SMB2返回ACCESS_DENIED，网络再快也没用，先把权限修好。

抓包不是万能的，但不抓包，遇到网络故障就只能靠猜。把OSI模型当成索引，把Wireshark当成显微镜，再把ICMP和SMB2这两个最经典的协议摸熟，Windows环境的网络排错基本就有章法了。这套方法我用了很多年，希望你也能从第一个抓到的ping包开始，建立属于自己的排错手感。