OSI 七层模型实战详解Wireshark 抓包分析 ICMP/SMB2Windows 10 Server 2022 分层排错与网络安全干网络排查这行十几年我最常被问的一句话就是老师OSI 七层模型背了无数遍到底有什么用说实话刚入行那会儿我也觉得它抽象直到后来被一个SMB 文件共享时快时慢的问题折磨了两天才真正体会到——OSI 模型不是一个用来考试的抽象框架它就是一张现成的排错地图。哪一层出了问题就在哪一层解决这个思维习惯能救命的。今天这篇文章我就用一套完整的实战环境来讲透 OSI 七层模型。环境很简单一台 Windows 10 作为客户端一台 Windows Server 2022 作为服务端中间用 Wireshark 抓包重点分析两个典型协议——网络层的 ICMPping 命令用的那个和应用层的 SMB2Windows 文件共享用的那个。前者小巧直观适合讲清楚包是怎么走的后者复杂真实适合讲明白一个完整业务请求如何跨越多层协作。同时我还会把分层排错的方法论和网络安全视角穿插进去保证你看完能直接照着做。1. 实验环境准备先搭一个能出问题的舞台1.1 虚拟化环境与系统配置我这次用的是 VMware Workstation 17你也可以用 Hyper-V 或者 VirtualBox逻辑都差不多。准备两台虚拟机角色操作系统内存磁盘网络模式客户端Windows 10 22H24 GB60 GBVMnet2仅主机服务端Windows Server 20224 GB80 GBVMnet2仅主机关于网络模式我要多说两句。我故意不用 NAT 模式而是选择了仅主机模式原因有两点。第一NAT 模式下流量会经过宿主机虚拟网卡Wireshark 抓到的包会混入宿主机自身的一些广播和路由协议报文干扰实验观察仅主机模式下两台虚拟机之间的流量干净纯粹非常适合教学演示。第二仅主机模式下没有外部网络干扰ICMP 测试的结果几乎完全由我们可控不会出现明明配置没问题却因运营商丢包导致排查方向跑偏的情况。两台虚拟机的 IP 规划如下Windows 10192.168.100.10 / 255.255.255.0网关留空Server 2022192.168.100.20 / 255.255.255.0网关留空网关留空是有意的。在仅主机网络中我们不需要跨网段通信留空网关可以避免客户端发起不必要的网关探测流量。如果你在实际局域网环境中复现按正常配置填网关即可。服务端还需要开启文件和打印机共享功能并在计算机管理—共享文件夹中新建一个测试共享目录比如名为 share 的文件夹。共享权限和安全权限我都设置为 Everyone 可读方便稍后展示 SMB2 的完整流程。1.2 Wireshark 安装与抓包前设置Wireshark 我用的 4.0 以上的版本安装过程默认下一步就行但有两个点值得提一下第一安装过程中会提示安装 Npcap这个必须装它是 Windows 下抓包的核心驱动。如果之前装过旧版 Npcap建议先卸载再装新版否则可能出现抓包时看不到任何接口的诡异问题。第二装完 Wireshark 后先别急着抓包打开捕获—选项在输入页面里把使用混杂模式勾上。虽然仅主机网络下不勾也能抓到大部分包但实际接交换机时如果端口没做端口镜像混杂模式是抓到别人流量的前提。养成习惯省得以后踩坑。抓包前还有一个容易忽略的设置Wireshark 默认会解释所有 TCP 端口 445 的流量为 SMB 协议但 SMB 有多个版本为了让 SMB2 的解析更友好建议在分析—启用协议里确认 smb2 协议处于启用状态。Wireshark 会同时加载 SMB 和 SMB2 解析器不必手动切换但如果遇到 SMB2 报文解析成 SMB 或者干脆是裸 TCP 的情况优先检查这里。2. 分层排错的核心思路OSI 模型不是背的是拿来用的2.1 把七层翻译成故障现象很多朋友背 OSI 七层模型时能流利说出物理层、数据链路层、网络层、传输层、会话层、表示层、应用层但一到实际排障就不知道该从哪层下手。我自己的习惯是把每一层翻译成一个具体的故障现象关键词层次典型故障表现常用排查工具物理层网线松动、指示灯不亮眼睛、测线仪数据链路层链路正常但 ARP 不通、交换机端口错误ping 同网段 IP、arp -a网络层跨网段不通、路由缺失、TTL 超时ping、tracert、route print传输层端口不通、TCP 连接重置telnet、Test-NetConnection、Wireshark 过滤 TCP会话层认证不断重试、会话被中断查看日志、Wireshark 看 SMB 会话建立过程表示层数据格式错误、加密协商失败抓包查看协议头、TLS 握手应用层共享能通但权限拒绝、HTTP 404应用程序日志、共享权限设置这个表格不是让你背而是给你一个问题落到哪一层的判断入口。比如用户报文件共享连不上你不会一上来就打开 Wireshark更不会先去翻应用日志。我的顺序永远是由下往上先看物理链路网线、虚拟机网卡状态再 ping 同网段 IP数据链路层 网络层再测 TCP 445 端口传输层最后才去看 SMB 会话和应用权限会话层 应用层。2.2 自下而上的排查顺序我在讲排错时经常用一个生活化类比你去餐厅吃饭菜最后端不上来问题可能出在采购、灶台、传菜员、服务员任何一个环节。你肯定不会先骂服务员应用层而是先确认厨房到底有没有做这道菜下层服务是否正常。网络也一样上层依赖下层下层坏了上层必然光火。所以标准操作是先看物理层虚拟机里看网卡状态是否已启用物理机看网线 LED 是否亮。这一步 10 秒钟能过滤掉一半的低级问题。再看链路层ping 同网段地址能通说明 ARP、交换机 MAC 转发都正常。如果 ping 不通抓包看有没有 ARP 请求和响应。然后是网络层和传输层ping 网关、tracert 跨网段telnet 目标端口。最后才是应用层看服务的配置文件、日志抓包分析协议交互。2.3 一个典型的分层定位案例去年我帮一个朋友排查过一个问题Windows 10 客户端可以 ping 通 Server 2022但访问共享文件夹一直转圈。从 OSI 来看网络层ping 通和传输层445 端口开着才能弹认证框大概率没问题那问题多半出在会话层以上的认证环节。我在 Server 2022 上打开事件查看器—Windows 日志—安全查看登录事件果然发现大量的 Audit Failure登录类型为 3网络登录。然后检查共享权限发现共享名虽然存在但安全选项卡里 Everyone 的读取权限被误删了。改完权限客户端立刻就能访问。这个案例说明什么说明如果你只停留在共享文件夹打不开这一层你永远不知道往下该怎么查。但当你把它映射到 OSI 的分层框架里每一步排查都有了明确的方向和工具。这才是 OSI 模型真正的价值。3. ICMP 抓包实战一次 ping 背后的网络层真相3.1 从 ping 开始ICMP 请求与响应现在我们正式开始抓包。在 Windows 10 上打开 Wireshark选择对应 VMnet2 的抓包接口然后打开 CMD 执行ping 192.168.100.20 -n 4注意我加了 -n 4只发 4 个包。不加这个参数 Windows 会无限 ping 下去方便是方便但包多了影响你后续分析。抓包结束后在 Wireshark 的过滤栏里输入icmp你会看到 8 个包交替出现4 个请求4 个响应。展开任意一个请求包在Internet Control Message Protocol字段里可以清晰看到Type: 8 (Echo (ping) request)Code: 0Identifier (BE): 1 (0x0001)Sequence Number (BE): 1 (0x0001)响应包对应的则是 Type: 0 (Echo (ping) reply)Identifier 和 Sequence Number 与请求包完全一致。Identifier 和 Sequence Number 的作用是什么呢你可以理解为快递单号。当一台机器同时向多个目标发起 ping 时系统靠这两个字段把响应对应回正确的请求避免张冠李戴。Wireshark 也正是靠它们把请求和响应自动关联成一条完整的HTTP 式对话方便你看往返时间。在 Wireshark 主界面每一项前面有灰黑色的横向小箭头点击可以展开请求和响应之间的关联视图Request/Response视图里会直接显示往返时间。这里我建议你把第一列的Time显示格式改成Seconds Since Previous Displayed Frame方便看到每个包的间隔判断是不是有延迟抖动。3.2 TTL、分片与超时判断再看 IP 层的 Time to Live 字段默认值 Windows 是 128Linux 是 64网络设备如 Cisco通常是 255。你看到的实际 TTL 是源主机设置的初始值减去沿途经过的路由器数量严格说是每经过一个路由跳数减 1。所以当你发现 ping 某台 Linux 服务器返回的 TTL 是 56你就可以推断出中间经过了 8 跳。这个细节在跨国、跨运营商的故障排查中特别有用——TTL 异常变小往往意味着路由绕路路径可能不是最优的。还有一个常见现象是分片。当 ping 包大小超过路径 MTU 时设备会把 ICMP 报文分成多个 IP 分片。你在 Wireshark 的过滤栏输入ip.flags.mf 1就可以筛选出所有更多分片标志位为 1 的包。Windows 下可以用以下命令测试分片ping -l 1472 -f 192.168.100.20-f 表示禁止分片-l 指定缓冲区大小。以太网标准 MTU 是 1500 字节减去 20 字节 IP 头、8 字节 ICMP 头正好剩下 1472 字节的载荷。如果这条命令能通说明路径 MTU 至少是 1500如果提示Packet needs to be fragmented but DF set说明中间设备 MTU 小于 1500。这是排查大包不通、小包通问题的利器。3.3 抓包定位通而不畅的问题ping 能通不代表网络体验好。以前排查过一个场景客户端 ping 服务器平均延迟只有 2 ms但远程桌面就是卡。后来抓包发现问题不在 ICMP而在 TCP 窗口频繁降到 0——服务器端应用程序处理不过来接收缓冲区满了TCP 流量控制把发送端按住了。所以 ICMP 抓包只是分层排错的第一步它的价值在于快速验证网络层通不通、大概多快但真正的性能瓶颈往往隐藏在传输层和应用层交互里。这也是为什么我强调 Wireshark 抓包不能只盯着某一个协议要结合具体业务去分析完整的交互流程。4. SMB2 抓包实战Windows 文件共享的完整会话4.1 为什么选 SMB2而不是 SMB1先泼一盆冷水如果你的生产环境还在用 SMB1请立刻、马上禁用。SMB1 是 1980 年代的设计存在严重的安全漏洞大名鼎鼎的勒索软件 WannaCry 就是通过 SMB1 漏洞MS17-010传播的。Windows 10 和 Server 2022 默认已经禁用了 SMB1但历史遗留系统、老 NAS 设备里可能还开着建议在所有 Windows 系统上执行以下 PowerShell 命令确认Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select-Object State如果显示 Enabled用下面命令禁用Disable-WindowsOptionalFeature -Online -FeatureName SMB1ProtocolSMB2 从 Windows Vista / Server 2008 开始引入相比 SMB1 大幅减少了命令数量提升了性能还支持加密和签名。现在 Windows 10 和 Server 2022 之间的文件共享默认走的是 SMB3.1.1属于 SMB2 家族的后续版本。所以这篇文章分析 SMB2既是讲协议也是讲当前 Windows 环境下的真实文件共享行为。4.2 SMB2 的四个阶段协商、认证、连接、读写现在我们在 Windows 10 上访问 \192.168.100.20\share同时 Wireshark 开始抓包。访问成功后过滤栏输入smb2你会看到一串复杂的交互但把它拆成四个阶段瞬间就清晰了。第一阶段是协议协商Negotiate。客户端发送 SMB2 Negotiate 请求服务端回复支持的最高版本。用下面的过滤表达式可以只看协商过程smb2.cmd 00 代表 SMB2 的 Negotiate 命令。在这里你可以看到客户端声明自己支持 SMB 2.0.2、2.1、3.0.2、3.1.1 等多个版本服务端最终选择 3.1.1。这个阶段由谁主动并不固定如果是客户端主动发起到服务端的 445 端口那就是客户端先发协商包如果是入站连接服务端会先发。第二阶段是会话建立Session Setup。这是应用层认证阶段通常走 NTLMSSP 或 Kerberos。过滤表达式smb2.cmd 1在这个阶段你会看到包含 NTLMSSP_NEGOTIATE、NTLMSSP_CHALLENGE、NTLMSSP_AUTHENTICATE 的报文序列。我用的是仅主机实验环境没有域控所以走的是 NTLM 挑战-响应认证客户端先发 NTLMSSP_NEGOTIATE 声明自己支持的认证选项服务端返回 NTLMSSP_CHALLENGE包含一个随机 challenges客户端用密码哈希加密这个 challenge 生成 NTLMSSP_AUTHENTICATE 发回服务端校验。整个过程中密码不会明文传输但注意 NTLM 认证容易被离线暴力破解所以生产环境有条件的还是建议用 Kerberos加域。第三阶段是树连接Tree Connect。认证成功后客户端需要连接具体的共享。过滤表达式smb2.cmd 3Tree Connect 请求里会包含共享名 \192.168.100.20\share响应里带有共享的类型和权限标志。这一步常见的问题是找不到共享名、共享权限不足返回错误码 STATUS_BAD_NETWORK_NAME 或 STATUS_ACCESS_DENIED。第四阶段是文件读写Create/Read/Write。过滤表达式smb2.cmd 5 || smb2.cmd 8 || smb2.cmd 9cmd 5 是 Create打开文件cmd 8 是 Readcmd 9 是 Write。在 Create 请求里你能看到客户端请求的文件名响应里带回了文件 ID 和文件大小。后续的 Read/Write 都带这个文件 ID相当于拿到了文件的句柄。如果这里出现 STATUS_SHARING_VIOLATION说明文件正被其他进程占用。看明白这个四阶段过程你会发现 SMB2 的交互本质上就是先谈版本再验身份再进房间再拿东西。每一步都有对应的过滤表达式和错误码这就是 Wireshark 排障最实用的地方。4.3 从抓包角度识别认证失败与共享权限问题前面说了一堆理论现在讲一个我实际踩过的坑。有次一个同事反馈客户端能 ping 通服务器也能 telnet 通 445 端口但访问共享时一直弹无法访问。您可能没有权限使用网格资源。我抓包看到 SMB2 Session Setup 阶段返回了 STATUS_LOGON_FAILURE但客户端的用户名密码明明是对的。折腾了很久最后发现是服务端的本地安全策略—网络访问本地账户的共享和安全模型被设成了仅来宾。这个策略会强制所有网络登录都映射到来宾账户你把密码输上天也没用。改回经典模式后认证立刻通过。这个案例告诉我SMB 抓包不能只看有没有包必须去读 SMB2 响应里的 NT 状态码。常见的几个状态码我整理在下面状态码含义排查方向STATUS_LOGON_FAILURE (0xC000006D)用户名或密码错误检查账号、密码、域策略STATUS_ACCESS_DENIED (0xC0000022)权限不足检查共享权限和 NTFS 权限STATUS_BAD_NETWORK_NAME (0xC00000CC)共享名不存在检查共享名称是否拼错STATUS_SHARING_VIOLATION (0xC0000043)文件被占用检查是否有进程锁文件STATUS_USER_SESSION_DELETED (0xC0000203)会话被强制断开检查服务器是否 reachable 的上限或安全策略5. 用抓包视角看网络安全日常巡检该盯什么5.1 常见异常流量识别与 Wireshark 过滤既然标题里提到了网络安全我必须强调一点Wireshark 不只是网络工程师的排错工具它也是安全分析的基础工具。你在日常运维中不需要像安全专家那样做深度取证但以下几个常用的过滤场景很有价值。端口扫描识别。攻击者最喜欢先用端口扫描探路。你可以在 Wireshark 里过滤出大量 TCP SYN 包tcp.flags.syn 1 tcp.flags.ack 0如果在短时间内看到同一源 IP 对大量目的端口发起 SYN 请求且没有对应的 ACK 响应就说明有人在扫端口。要快速统计可以用统计—IPv4 统计—目标地址和端口按报文数降序排列一眼就能看到异常热点。可疑的 SMB 爆破。在 Server 2022 上如果发现大量来自同一 IP 的 SMB2 Session Setup 请求且状态码都是 STATUS_LOGON_FAILURE那基本可以断定有人在尝试弱口令爆破。Wireshark 过滤smb2.cmd 1 smb2.nt_status 0xC000006D然后去统计—对话里看这个 IP 的连接次数即可确认。ARP 欺骗。如果内网有人跑 ARP 欺骗工具你会发现同一 IP 对应了多个不同的 MAC 地址。Wireshark 过滤arp然后查看ARP 请求和ARP 应答里的 Sender MAC 字段。正常情况下一个 IP 的 MAC 是稳定唯一的如果出现频繁跳变就要警惕了。这个检查在办公网里偶尔做一次能有奇效。5.2 Windows 安全日志联动排查抓包能告诉我们网络上发生了什么但想知道系统认为发生了什么还得看 Windows 事件日志。我在这里用的组合思路是Wireshark 定位异常流量的来源 IP 和端口安全日志确认这些流量是否造成了实际影响。Server 2022 的事件查看器—Windows 日志—安全里几个关键事件 ID 你必须要知道4624登录成功4625登录失败4672给予特殊权限4720创建用户账户如果 4625 事件在短时间内大量出现且失败原因子状态码是 0xC000006A密码错误或 0xC0000064用户名不存在结合 Wireshark 抓到的爆破流量基本就能实锤账号密码喷洒攻击。这时你的应对优先级是先确认是否有弱口令账号再考虑在防火墙或 IP 安全策略层面封禁源 IP。顺便说一句Windows 安全日志默认记录的信息有可能不够详细建议在本地安全策略—安全选项—审计中把审计登录事件调成成功和失败都记录。这样排查时日志才有价值。5.3 TLS 加密与 SMB3 加密的抓包差异最后提一个很多人容易忽略的点现代网络流量越来越透明但也越来越加密。SMB3.1.1 支持强制加密Server 2022 上可以针对共享设置加密数据访问。当 SMB 加密启用后你在 Wireshark 里看到的不再是明文协商和读写数据而是一个Encrypted标志。此时 Wireshark 默认的 smb2 解析器看到的只是加密后的载荷无法直接读到文件名和内容。这种情况下的排查思路有两个方向。一是从安全角度这是好事即使有人抓包也看不懂业务数据这也符合纵深防御的理念。二是从排错角度加密给分析增加了难度你可以临时在服务端关闭加密仅测试环境或者配置 Wireshark 的 TLS 解密功能如果是基于 TLS 的 SMB over QUIC 等场景用 SSLKEYLOGFILE 等方式解密后分析。不过生产环境关闭加密要谨慎一旦涉及等保或安全合规要求宁可用抓包软件的密钥注入功能也不要动业务配置。对于个人学习我建议你把 SMB 加密这个点玩透因为现在企业里抓包抓到一堆密文、看不懂的困境越来越常见提前掌握解密分析的思路对工作很有帮助。6. 常见问题与排查技巧实录6.1 Wireshark 常见使用问题抓包软件本身也有一些坑我在培训时几乎每次都会遇到学员踩到索性统一整理一下。第一个问题是抓包后一片空白什么流量都没有。优先检查三件事选对网卡没有混杂模式开没开Npcap 驱动装没装。这三个占了 90% 的原因。还有一个小概率问题是 Windows 防火墙拦截了 Wireshark 的驱动通信遇到这种情况以管理员身份运行 Wireshark 通常就能解决。第二个问题是我过滤表达式写对了但看不到预期的包。这时候别急着改表达式先清空过滤条件看全量流量里到底有没有这个协议。如果全量里有再慢慢加过滤条件缩小范围。如果全量里都没有说明流量根本没走到这台机器或者抓包位置不对比如源和目标之间经过了加密隧道。第三个问题是想抓 Loopback本机回环流量。Windows 上 Wireshark 默认抓不到本机访问本机的流量需要在 CMD 里安装 Npcap Loopback Adapter或者在 Wireshark 里选择Adapter for loopback traffic capture接口再结合路由规则才能抓到。这个我建议新手直接放弃用远程两台机器来复现就好。还有一个细节是关于显示过滤器表达式的性能。比如你想筛选 SMB2 的多个命令写成smb2.cmd 0 || smb2.cmd 1 || smb2.cmd 3是没问题的但如果条件越来越多建议用smb2.cmd in {0 1 3}这种集合语法不仅简洁匹配性能也更好。6.2 抓包排错的几个习惯下面这些经验是我多次在深更半夜处理故障时换来的分享给你。第一抓包前先想清楚我要验证什么假设。没有目标的抓包就是大海捞针你会被上千个无关的广播包淹没。比如前面 ping 不通的例子我的假设是网络层 ARP 是否能成功那我就会先把过滤条件设为 arp抓几个包验证这个假设不对再调整。第二保存 pcapng 文件时别偷懒文件名写清楚日期、源和目的、协议、问题现象。我用过这种命名格式20250115_win10_to_srv2022_smb2_slow_transfer.pcapng。三个月后你翻回来看到文件名就知道当时在干什么不用重新回忆。第三善用着色规则。Wireshark 默认把 TCP 重置RST标成红色把重传标成浅黄色。你可以自己定义 SMB2 错误响应也标成醒目颜色这样在长会话里快速定位异常点非常高效。设置路径视图—着色规则添加一条协议为 smb2、字段为 smb2.nt_status 且不等于 0 的规则颜色选亮红。第四动手前先看时间列。遇到慢的问题我第一件事就是看 Wireshark 的时间间隔用Seconds Since Previous Displayed Frame显示。如果两个包之间间隔长达数秒问题往往在网络超时或应用层阻塞如果每个包间隔都很短但整体耗时很长那问题通常是协议层面的交互太多或某个环节在反复重试。这个细节能把定位范围缩小一大半。第五也是最重要的一条不要在问题发生时边抓边想而是先无脑抓 30 秒存好现场再慢慢分析。线上故障是分秒必争的但分析可以在事后慢慢做。现场没了神仙也难查。6.3 从实验到生产你还可以这样扩展到这里实验环境里的基础分析已经闭环了。但如果你想把这套技能用到生产环境我建议按以下路径继续深化。你可以把这套环境扩展到三层架构客户端—交换机—服务器在交换机上配置端口镜像把服务器上联口的流量镜像到分析口再在分析口接一台装有 Wireshark 的机器。这样你就能在不影响业务的情况下实时观察服务器收到的所有流量。端口镜像是一个非常重要的技能很多网工干了几年都没在真实交换机上配过建议找台 Cisco 或华为的模拟器练一练命令差异不大但思路完全一样。你还可以把抓包分析跟 Windows 性能监视器联动。比如用户报复制文件慢你一边抓 SMB2 流量一边开 PerfMon 看服务端的Server Reconnects、SMB Client Credits Outstanding等性能计数器两边一对照瓶颈在客户端还是服务端很快就能分辨。还有一个值得玩的方向是用 Wireshark 训练自己的协议直觉。建议你每周花半小时随便找一个 pcap 文件不依赖过滤器纯肉眼扫一遍包列表快速回答三个问题这个会话是什么协议建立的哪一步用了最长时间有没有任何异常标志位坚持一个月你对网络交互的理解会上一个台阶。我个人在实际操作中的体会是OSI 七层模型和 Wireshark 这套组合拳真正牛逼的地方不在于让你看懂每一个字节而在于给你一套系统性的思考框架。遇到任何网络故障你不再慌张而是能冷静地把问题拆到具体的层次再用合适的工具去做验证。这种能力光看书学不会必须靠一次次的抓包、一次次的复盘练出来。希望今天这篇实战拆解能帮你少走一些我当年走过的弯路。