VPN 连接失败或连接后很慢，应该如何系统排查？

简化版

VPN 排查要先分“连不上”和“连上后业务不通/很慢”。连不上重点看账号认证、证书、MFA、客户端配置、端口放行、NAT、IKE/TLS 协商和服务端日志；连上后不通重点看路由、DNS、防火墙策略、回程路由、NAT、MTU/MSS；很慢重点看 RTT、丢包、出口带宽、全隧道绕路、网关负载和加密 CPU。不要只盯客户端，要端到端分段定位。

详细版

排查路径可以拆成三类：

现象	优先检查
VPN 连不上	认证、证书、端口、协议协商、服务端日志
连上但访问不了	客户端路由、DNS、ACL、回程路由、NAT、MTU
访问很慢	RTT、丢包、带宽、网关负载、全隧道绕路

典型流程：

客户端是否能到 VPN 网关？
  -> 认证和协商是否成功？
  -> 是否拿到虚拟 IP 和路由？
  -> 目标域名是否解析正确？
  -> 请求是否到达 VPN 网关和目标？
  -> 响应是否按原路返回？

面试回答时要体现分层思路：客户端、网络路径、VPN 网关、内网目标、回程路径、性能指标。这样比“重启客户端、检查防火墙”完整得多。

完整版教学

一、先把问题分类，不要一上来抓瞎

VPN 问题看起来都叫“不能用”，但根因差异很大。第一步要问清现象：是完全连不上，还是能连但某些系统不通；是所有人都有问题，还是某个用户；是一直失败，还是高峰期慢；是公司 Wi-Fi 不行，还是家庭网络不行。

连不上 -> 控制面问题概率高
连上不通 -> 数据面/路由/策略问题概率高
连上很慢 -> 性能/路径/拥塞/MTU 问题概率高

分类能减少排查范围。例如连不上时查内网服务器路由意义不大；连上后某个网段不通时，反复改账号密码也解决不了。

VPN 排障先问现象，再分控制面、数据面和性能面，别把所有问题都归到“防火墙”。

二、连不上时先看客户端到网关路径

客户端必须能访问 VPN 网关的公网地址和端口。SSL VPN 可能走 TCP/UDP 443，IPSec IKE 走 UDP 500，NAT-T 走 UDP 4500，WireGuard 常走 UDP 自定义端口。如果运营商、公司出口或本地路由器拦截 UDP，就可能失败。

协议	常见检查
SSL VPN	TCP/UDP 443 可达，证书可信
IPSec/IKEv2	UDP 500/4500 可达
WireGuard	UDP 端口可达，peer key 配置正确
SSH Tunnel	TCP 22 或跳板端口可达

可以用 Test-NetConnection、nc、抓包、服务端日志确认请求是否到达网关。UDP 连通性不能只靠 TCP 端口测试判断。

三、认证和协商失败要看日志，而不是猜密码

认证失败可能来自密码、MFA、证书过期、时间不同步、用户组不允许、设备不合规。协商失败可能来自加密套件不匹配、IKE proposal 不一致、预共享密钥错误、证书链不可信。客户端提示通常很模糊，服务端日志更关键。

认证失败: user not allowed / invalid certificate / MFA timeout
协商失败: no proposal chosen / PSK mismatch / certificate verify failed

IPSec 里两端 proposal 必须匹配，包括加密算法、完整性算法、DH 组、生命周期等。只要一项不兼容，就可能协商失败。

四、连上后先确认是否拿到了正确地址和路由

连接成功后，客户端通常会获得虚拟 IP、DNS、路由和分流策略。没有这些，业务流量不一定进 VPN。排查时要看 VPN 客户端状态、系统路由表、DNS 服务器和域名后缀。

虚拟 IP: 10.250.0.23
路由: 10.20.0.0/16 -> VPN
DNS: 10.20.0.53

如果用户访问 10.30.1.10，但路由只下发了 10.20.0.0/16，请求不会进隧道。很多“某个系统打不开”的问题，本质是漏下发路由或策略。

五、DNS 要和 IP 连通性分开验证

排查时不要直接访问域名然后猜。应该先解析域名，看结果是否是内网地址；再直接访问解析出来的 IP，看网络是否通。这样能区分 DNS 问题和路由问题。

nslookup git.company.local
ping 10.20.1.10
curl -vk https://10.20.1.10

如果 IP 能通、域名不通，多半是 split DNS、DNS 后缀或内网 DNS 可达性问题。如果域名解析正确但 IP 不通，再看路由、防火墙和回程。

六、回程和防火墙要双向看

请求能从客户端到目标，不代表响应能回来。目标服务器可能没有到 VPN 地址池的路由，或者防火墙只允许内网源地址，不允许 VPN 地址池。排查要在目标侧抓包：有没有收到请求？有没有发响应？响应去了哪里？

客户端抓包: 发出 SYN，无 SYN-ACK
目标抓包: 收到 SYN，发出 SYN-ACK
网关抓包: 没看到 SYN-ACK 回来
结论: 回程路径或中间策略有问题

有些网关通过源 NAT 解决回程，但要评估审计影响。更规范的做法是让内网路由知道 VPN 地址池。

七、慢的问题要看路径和负载

VPN 慢可能是全隧道绕路、跨境链路 RTT 高、丢包重传、网关 CPU 加密瓶颈、出口带宽不足、用户本地上行差、MTU 黑洞、DNS 慢。不要只看带宽，要看分段延迟。

指标	说明
RTT	用户到 VPN 网关、网关到目标
丢包/重传	TCP 性能下降核心信号
网关 CPU	加解密和转发压力
出口带宽	全隧道时尤其重要
MTU/MSS	大包卡顿、部分网站慢

例如用户在上海，VPN 网关在美国，全隧道访问中国网站，流量先绕到美国再回来，慢是路径设计问题，不是单台服务器问题。

八、常见误区与追问

误区：VPN 问题都从重装客户端开始。 重装只能解决少数配置损坏问题，系统排查要先分控制面和数据面。
误区：连上 VPN 后访问不了就是账号权限。 也可能是路由、DNS、回程、ACL、NAT 或 MTU。
误区：ping 通就说明业务通。 ICMP 通不代表 TCP 端口、TLS、DNS 和应用协议都通。
误区：VPN 慢只能加带宽。 RTT、丢包、全隧道绕路、加密 CPU、MTU 都可能是主因。
追问：如何判断请求是否进入 VPN？ 看客户端路由表、抓 VPN 虚拟网卡包、看网关是否收到流量。
追问：为什么某些网站能打开，某些打不开？ 可能是 MTU/MSS、DNS 分流、策略路由或 HTTPS 大响应触发问题。
追问：多人同时慢怎么判断瓶颈？ 看 VPN 网关 CPU、连接数、出口带宽、丢包、上游链路和认证服务状态。

九、加强记忆

VPN 排障按“三段式”记：连不上查可达性、认证和协商；连上不通查路由、DNS、策略、回程和 NAT；连上很慢查 RTT、丢包、带宽、网关负载、全隧道绕路和 MTU。任何时候都要双向看包：请求到没到，响应回没回。

简化版

详细版