У меня есть VPN-сервер (strongswan) используется для тестирования, к которому я подключаюсь через IKEv2 в различных системах (здесь я пробовал Windows, Ubuntu и Android), обычно без проблем. Этим утром я был в поезде в Великобритании (Transpennine Express, который использовал Icomera.com) и подключен к бортовому Wi-Fi. Это сеть только для IPv4 и использует OpenDNS для блокировки определенных сайтов. К сожалению, они блокируют обмен стеками, поэтому я подключился к своей 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. Что может мешать определенному общению?
ping и traceroute работал на всех доменах и возвращал действительные IP-адреса (как через v4, так и через v6, через VPN - проблемы все еще возникали, если я отключил 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, подключенная к моему мобильному телефону на случай, если с моим оборудованием возникла какая-то особенность), я попробовал то же самое - у нее нет 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 (я не использую здесь ключ), при подключении к VPN:
ssh -v user@1.2.3.4
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-сервер использует DNS-серверы Cloudflare 1.1.1.1. Запуск команды dig +nocmd +multiline +noall +answer TXT resolver.dnscrypt.info возвращает фактический преобразователь, похоже, что он использует правильную конфигурацию DNS через VPN:
Попытка 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. Это не проблема с подключением - я запускал пинг сценария в фоновом режиме каждую секунду, и когда это не удалось, я, очевидно, перестал пытаться диагностировать проблему.
Единственный соответствующий вопрос, который я могу найти, это Cisco ASA: часть трафика через VPN заблокирована785363 здесь об устройстве Cisco ASA но это не вызывает проблем, поскольку они появляются только в сети, к которой я был подключен. Я предполагаю, что это связано с используемой настройкой OpenDNS, но не могу понять, как это работает.
В журналах рассматриваемого сервера ничего непосредственного не видно.
Для справки, когда я не подключен к VPN (и разрешая небезопасный сертификат), я вижу это при попытке доступа к stackoverflow.com в Chrome:
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
Во время работы над другими проблемами, похоже, что часть решения этого была на самом деле связана с проблемой клиента - `` Умное многосетевое разрешение имен '' в Windows не отключается с помощью редактирования реестра за пределами Windows 8, а вместо этого должно быть отключено групповой политикой без видимых изменений реестра. Диагностика осложнялась сетью, в которой проводились тесты. В настоящее время невозможно протестировать решение в «реальном мире», но я настроен оптимистично и отмечу как решенное, когда оно будет протестировано. Он не объясняет Android или Ubuntu, но у меня есть дополнительные теории, работает ли это решение.