OpenVPN 在家能用但某个网络不行：UDP 还是 TCP？

同一个配置在家能连上，却在酒店、校园或分支机构网络里卡住。凭据没有变化，所以真正值得关注的变量是路径：OpenVPN在读取数据包之前它们经历了什么。按可测试的顺序比较四种可能原因，比猜测证书问题更有效。每种原因留下的痕迹不同，而正是痕迹把它们区分开。

哪一阶段失败，决定哪种比较关键

客户端日志已经记录了走到哪一步。如果出现「TLS 密钥协商在超时内未发生」，说明第一个数据包发出后没有任何可用回应返回，这指向路径。证书被拒则完全不同：先有回应到达，然后某个具体的验证错误说明原因。记下重试循环前的最后一行，因为那正是你要跨网络比较的值。

要在重试过程中抓包，而不是事后。在客户端上，tcpdump -ni any udp port 1194能看出到底有没有回应回来。在你自己掌控的服务器 WAN 接口上重复一遍，就能看出这些数据包是否到达远端。

单向流量是这里最有价值的结果，因为它把间歇性的抱怨变成可调查的方向。保留抓包文件，因为下一次同样问题的报告，用证据比用描述更容易结案。

UDP 过滤与端口关闭

许多接入网络把持续 UDP 视为可疑，部分运营商也持同样看法。端口关闭在客户端一侧造成的沉默完全相同。区别在选择性地：过滤器往往挑剔地丢弃某些目标或端口，而关闭的端口会拒绝所有发往该端口的东西。

在 443 端口上使用 TCP 配置是常见做法，因为它看起来像普通 HTTPS 流量，能穿过大多数强制门户和出口过滤。但必须满足两个条件。服务器要以 proto tcp-server 监听，客户端要以 proto tcp-client 匹配，而且运营方必须公开那个替代入口。把能用的 UDP 配置改写声称 TCP 443，而在另一端根本没人监听，是毫无用处的。

端口关闭是配置问题，不是审查问题。家用路由器后面的服务器需要转发 UDP 端口，路由器防火墙也必须放行。如果端口从未被允许，无论凭据如何，每个客户端都会在协商阶段失败，而且故障跟着服务器走，而不是跟着网络走。

老旧协议在这方面表现很差。PPTP 需要 TCP 1723 加 GRE，而 GRE 是 IP 协议 47 而不是端口，所以普通的端口转发无法表达它。

当是交换机在丢包

受管交换机可能故意丢弃隧道。部分 HPE 和 Aruba 型号在高级安全设置里提供 UDP 泛洪防护控制，有时标为 Prevent UDP Blat Attack。该控制一旦启用，交换机后面的服务器不会回应任何请求，所有客户端都以同样方式超时。取消它并保存运行配置就是全部修复，但前提是你先确认交换机确实在路径上。

反证才能把交换机丢包和运营商封锁区分开。在向运营商报障之前，先读接口计数器和泛洪防护日志。带 DoS 或泛洪防护的家用路由器也会以同样形态失败，任何 UDP 空闲超时很短的中间设备也一样。始终完不成的握手暗示丢包，而安静几分钟后断掉的隧道暗示超时。

修改配置前，把客户端与服务器之间的每台设备写下来。修错层看起来正确，直到换到下一个网络。这份清单也能让下一位工程师知道该看哪里，而不必重做整套排查。

看起来像 DNS 故障的地址重叠

在 10.0.0.0/8 内编号的接入网络可能与隧道地址池重叠，而解析器通常就住在那个池里。当笔记本在 Wi-Fi 上拿到 10.184.178.50 这类地址并带 /8 掩码时，按定义每个 10.x 目标都是本地。发往 10.4.0.1 的数据包于是走局域网，隧道保持在线，而名称解析失败。

ip addr 一眼就能看出重叠，ip route get 10.4.0.1 则显示数据包实际会被送到哪里。由于可见症状是解析器失败，这个问题往往能扛过好几轮 DNS 改动。

重新编号地址池，或者把那个接入网络排除在范围之外。任何客户端设置都无法从地址重叠中恢复。

在 TCP 备用线路与修复路径之间做选择

当你无法控制路径、用户今天就要能用时，选 TCP 备用线路，并接受它的代价：TCP 套 TCP 在丢包链路上表现很差，备用线路还需要你自己维护一个监听端口。当封锁位于你自己拥有的基础设施上时，选修复路径，因为一条防火墙规则比第二个监听更便宜。无论哪种，都按顺序逐层排查：链路、外层传输、协商、内网路由。在那个网络上失败的那一阶段，才是唯一重要的事实。

按网络记录结果，而不是按用户。下一次同样故障的报告就会从已知阶段开始，而不是从证书理论开始。如果需要，这份记录也正是长期保留第二个监听的理由。