【AI 生成】探索校园网的 TCP 445（SMB）端口
前言
自从有一次观看了字幕组制作的带有精品字幕的动漫后，我养成了本地看片的习惯。苗头在四五年前就已经产生，上半年换手机得到了第一部 iPhone，自然也接触到了 infuse。
由此可见，我接触到媒体服务器就是水到渠成的事了。在今年的寒假，当时尚未接触到 Emby、Jellyfin、Plex 这些主流，先是自己捣鼓了自己的 Windows SMB。在家里自然是靠着 192.168.xxx.xxx 秒成功，于是自然就想，学校如此广阔，如果能够自如地在校园网内远程访问，岂不美哉？
从 10 号开始我就开始陆陆续续地攻克校园网，iPhone 究竟是为何连接不上 smb:\\，急得抓耳挠腮。昨天搜索到一篇知乎的提问，终于有了眉头，于是连夜添加提醒事项，告诉自己明日一定解决。于是今天和 ChatGPT 搏斗一下午，和浩如烟海的 PowerShell 命令扭打在一起，犹如周处大战白额猛兽、长桥下蛟，终于得出了结论。
我让 ChatGPT 直接帮我形成日志，摘录这个下午的路途。
如下：
一次从 Windows SMB、Windows 防火墙、TCP 抓包到校园网环境对比测试的联合排查记录
简介
本文记录了一次 Windows 共享文件夹无法通过校园网 SMB 访问的排查过程。通过检查 SMB 服务、TCP 445、防火墙规则、网络接口，并结合普通端口测试、pktmon 抓包和个人热点对照实验，逐步排除 Windows 与客户端自身问题，最终将故障范围定位到校园网络环境对 TCP 445 / SMB 连接的处理。
一、问题背景
我的目标是：
在校园网环境下，通过 iPhone / iPad 的「文件」App，使用 SMB 访问 Windows 10 电脑上的共享文件夹。
Windows 电脑和 iPhone / iPad 位于同一个校园网络环境中。
最初的现象是：
- Windows 自己访问 SMB：正常
- Windows 上 SMB 服务正常运行
- iPhone 可以访问 Windows 上的普通 HTTP 服务
- 但是 iPhone 通过
smb://[Windows-IP]无法连接 - iPhone「文件」App 提示类似 “Socket 未连接”
因此最初无法确定问题究竟出在哪里：
- Windows SMB 服务是否正常？
- Windows 防火墙是否阻止了 445？
- Windows 是否真的监听了 TCP 445？
- 校园网络是否限制了 TCP 445？
- iPhone 的 SMB 客户端是否存在问题？
- Windows 上是否存在第三方网络过滤软件？
于是开始逐层排查。
二、第一步：确认 Windows SMB 服务
首先检查 Windows 的 Server 服务：
Get-Service LanmanServer结果：
Status Name DisplayName
Running LanmanServer Server说明：
Windows 的 SMB Server 服务正在运行。
因此可以排除“SMB 服务根本没有启动”的可能。
三、第二步：确认 TCP 445 正在监听
执行：
Get-NetTCPConnection -LocalPort 445 -State Listen结果：
LocalAddress LocalPort RemoteAddress RemotePort State
------------ --------- ------------- ----------- --------
:: 445 :: 0 Listen说明 Windows 确实在监听 TCP 445。
这里的：
::代表 IPv6 的通配监听地址。
同时 Windows 后续的 IPv4 测试证明，这个监听也能够处理当前 IPv4 路径。
因此可以排除：
“Windows 根本没有打开 445 端口。”
四、第三步：Windows 自己测试 TCP 445
使用：
Test-NetConnection 127.0.0.1 -Port 445结果：
TcpTestSucceeded : True再测试 IPv6：
Test-NetConnection ::1 -Port 445结果同样成功。
随后使用 Windows 自己的校园网 IPv4 地址进行测试：
Test-NetConnection [Windows-IPv4] -Port 445结果：
TcpTestSucceeded : True后续使用详细模式再次确认：
Test-NetConnection [Windows-IPv4] -Port 445 -InformationLevel Detailed关键结果：
InterfaceAlias : [有线网络接口]
SourceAddress : [Windows-IPv4]
RemoteAddress : [Windows-IPv4]
RemotePort : 445
TcpTestSucceeded : True这说明：
Windows 使用自己的校园网 IPv4 地址访问 TCP 445，可以成功建立连接。
因此 Windows 自身的 IPv4 网络栈和 TCP 445 并没有明显异常。
五、第四步：检查 Windows 防火墙
因为 SMB 使用 TCP 445，所以检查 Windows 防火墙中与 445 有关的规则。
执行：
Get-NetFirewallPortFilter |
Where-Object { $_.LocalPort -eq 445 } |
Get-NetFirewallRule |
Select-Object DisplayName, Enabled, Profile, Direction, Action其中关键规则为：
文件和打印机共享(SMB-In)
Enabled : True
Profile : Private
Direction : Inbound
Action : Allow进一步确认：
Get-NetFirewallRule -DisplayName "文件和打印机共享(SMB-In)" |
Where-Object Enabled -eq True |
Get-NetFirewallPortFilter |
Format-Table Protocol, LocalPort, RemotePort -AutoSize结果：
Protocol LocalPort RemotePort
-------- --------- ----------
TCP 445 Any说明：
Windows 防火墙明确存在一条允许 TCP 445 入站的 SMB 规则。
六、第五步：临时完全放行 TCP 445
为了进一步排除 Windows 防火墙因素，临时创建一条允许所有配置文件访问 TCP 445 的规则：
New-NetFirewallRule `
-DisplayName "TEMP SMB 445 TEST" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 445 `
-Action Allow `
-Profile Any规则创建成功。
但是：
即使 Windows 防火墙被明确允许 TCP 445，iPhone 仍然无法通过校园网连接 SMB。
因此：
Windows 防火墙成为主要嫌疑的可能性进一步降低。
测试完成后，这条临时规则应该删除：
Remove-NetFirewallRule -DisplayName "TEMP SMB 445 TEST"七、第六步：使用普通 HTTP 服务测试网络连通性
为了证明问题不是“iPhone 根本无法访问 Windows”，我们使用 Python 临时启动 HTTP 服务。
例如：
python -m http.server 8080 --bind 0.0.0.0使用：
Get-NetTCPConnection -LocalPort 8080 -State Listen确认 HTTP 服务正在监听。
之后进一步使用：
Test-NetConnection [Windows-IPv4] -Port 8080确认 Windows 自身访问该端口成功。
最关键的是：
iPhone Safari 最终能够成功打开
http://[Windows-IPv4]:8080。
因此：
iPhone 可以通过校园网络访问 Windows 的普通 TCP 服务。
这排除了“校园网络完全无法访问这台 Windows”的可能。
八、第七步：使用更多普通端口进行对比
为了进一步研究校园网络是否存在端口过滤，我们进行了多个端口实验。
| TCP 端口 | 测试服务 | iPhone 访问 |
|---|---|---|
| 445 | SMB | ❌ |
| 4444 | HTTP | ❌ |
| 4450 | HTTP | ✅ |
| 4466 | HTTP | ✅ |
| 8445 | HTTP | ✅ |
这个结果非常重要。
它说明：
不能简单地得出“校园网禁止所有 445 附近的端口”。
因为其他高位端口可以正常访问。
因此我们不能仅仅根据端口号附近的范围来判断校园网络策略。
九、第八步：使用 pktmon 抓包
为了不再依靠猜测，而是直接观察 TCP 数据包，使用 Windows 自带的 pktmon 进行抓包。
首先：
pktmon filter remove
pktmon filter add -p 445
pktmon start --etw -m real-time然后使用 iPhone 尝试：
smb://[Windows-IPv4]十、第一次抓包：最初的判断
第一次抓包中可以看到：
[客户端内网地址]:[临时端口] > [Windows-IPv4]:445
Flags [S]也就是：
iPhone 发出的 TCP 连接请求确实到达了 Windows。
当时没有明显看到 Windows 返回的 SYN-ACK，因此一度怀疑：
Windows 本地防火墙可能仍然阻止了连接。
于是进行了前面的“临时完全允许 TCP 445”实验。
但即使放行后问题仍然存在。
因此需要再次抓包。
十一、第二次抓包：真正的关键证据
第二次抓包是在临时防火墙允许规则存在的情况下进行的。
这次抓到了完整的关键过程。
1. 客户端发出 SYN
抓包中出现：
[客户端内网地址]:[临时端口] > [Windows-IPv4]:445
Flags [S]这表示：
iPhone 正在请求建立 TCP 445 连接。
而且这个 SYN 确实到达了 Windows。
2. Windows 返回 SYN-ACK
随后抓包出现：
[Windows-IPv4]:445 > [客户端内网地址]:[临时端口]
Flags [S.]也就是：
Windows 收到了 iPhone 的 SYN，并且向 iPhone 返回了 SYN-ACK。
这是整个调查中最关键的发现之一。
它证明：
Windows 并没有单方面拒绝 iPhone 的 TCP 445 请求。
Windows 确实在响应。
3. 但是客户端没有返回 ACK
正常 TCP 三次握手应该是：
客户端 Windows
SYN -------------------->
<---------------- SYN-ACK
ACK -------------------->
TCP 连接建立而实际情况是：
客户端 Windows
SYN -------------------->
<---------------- SYN-ACK
ACK - - - - - - - - - -> ❌ 没有出现Windows 又多次发送 SYN-ACK：
Windows → 客户端
Flags [S.]但是仍然没有看到客户端返回 ACK。
最后 Windows 发出了：
Windows → 客户端
Flags [R]即 TCP RST。
所以实际过程可以概括为：
SYN ✅
SYN-ACK ✅
ACK ❌
RST ✅十二、这改变了我们的判断
到这里，我们已经可以排除很多早期猜测。
已经基本排除
1. SMB 服务没有启动
不是。
LanmanServer = Running2. Windows 没有监听 445
不是。
TCP 445 = Listen3. Windows 自己不能使用 445
不是。
Windows → 自己的 445 = True4. 普通 Windows 防火墙规则阻止
可能性已经很低。
因为：
- SMB-In 已经允许 TCP 445
- 又临时增加了
Profile Any的允许规则 - 问题仍然存在
5. iPhone 完全无法访问 Windows
不是。
因为多个其他 TCP 端口曾经成功访问。
十三、第九步：检查 Windows 网络接口
为了排除网卡本身的问题，检查：
Get-NetIPInterface -AddressFamily IPv4 |
Format-Table ifIndex,InterfaceAlias,ConnectionState,NlMtu,InterfaceMetric结果显示当前使用的：
[有线网络接口] Connected 1500实际网络连接使用的是：
Windows 当前启用的有线网络接口。
其他无线网络接口处于未连接状态。
因此可以确认：
当前校园网连接使用的是有线网络路径。
十四、第十步：检查第三方网络组件
由于系统中存在第三方网络优化相关组件，因此一度考虑是否存在第三方软件干扰 SMB。
进一步检查当前有线网卡的网络组件绑定：
Get-NetAdapterBinding -Name "[有线网络接口]" |
Format-Table DisplayName,ComponentID,Enabled可以看到常见的：
Internet 协议版本 4 (TCP/IPv4)
Microsoft 网络的文件和打印机共享
Microsoft 网络客户端
Internet 协议版本 6 (TCP/IPv6)
QoS 数据包计划程序但没有发现明显的第三方网络过滤组件绑定到当前使用的有线网卡。
因此：
没有足够证据把问题归因于 Windows 上的第三方网络优化软件。
最终也没有继续修改或强制停止相关服务。
十五、第十一步：决定性实验——脱离校园网
经过前面的调查，仍然存在一个重要问题：
到底是校园网络的问题，还是 iPhone / Windows 在 SMB 上存在某种兼容性问题？
因此进行了最有决定性的对照实验。
实验环境
让：
- Windows 电脑
- iPad
同时连接到：
iPhone 的个人热点
这样就完全绕开了校园网络。
网络结构变成：
iPad
│
▼
iPhone 热点
│
▼
Windows然后使用 Windows 在热点网络中获得的新 IP 地址，通过 SMB 访问。
结果：
SMB 秒成功。
十六、最终结论
这个实验是整个调查中最重要的证据。
因为在校园网环境：
iPhone → Windows SMB 445
❌而在 iPhone 个人热点环境：
iPad → iPhone 热点 → Windows SMB 445
✅ 秒成功因此可以非常有把握地得出：
Windows SMB 服务本身没有问题，iPhone/iPad 的 SMB 客户端也没有问题。问题只出现在校园网这一网络环境中。
结合之前的 pktmon：
校园网环境：
iPhone → Windows
SYN ✅
Windows → iPhone
SYN-ACK ✅
iPhone → Windows
ACK ❌
Windows
RST ✅以及：
个人热点环境：
iPad → Windows SMB
TCP 三次握手正常
SMB 登录正常
连接秒成功因此目前最合理的结论是：
校园网对 TCP 445 / SMB 连接存在网络层面的限制、过滤或其他特殊处理。
严格来说，仅凭本次实验还无法知道校园网设备究竟是：
- 主动丢弃 TCP 445；
- 对 TCP 445 的返回流量进行处理；
- 使用某种安全策略干扰 SMB；
- 或存在其他网络路径上的特殊规则。
因此不应该进一步声称“已经知道校园网设备具体是哪一台、具体哪条 ACL 在拦截”。
我们能够确定的是：
问题具有明显的“校园网相关性”，而不是 Windows SMB 或 iPad/iPhone SMB 客户端自身的问题。
十七、整个调查的逻辑链
整个排查实际上是逐层缩小范围：
最初：
iPhone 无法 SMB → 原因未知
│
▼
检查 LanmanServer
│
└── Running ✅
│
▼
检查 TCP 445
│
└── Listen ✅
│
▼
Windows 自测 445
│
└── Success ✅
│
▼
检查 Windows 防火墙
│
└── SMB-In Allow ✅
│
▼
临时完全放行 445
│
└── iPhone 仍失败 ❌
│
▼
普通 HTTP 端口测试
│
├── 其他端口 A ✅
├── 其他端口 B ✅
└── 其他端口 C ✅
│
▼
证明 iPhone 能访问 Windows
│
▼
pktmon 抓包
│
├── SYN 到达 Windows ✅
├── SYN-ACK 发出 Windows ✅
└── ACK 没有返回 ❌
│
▼
检查网卡 / 第三方过滤组件
│
└── 未发现明显异常
│
▼
换到 iPhone 个人热点
│
└── iPad → Windows SMB 秒成功 ✅
│
▼
最终结论：
问题与校园网环境高度相关十八、这次调查最重要的几个知识点
1. “端口开放”不等于“应用一定能连接”
例如：
TCP 445 Listen只能说明：
Windows 有程序在等待 TCP 445 连接。
真正建立连接还需要 TCP 三次握手：
SYN
SYN-ACK
ACK2. 抓包比单纯测试端口更加有价值
Test-NetConnection 告诉我们：
True / False但是 pktmon 能告诉我们：
SYN 到了没有？
SYN-ACK 发了没有？
ACK 回来了没有？
RST 有没有出现？这让我们最终能够知道：
连接究竟在哪一个阶段失败。
3. “Windows 防火墙允许 445”不能证明网络一定允许 445
Windows 本地防火墙只是：
Windows 本机的一层安全机制。
数据还要经过：
iPhone
↓
无线网络
↓
校园交换/路由设备
↓
校园网络安全设备
↓
Windows 网卡
↓
Windows 防火墙
↓
SMB因此即使：
Windows Firewall = Allow网络中的其他设备仍然可能对流量进行处理。
4. 对照实验非常重要
本次最终能够定位问题，很大程度上依靠了：
校园网环境
❌ SMB
iPhone 热点环境
✅ SMB这就是一个非常典型的对照实验。
我们没有修改 Windows SMB 配置，只改变了：
网络环境
结果 SMB 从失败变成成功。
这使得“校园网络环境导致问题”的解释具有很强的证据支持。
十九、最终建议
既然已经确认 Windows SMB 和 iPhone/iPad SMB 本身正常，就没有必要继续修改：
- Windows SMB 配置
- Windows 注册表
- Windows 防火墙
- 网卡 IPv4 配置
- SMB 协议版本
更合理的解决方向是：
方案 A：VPN + SMB
例如：
iPhone / iPad
│
│ VPN
▼
Windows
│
▼
SMB 445这样可以建立一条独立的私有网络。
方案 B：使用其他文件传输协议
例如 HTTP 文件服务器、SFTP 等，避开校园网对 SMB/445 的限制。
方案 C：继续使用 LocalSend
如果需求主要是：
iPhone ↔ Windows 临时互传文件
那么 LocalSend 是最简单的方案。
二十、结语
这次排查并不是一开始就知道“校园网封了 445”，而是通过一系列实验逐步排除其他可能。
最关键的证据分别来自：
- Windows SMB 服务正常
- TCP 445 正在监听
- Windows 自己连接 445 成功
- Windows 防火墙明确允许 445
- 临时完全放行 445 后仍然失败
- iPhone 可以访问多个其他 TCP 端口
- pktmon 证明 SYN 到达、SYN-ACK 发出，但 ACK 没回来
- 脱离校园网后，iPad → Windows SMB 秒成功
最终，我们把一个最初很模糊的：
“iPhone 为什么连不上 Windows SMB？”
逐步缩小成：
Windows SMB 正常；iPhone/iPad SMB 客户端正常；问题高度集中在校园网环境对 TCP 445/SMB 连接的处理上。
这就是本次“探索校园网 TCP 445（SMB）端口”调查的完整过程。