几乎每条 Windows VPN 投诉之后十分钟内都会出现这条建议:跑一次网络重置,它什么都能修好。事实并非如此,而且它一点也不精准。那个按钮会清空适配器、重新绑定协议、删除静态地址和默认路由、丢弃防火墙和过滤器条目,还顺手忘掉 Wi-Fi 配置文件。在一台隧道可用但配置错误的机器上,它把一个可诊断的故障变成一次没有记录的重建。先保存五样东西,你就留住了撤销的余地。

重置并不只针对 VPN 配置文件

VPN 连接只是共享网络栈的众多对象之一。移除并重新添加适配器会改变接口索引,而任何引用该索引的东西,从一条路由到一条防火墙规则再到第三方过滤器驱动,现在都指向已不存在之物。

虚拟化让情况更糟。Hyper-V 交换机、VMware 网桥、容器网络,以及自带虚拟适配器的 VPN 客户端,全都住在同一个空间里。一个重新安装基础网络栈的重置,可能让这些组件半途而废,结果机器报告硬件正常,却没有可用路径。

以上都不是“永远不要重置”的理由。它是“不要先重置”的理由:在一台你没有记录过的机器上,真正的故障也许只是一条路由或一个过期过滤器。重置是成功率很窄的宽口径工具,把它当作第一步,就意味着你永远不会知道两者中究竟是哪一个。

先保存证据,再保存设置

故障本身就是数据。记下确切的错误代码、发生时间、当时选中的配置文件,以及网关是否记录过任何尝试。一个说隧道从未收到应答的代码,与一个说认证失败的代码,指向完全不同的修复方向。重置之后你可能两者都无法复现。把坏掉的状态当作你即将花掉的资产。

趁机器仍然故障时抓取状态,存到机器临时目录之外的文件夹里:

mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xml

最后一条命令正是人们常常漏掉的,而它往往就是解释故障的那条。被卸载客户端残留的过滤器会以持久策略的形式存活,导出的 XML 是它们唯一的本地记录。在重置抹掉你正试图确认的东西之前,先读它。

保存那些不会自己回来的配置

有些设置会自动重建。静态地址、自定义路由、DNS 后缀、代理例外和防火墙规则不会。配置文件本身也不会,它们住在电话簿文件里,重置不会替你恢复。

What to saveWhere it livesWhy the reset loses it
VPN profilesrasphone.pbk in ProgramData or the user profileProfiles are not part of the adapter state
Static IP and DNSAdapter configurationAdapters are removed and recreated
Persistent filtersWFP policy storeFilter state is cleared with the stack
Third-party bindingsAdapter binding listComponents must be reinstalled manually
Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfter

证书列表比看上去更重要。网络重置不会销毁客户端证书,但列表会告诉你配置文件依赖哪些证书,以及是否有证书即将到期。重建之后才发现证书过期,等于白白浪费这次重建。

动手之前先写下回退路径

如果机器在远端,而 VPN 是你唯一的入口,重置可能终止你的会话,现场没人就再也回不去。在运行任何触碰适配器的操作之前,确认存在带外访问,或有人可以到现场。

把安装包和连接信息放在机器事后仍能取到的地方。一个必须从只能经隧道访问的厂商门户重新安装的客户端,是循环依赖,而这正是这类操作变成宕机的最常见方式。

然后记录你做了什么、为什么,包括确切命令。下一个人需要知道这次重置是实验还是决定,而“我们什么都试过了”不算记录。

重置之后分层测试

一次恢复太多会让结果读不出来。自下而上:适配器与地址,然后名称解析,然后隧道的身份阶段,最后应用。每一层都有一条能回答自己问题的命令:

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443

如果适配器层健康而解析不正常,停下来修解析。此时重装 VPN 客户端只会增加变量、拿走线索。只恢复你解释得清的设置,一次一项,每改一项就复查同一层。

例如微软自己关于错误 720 的排障指南,会把绑定问题与地址分配问题区分开,而不是开一张“全面重置”的方子;对这类错误代码来说,这才是正确的直觉。在抓起最宽口径的工具之前,先读代码在说什么。

相关文章