部分 VPN 流量被阻止流向安全端点

部分 VPN 流量被阻止流向安全端点

strongswan我有一个用于测试的VPN 服务器 ( ),我IKEv2通过各种系统(这里,我尝试了 Windows、Ubuntu 和 Android)连接到它,通常没有问题。今天早上,我在英国乘坐火车(Transpennine Express,使用Icomera.com) 并连接到板载 wifi。这是一个仅 IPv4 网络,并使用 OpenDNS 来阻止某些网站。不幸的是,他们阻止了 stack exchange,所以我连接到我的 VPN 以尝试绕过这些限制。它在某些网站上运行良好,例如 news.bbc.co.uk 和 twitter.com 的一些网站(它允许访问https://abs.twimg.com在某些地址(如/responsive-web/web/runtime.21a6d542388d1e3e4.js和)上有效/responsive-web/web/main.d9a47f436e41de1a4.js,但阻止了其他地址(如/responsive-web/web/i18n-rweb/en.10f7da63e9b736204.js/responsive-web/web/icon-default.3c3b224a61f8b0e54.png)。但是,其他域名根本不起作用;例如 google.com 和 amazon.com。 什么原因可能阻碍某些交流?

pingtraceroute在所有域上工作并返回有效 IP(通过 VPN 通过 v4 和 v6 - 如果我禁用 IPv6,问题仍然会出现)。通过telnet端口 80 连接到站点有效,但当我尝试时,wget它会在重定向后卡住(通常是重定向到 https,尽管下面的重定向到 http 地址失败):

wget -vv -4 google.com
--2019-09-02 08:39:18--  http://google.com/
Resolving google.com (google.com)... 172.217.18.14
Connecting to google.com (google.com)|172.217.18.14|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.com/ [following]
--2019-09-02 08:39:18--  http://www.google.com/
Resolving www.google.com (www.google.com)... 216.58.205.228
Connecting to www.google.com (www.google.com)|216.58.205.228|:80... connected.
HTTP request sent, awaiting response... ^C

使用adb(Android 调试 shell,连接到我的手机以防我的硬件出现问题),我尝试了相同的操作 - 它没有wget,所以我使用了curl,但结果相同:

NB1:/ $ curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

NB1:/ $ curl https://google.com
curl: (28) Operation timed out after 300191 milliseconds with 0 out of 0 bytes received

如果我尝试通过 SSH 连接到托管 VPN 的服务器(这里我没有使用密钥),则会出现以下情况:

 ssh -v [email protected]
OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /jkl/ssh_config
debug1: /abc/ssh_config line 19: Applying options for *
debug1: Connecting to 1.2.3.4 [1.2.3.4 port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 1.2.3.4:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent

然后什么都没有,没有超时或无法验证的消息等。我可以访问的另一个 SSH 服务器连接正常。

VPN 服务器使用 Cloudflare 1.1.1.1 DNS 服务器。运行该命令dig +nocmd +multiline +noall +answer TXT resolver.dnscrypt.info会返回实际的解析器,看来它在 VPN 上使用正确的 DNS 配置:

尝试 1:

resolver.dnscrypt.info. 10 IN TXT "Resolver IP: 162.158.85.239"

尝试2:

resolver.dnscrypt.info. 10 IN TXT "Resolver IP: 162.158.82.32"

显然这不是 DNS 错误,因为地址已解析,并且 VPN 正在通过多个端口(至少 22、25、80、443)正确连接并接收数据。 什么可能阻碍这里的某些交流? 这几乎就像是某种 DPI 正在发生,而且似乎与安全通信有关 - 某些 HTTPS 连接和上述 SSH。这不是连接问题 - 我每秒都在后台运行一个脚本 ping,当它失败时,我显然停止尝试诊断问题。

我能找到的唯一相关问题是Cisco ASA:部分通过 VPN 的流量被阻止785363 此处有关 Cisco ASA 设备但这不是导致问题的原因,因为它们只出现在我连接的网络上。我假设这与使用的 OpenDNS 设置有关,但无法弄清楚它是如何工作的。

在相关服务器的日志中没有发现任何直接的信息。

作为参考,当未连接到 VPN(并允许不安全的证书)时,我在 Chrome 中尝试访问 stackoverflow.com 时会看到此信息:

This site is blocked due to content filtering.
stackoverflow.com
Sorry, stackoverflow.com has been blocked by your network administrator.

You can still get FREE movies, TV shows and magazines through our TPE App or at tv.tpexpress.co.uk.

This site was blocked due to the following categories: Forums/Message boards

 Diagnostic Info
ACType
0
Block Type
aup
Bundle ID
640224
Domain Tagging
-
Host
block.opendns.com
IP Address
176.12.107.132
Org ID
2218188
Origin ID
72833478
Prefs
-
Query
url=8485666876808770837177808815688078&ablock&server=lon15&prefs=&tagging=&nref
Server
lon15
Time
2019-09-02 08:48:01.341364541 +0000 UTC m=+5779291.314972467

答案1

我最近有机会再次测试有问题的网络。

解决方案与 MTU 有关。对有效载荷的进一步分析curl -v表明,客户端问候之后握手失败,并且没有看到任何响应,即使 VPN 服务器看到了这一点,这让我怀疑路由存在问题。

进一步查看,客户端的 MTU 为 1500,这通常可以正常工作,但在此网络配置中失败了。修复方法是降低 MTU,并且可能可以通过更改 MTU 和 MSS 设置来在服务器端更可靠地实施iptables

不同长度的不同域名返回不同大小的有效负载,但不会引起问题,因此存在不一致。

相关内容