VPN заблокирован в сети только для веба? Разберите уровни

Сеть кампуса или отеля, где браузер работает, а каждый туннель умирает, — это не одна проблема, а четыре уровня. Путь может разрешать только TCP 443, требовать аутентифицированный прокси, инспектировать рукопожатие или просто запрещать удалённый доступ политикой. Последовательная работа с ними избавляет от покупки нового клиента ради исправления сетевого правила. Инструкция ниже занимает около десяти минут и заканчивается письменным ответом о том, какой уровень вас отклонил.

Докажите, какой уровень отклоняет соединение

Не начинайте с VPN-клиента. Начните с обычного HTTPS-запроса к тому же узлу и прочитайте фазы времени, потому что фаза, которая падает, подсказывает, какое устройство отвечает:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Нет ответа и нет времени connect — значит, TCP так и не завершился, поэтому в игре межсетевой экран, требование прокси или неверный адрес назначения. Время connect без времени tls — значит, что-то посередине приняло соединение и затем задержало рукопожатие, именно так выглядит инспектирующий прокси со стороны клиента.

Теперь посмотрите на сертификат, который вы действительно получаете. Это самый быстрый способ узнать, говорите ли вы с сервером или с промежуточным ящиком, переподписавшим сеанс:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Прочитайте строку издателя. Свой CA означает, что вы дошли до сервиса; корпоративный издатель или издатель устройства означает, что фильтр завершил соединение и решает, что будет дальше. Запишите оба вывода с отметкой времени, потому что тот же тест через час в гостевой сети может дать другой ответ.

Клиент, знающий о прокси, меняет первый пакет, а не политику

Если сеть требует CONNECT через аутентифицированный прокси, об этом нужно сообщить VPN-клиенту, иначе он попытается открыть сокет на адрес, который не может маршрутизировать. Проверяйте прокси отдельно от клиента, чтобы у сбоя было одно объяснение:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Первая команда доказывает, что прокси понесёт пункт назначения. Вторая просит клиент использовать TCP на 443 — единственный транспорт, который большинство путей только для веба вообще пропускают. Если первая удалась, а вторая всё ещё падает, прокси не помеха.

Некоторые клиенты читают прокси операционной системы вместо переопределения, а некоторые не читают ни одного. Проверьте документацию приложения, прежде чем считать, что системная настройка применима. Клиент, который разрешает конечную точку через резолвер, который прокси не обслуживает, тоже потерпит неудачу, и поэтому смена DNS может выглядеть исправлением, когда это лишь обход.

Обратите внимание и на схему управления. Фильтрующая сеть может ответить на имя узла обнаружения поставщика чем-то своим, что меняет профиль прокси, который выбирает клиент. Не стройте процесс вокруг этой странности. Она зависит от площадки, меняется без предупреждения, и это не то, что вы можете поддерживать для кого-то другого.

Порт 443 доступен, но не разрешён

Упаковка туннеля в TLS на 443 решает доступность и ничего больше. Фильтр, который проверяет порт, пропустит его; фильтр, который снимает отпечаток рукопожатия, — нет, а шифрованное приветствие клиента скрывает имя сервера только когда обе стороны это поддерживают. Запустите тест и выясните, за каким фильтром вы находитесь, вместо того чтобы надеяться.

Есть и цена производительности, которую люди обнаруживают позже. Надёжный транспорт внутри надёжного транспорта усиливает потери, потому что внутренний стек повторно отправляет сегменты, которые внешний уже повторно отправил. На чистом канале этого никто не замечает. В перегруженной кампусной беспроводной сети туннель становится непригодным ровно тогда, когда он нужен, и график выглядит как потеря пакетов, хотя ничего не отбрасывается намеренно.

UDP обычно первая жертва, и это стоит подтвердить, а не предполагать. Если WireGuard или стандартный OpenVPN никогда не завершает рукопожатие, пока TCP 443 работает, сеть отбрасывает UDP, и никакая регенерация ключей этого не изменит:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Пустая отметка времени рукопожатия рядом с пиром, который вчера работал, — это ответ по UDP. Два запроса DNS отвечают на другой вопрос: если локальный резолвер и публичный резолвер расходятся в адресе конечной точки, вас перенаправляют, и аргумент о транспорте неверен.

Проверьте, что на самом деле покинуло машину

Журналы клиента описывают, во что клиент верит. Захват описывает, что видела сеть, и разница между ними — то место, где решается большинство таких случаев:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Если видны пакеты SYN и нет SYN-ACK, блокировка выше по потоку, и клиент невиновен. Если виден завершённый рукопожатием контакт с адресом, который не принадлежит серверу, вы говорите с прокси или перехватчиком. Если не видно ничего, проверьте, что захват шёл на правильном интерфейсе, прежде чем что-то заключать.

Список сокетов ловит более тонкий случай: второй туннель уже держит маршрут по умолчанию. Два клиента, борющиеся за таблицу маршрутизации, дают периодические сбои, которые выглядят точно как заблокированная сеть, а захват покажет трафик, уходящий через интерфейс, которого вы не ждали.

Откат и заметка, которую стоит сохранить

Отмените изменения в обратном порядке к тому, в котором вы их вносили. Снимите переменные прокси, остановите клиент, запущенный вручную, и уберите любое переопределение маршрута или резолвера, которое вы добавили:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Оставить запущенный вручную клиент — это способ, которым ноутбук остаётся со сломанной сетью при следующем визите в офис. Переменные прокси, оставленные в профиле оболочки, ломают посторонние инструменты недели спустя, и человек, который их отлаживает, не свяжет два события.

Затем напишите четыре строки: сеть, отметка времени, сбойная фаза и увиденный издатель. Путь, который работает в одном кампусе и не работает в следующем, — это нормально, и следующему человеку нужно знать, была ли разница в прокси, резолвере или фильтре. Если ответ в том, что сеть запрещает удалённый доступ, остановитесь там и попросите администратора о поддерживаемом пути вместо того, чтобы нести обходной путь в политику, которую вы не читали.