周一早上九点，朋友发消息过来：
“兄弟，救命。我们这边几个同事在家里远程办公，VPN 都连上了，但是 OA 打不开。你帮我看看。”
我问他：报什么错？
他发了张截图过来——浏览器一直转圈，最后提示“无法访问此网站”。VPN 客户端那边，绿灯亮着，状态显示“已连接”。
这是网工日常里最常见、也最让人头大的一类问题：VPN 明明连上了，但业务就是用不了。
用户只会跟你说一句话：“你们的 VPN 又坏了。”
但真相是——VPN 根本没坏，坏的是 VPN 连上之后那一长串的东西。80% 的问题，不在 VPN 本身。
今天这篇想把这类问题彻底拆一遍。不绑品牌，EasyConnect、FortiClient、AnyConnect、OpenVPN、SSL VPN、IPSec 都适用——因为底层逻辑是一样的。
01
PART
先建立一个心智模型：“VPN 已连接” ≠ “能用”
绝大部分网工（包括我自己早期）的误区是：VPN 客户端显示“已连接”，就觉得通道没问题，开始去查业务侧。
错。
“VPN 已连接”只证明一件事：你的终端和 VPN 网关之间，建立了一条加密隧道。
它不证明：
你有权限访问 OA
你的终端能解析 oa.company.com（http://oa.company.com/） 这个域名
你的流量真的走了 VPN 这条路
OA 服务器的返回包能回到你这里
OA 服务器本身是活的
一次完整的 OA 访问，要走完下面这 6 步，任何一步断了都是“连上了但打不开”：
认证通过 → 权限下发 → DNS 解析 → 路由命中 → 服务端响应 → 返回路径通畅
你盯着客户端的绿灯，只能证明第 1 步。后面 5 步，一个都没验证。
记住这个模型，排错速度能快一倍。
02
PART
按链路排查：四步定位到问题层
第一步：权限层——你有没有被授权访问 OA？
很多 SSL VPN 产品是基于资源授权的——不是你连上就能访问全内网，而是管理员给你配了“OA 资源”、“邮件资源”、“ERP 资源”，你才能访问对应的内网段。
排查动作：
一是登录 VPN 的 Web 门户，看资源列表。如果 OA 资源根本不在你的列表里，就是权限没分配，找管理员。
二是如果 VPN 用的是 AD/LDAP 对接，确认用户是不是在正确的 AD 组里。
真实的坑：VPN 侧的权限和 AD 侧的组同步可能有延迟，甚至不同步。有次朋友那边新入职的员工 AD 账号开好了，部门组也加了，VPN 死活访问不了 OA——最后发现是 VPN 设备上的 LDAP 缓存没刷新。先尝试在 VPN 设备上手动刷新 LDAP 缓存或重连 LDAP 会话，必要时在变更窗口再重启服务。生产环境别第一反应就重启。
第二步：DNS 层——oa.company.com（http://oa.company.com/） 解析到哪儿去了？
这是最高频的坑，大约一半的“连上了但打不开”都卡在这里。
排查命令（Windows）：
正常情况下，oa.company.com（http://oa.company.com/） 应该解析到一个内网 IP（比如 192.168.x.x 或 10.x.x.x）。
如果解析不出来，或者解析到一个公网 IP（甚至是 127.0.0.1 这种），就是 DNS 出问题了。
三种常见的 DNS 模式，坑在哪儿不一样：
模式 A：VPN 下发内网 DNS 给终端
连上 VPN 后，终端的 DNS 服务器被改成了内网 DNS（比如 10.0.0.53）。所有域名都走内网 DNS 解析。
坑：公网域名（百度、知乎）解析可能变慢，因为内网 DNS 要递归转发。
坑：如果内网 DNS 挂了，整个终端的域名解析全废。
模式 B：Split DNS
内网域名（.company.com）走内网 DNS，公网域名走公网 DNS。
坑：Split DNS 的配置是在 VPN 服务端下发的，各厂商实现差异大。部分 Windows 版本和 Split DNS 实现，会出现多 DNS 并行查询、谁快用谁的情况——结果公网 DNS 比内网 DNS 快，返回了“域名不存在”，内网 DNS 的正确结果反而被丢了。
排查：nslookup oa.company.com 10.0.0.53 直接指定内网 DNS 查一下，如果能查到，就是 Split DNS 没生效。
模式 C：VPN 不下发 DNS，只给路由。 终端 DNS 不变，但 10.0.0.0/8 的路由指向 VPN 网关。
坑：这种模式下，oa.company.com（http://oa.company.com/） 根本解析不出来——因为公网 DNS 不认识这个内网域名。
解决：要么让用户手动改 hosts，要么服务端下发 DNS，要么用 IP 直接访问（但多数 OA 不推荐直接用 IP 访问，容易证书不匹配或触发跳转异常）。
另一个常见坑：加速器 / 代理 / 安全软件接管 DNS
现在很多人电脑上装着游戏加速器、科学上网工具、企业代理（SASE / 零信任客户端）、部分 EDR。这些工具可能接管 DNS 请求或代理全部流量。VPN 连上之后，DNS 请求根本没走到 VPN 下发的 DNS 上去。
排查方法：让用户临时关掉所有加速器和代理工具，再试一次。经验上这一条能解掉大约 20% 的“疑难杂症”。
第三步：路由层——流量真的走 VPN 了吗？
DNS 解析对了，还不够。流量得真的从 VPN 的隧道出去。
排查命令（Windows）：
正常情况下，oa 的内网 IP 对应的下一跳，应该是 VPN 虚拟网卡的网关。
注意：很多内网设备默认禁 ICMP，tracert 中间几跳打星号不代表链路断，最终以路由表和服务端抓包为准。
Full Tunnel vs Split Tunnel：
Full Tunnel：所有流量都走 VPN。安全但慢，看视频、打游戏都会被企业出口限速。
Split Tunnel：只有内网流量走 VPN，公网流量走本地宽带。体验好但有安全风险。
现在不少企业默认用 Split Tunnel。但 Split Tunnel 的路由下发有个经典问题——跟用户家里的网段冲突。
真实场景：
公司内网是 192.168.1.0/24，用户家里路由器也是 192.168.1.0/24。VPN 下发了 192.168.1.0/24 的路由给 VPN 网卡，和本地物理网卡上同一个段的直连路由撞在一起——Windows 系统的路由匹配是最长前缀 + 接口 metric，这时流量到底走哪个接口要看 metric 比较，很可能走到了用户家里的路由器，而不是 VPN。
表现就是：VPN 连上了，内网段路由也看着下发了，但 ping 内网 IP 不通，或者间歇性通。
解决：让用户换个网段的家庭网络（比如改成 192.168.100.0/24），或者让企业内网改一个不常见的网段（比如 10.233.x.x）。
另一个常见坑是路由优先级。同一目的地址下，最长前缀优先，所以明细路由不会被默认路由抢走——但要注意策略路由（PBR）、接口 metric、VPN 客户端过滤等因素可能打破这个默认行为。两种常见例外：一是 Full Tunnel 下发 0.0.0.0/0，和本地默认路由同为 /0，这时看 metric 决定走哪条；二是 Split Tunnel 下发的内网明细路由没下发成功（被系统拦了、或者客户端 bug），路由表里压根没这条，流量只能走默认路由出公网，当然不通。route print 看一下 metric 列和明细路由在不在，就能发现。
第四步：服务端层——OA 本身是不是出问题了？
走到这一步，前三层都排除了，就得往服务端看。
几个常见情况：
一是 OA 服务器的白名单。
有些 OA 系统做了源 IP 白名单，只允许办公网段访问。VPN 用户的虚拟 IP 段（比如 172.16.100.0/24）如果没加到白名单里，服务器直接丢包，表现就是“连得通但打不开”。
排查：在 OA 服务器上抓包（tcpdump 或 Wireshark），看有没有收到用户的 SYN 包、有没有回 SYN-ACK。如果 SYN 到了但没回 SYN-ACK，要结合服务器本地防火墙（iptables / Windows 防火墙）、云安全组、回程路由综合判断，不能单凭抓包就断定是白名单。
二是 OA 服务器限制了多地登录。
有些 OA 做了“同一账号不能在两个 IP 同时登录”的策略。用户在办公室登了一次，回家又用 VPN 登，被踢掉或者直接拒绝。
表现：登录页能打开，但一登录就报错或者转圈。
三是 HTTPS 证书问题。
内网 OA 用的是自签 CA 的证书，用户的终端没导入根证书。浏览器直接拦截，提示“连接不安全”。
解决：让 IT 把根证书推给所有终端（通过 AD 组策略或 MDM）。
四是 TLS 版本不匹配。
老的 OA 系统只支持 TLS 1.0/1.1，新版 Chrome / Edge 已默认禁用，Firefox 新版也默认禁用。
表现：报 ERR_SSL_VERSION_OR_CIPHER_MISMATCH。
解决：要么升级 OA 服务端，要么临时救急——改浏览器配置重新开启旧协议，或用仍支持旧协议的浏览器。
五是 MTU 问题（最隐蔽）。
VPN 隧道会在原始包外面加一层封装。IPSec 隧道模式常见额外开销约 50~73 字节（启不启 NAT-T、是否含 ESP 填充都有差别），SSL VPN 取决于具体封装方式，常见 40+ 字节。如果终端还是按 1500 的 MTU 发包，封装之后超过了链路 MTU，被中间设备分片或直接丢弃。
表现：ping 小包正常，访问网页卡死——因为 TCP 三次握手包小不受影响，真正传数据的大包过不去。
排查命令：
1472 只是 IPv4 以太网无封装下的测试起点，VPN 场景更常见从 1400、1380 往下试。如果 1472 不通、1400 通，就是 MTU 问题。VPN 客户端或网关上把 MTU 调到 1400 左右，一般能解决。
03
PART
动手之前先问三个问题，范围能砍掉约 80%
上面讲了四层排查，但不是每次都要从头走一遍。真正高效的做法，是先用三个问题把问题范围圈小。
问题一：是一直打不开，还是突然打不开？
一直打不开——通常是权限、路由、DNS 配置问题。
突然打不开——通常是服务端、链路或策略变更。
问题二：是所有系统都打不开，还是只有 OA？
所有系统都打不开——基本是 VPN 隧道、路由、DNS 层的问题。
只有 OA 打不开——基本是权限、OA 服务端、或 OA 走的特定端口被拦。
问题三：别人能不能打开？
只有一个人不行——终端、本地网络、账号权限问题。
一个部门不行——AD 组、权限策略问题。
所有人都不行——VPN 网关、OA 服务端、链路问题。
这三个问题问完，排查范围能砍掉约 80%。
04
PART
几个过来人的坑，踩过一次就记一辈子
第一，别只看 VPN 客户端的绿灯。 绿灯只证明隧道建立，不代表业务通。永远从“业务能不能用”反推，不要从“VPN 连没连上”正推。
第二，先看现象描述，再上手。 用户说“VPN 用不了”——是打不开 OA？还是 OA 打开但点进去报错？还是只有附件下载不下来？不同的描述对应不同的问题层，上手之前一定问清楚。
第三，远程排查，让用户发截图而不是发文字。 用户说的“报错了”和截图里的“报错了”，可能差了十万八千里。
第四，善用对比。 同样连 VPN，别人能用，你不能用——那就是你本地或权限的问题；所有人都不能用——那就是服务端或网关的问题。对比法是远程排查最快的工具。
第五，重装 VPN 客户端是最后的手段，不是第一个动作。 很多网工偷懒，一上来就让用户“卸载重装”——有时候能解决，但经验上大多数时候只是碰运气。真正的问题没找到，下次还会复发。
05
PART
写在最后
VPN 的本质，是把一段互联网链路变成企业网络的延伸。但“延伸”这件事，涉及加密、认证、路由、DNS、权限、服务端策略——任何一环断了，用户感知到的都是同一句话：“你们的 VPN 又坏了。”
网工被骂多了，容易陷入一个误区：听到“VPN 坏了”就去查 VPN。 其实 VPN 本身坏的概率不到 20%，剩下 80% 都在它之外。
真正能解决问题的网工，不是那种对 VPN 产品最熟的，而是对“VPN 连上之后那一长串链路”最清楚的——知道流量从哪儿来、经过哪儿、到哪儿去，知道哪一层最容易出事，知道怎么用三个问题把范围缩到最小。
这篇讲的六步模型 + 四层排查 + 三个问题，你可以收藏下来。下次再遇到“VPN 连上了但 OA 打不开”的工单，照着这个思路走一遍，大概率半小时内能定位到问题层。
· · ·
互动话题：你遇到过最离谱的“VPN 连上了但用不了”是什么场景？评论区聊聊。
SPOTO 思博网络是全球 IT 人才在线教育品牌，深耕 ICT 职业教育二十余年。华为授权培训合作伙伴。课程涵盖思科、华为认证及云计算、Linux、PMP、软考、CISP 等方向，已服务全球 152 个国家和地区的 55 万余名学员。
学习改变命运，知识成就未来。如果你想在 IT 路上走得更远，SPOTO 思博愿做你的同行者。想在 IT 领域进阶，欢迎与我们同行。