OpenVPN 使用 TCP 而不是 UDP

Question

我已经在 Debian（树莓派模型 b+）上成功设置了一个 OpenVPN 服务器。将协议设置为 TCP 后，它完全按预期工作（通过 VPN 路由互联网，访问本地网络机器），但是当我将协议设置为 UDP（我认为这对于提高速度是可取的）时，我发现我能够ping 任何主机（IP 地址或域名），我可以 telnet 和 ssh（再次是 IP 地址或域），但是当我尝试在浏览器中打开页面时，它似乎进行了初始连接，但随后从未加载。

你有什么想法为什么网页浏览会成为 UDP 模式的问题？

我已经设置了 UFW 来管理 iptables，为此添加了主配置行 before.rules

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

由于 TCP 一切正常，UDP 几乎可以正常工作，因此我认为问题不在于防火墙/iptables，但我可能是错的。

我的 openvpn 服务器配置是

local 192.168.0.31
dev tun
proto tcp
port 1194
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.31 255.255.255.255"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.0.31 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"
push "redirect-gateway def1"
push "explicit-exit-notify 3"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth ta.key 0
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 1

有没有人有任何想法为什么可能会出现问题？

Answer 1

这些特定症状（使用 VPN）是相当常见的症状，表明您的路径 MTU 存在问题。

MTU基础知识

路径 MTU（最大传输单元）是可以在互联网（或任何其他网络）上的两个设备之间穿越的最大数据包。路径上的每条链路都有自己的 MTU，它可能与其他链路匹配，也可能不匹配。总路径 MTU 是沿整个路径的最低 MTU。

如果您的计算机尝试发送大于路径 MTU 的数据包，则数据包会在超出的跃点处被丢弃，并且数据将永远不会到达。在行为良好的网络中，您的计算机应该收到错误响应并知道自动调整 MTU 和/或分割后续数据包。在表现不佳的网络上，它可能会被悄悄丢弃。

路径 MTU（自动）发现是用于自动检测您和 VPN 服务器之间的 MTU 的机制，但是它在行为不良的网络上使用 TCP 比使用 UDP 更强大，因为 TCP 强制要求明确的反馈，可以告诉您哪些数据包不没到。

它以 VPN 链接的方式运行的原因是因为 VPN 封装标头减少了隧道连接的 MTU，并且因为 UDP 不提供有关丢弃数据包的反馈。

例如，如果您的实际 PMTU 是 1400 字节，那么通过 VPN 发送 1400 字节的数据包可能需要 1432 字节。通过 TCP 连接，如果您尝试发送 1432 字节的数据包，TCP 可以告诉它没有到达并将其分段并作为 1400 字节的数据包和第二个 32 字节的数据包再次发送（尽管如此，这是一个粗略的简化）。使用 UDP，它只是默默地丢弃。但是，在这两种情况下，发送任何小于 1400 字节的数据包都会成功。

这就是 SSH 和 telnet 有效而网页浏览无效的原因。您的 VPN 已将您的 MTU 降低到您的默认值以下，但您的操作系统尚未意识到，因为错误消息未正确返回或 PMTU 自动发现不起作用。但是因为 SSH 和 telnet 和 ping 都使用非常小的数据包（通常 <100 字节），如果您的 MTU 已经从 1400 减少到 1368（1400 - 32），则没关系，因为它们仍然比限制小得多. SSH 和 telnet 通常一次发送一个字节和一行，以及数据包头。Ping 数据包通常最多 64 字节加上数据包标头，同样比任何正常的 MTU (1400+) 小得多

Web 浏览最初连接是因为 DNS、TCP SYN/ACK 数据包和 HTTP 请求通常都比 1400 字节小得多，但是一旦网站尝试发送实际网页，它将使用全尺寸数据包，然后一路上默默地丢弃。

解决问题

有一种简单（作弊）的方法，另一种方法是找出问题的实际所在。

一种欺骗性的方法是手动将 MTU 设置得低得多 - 例如设置为 1000，因此即使 VPN 的 MTU 减少，所有内容都将适合。这本身就是一个很好的测试，看看 MTU 是否有问题。

更好的方法是找出问题所在，并解决它。MTU 自动发现问题可能是由于糟糕的服务器或 ISP（您无能为力）或本地防火墙/配置问题（您可以修复）而出现的。可能是您的 OpenVPN 路由和防火墙规则不允许 ICMP 错误消息返回到您的机器。

一种中间方法是找出真正的最大 MTU 并手动设置它 - 您可以从 1000 字节这样的小东西开始，然后向上工作以找到有效的最高值。基本上，使用 UDP 连接您的 VPN，然后使用命令通过 VPN ping 某些东西ping -f <server address> -l <packet size>并向上增加数据包大小，直到它停止工作 - 无论是超时还是错误。