OpenVPN не подключается в Wi-Fi отеля? Попробуйте TCP 443

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

Сначала проверьте с точки доступа телефона. Если туннель там поднимается, сервер, сертификат и учётная запись в порядке, и единственная оставшаяся переменная — сеть перед вами.

Начните с клиента: прочитайте строку состояния

Строка состояния говорит, на каком этапе произошёл сбой. Клиент, застрявший на «Подключение», всё ещё разрешает имя узла или открывает внешний сокет; тот, что доходит до «Ожидание сервера», имеет путь, но не имеет ответа; тот, что проходит аутентификацию и затем отваливается, имеет совсем другую проблему. Журнал клиента и собственные поля remote и proto профиля показывают, что клиент пытается сделать, а --verb 4 в клиенте командной строки печатает те же подробности. Именно сравнение этого с сетью перед вами превращает «VPN заблокирован» в конкретное утверждение.

Затем проверьте сеть инструментами, которые уже есть. nc -vzu 203.0.113.10 1194 отправляет UDP-дейтаграмму, curl -v telnet://203.0.113.10:443 сообщает, завершается ли рукопожатие TCP, а браузер, загружающий HTTPS-страницу, доказывает лишь то, что исходящий 443 достигает этого одного узла. Небольшие проверки отвечают на то, чего не может клиент VPN: какой порт и какой протокол вообще покидают эту сеть.

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

Переносите слушатель и профиль вместе

На стороне сервера задайте слушатель так, как позволяет сеть: port 443 и proto tcp в конфигурации сервера, затем перезапустите службу и подтвердите сокет с помощью ss -lntp. На стороне клиента профиль должен согласиться, потому что транспорт и порт находятся вне туннеля: proto tcp и port 443 в .ovpn или соответствующие поля на экране настроек приложения. Профиль, по-прежнему нацеленный на UDP 1194, отказывает точно так же, как раньше, и появляется соблазн обвинить уже исправленный межсетевой экран. Если тот же узел отвечает и по HTTPS на 443, два слушателя не могут делить этот адрес и протокол; дайте VPN второй адрес или поставьте впереди демультиплексор.

Проследите первое соединение с помощью tcpdump -ni any port 443 на обоих концах. Пакеты, которые уходят от клиента и никогда не приходят, означают, что сеть всё-таки фильтрует, или что адрес в профиле не тот, который вы предполагаете. Пакеты, приходящие без ответа, возвращают вас к журналу сервера, где несовпадение протокола сразу проявляется как отброшенный пакет.

Когда из сети выходит только прокси

Некоторые гостевые сети не разрешают ничего, кроме HTTP-прокси, — это ограничение иное, чем закрытый порт, и исключает больше, чем OpenVPN. Клиенты, говорящие только PPTP, L2TP/IPsec или чистым IPsec, не имеют пути через него, поскольку такие решения рассчитывают, что их внешний протокол дойдёт до сервера напрямую. OpenVPN может, с http-proxy proxy.example.net 8080 в профиле клиента, при условии, что прокси разрешает метод CONNECT на ваш порт. Прокси SOCKS ещё проще, потому что пересылает поток, не заботясь о том, что внутри.

Там, где клиент не поддерживает прокси, обычно остаётся SSH-туннель поверх 443. Он добавляет второй слой, и оператор сети может иметь своё мнение на этот счёт, поэтому относитесь к нему как к мосту для одной поездки, а не как к архитектуре.

Оцените цену запасного пути, прежде чем его оставлять

TCP внутри TCP имеет известную цену. Когда внешнее соединение — TCP и полезная нагрузка тоже TCP, потерянный сегмент вызывает повторную передачу на обоих уровнях, а внутреннее соединение отступает перед потерей, которую не может увидеть. Просмотр это выдерживает; интерактивные сеансы и звонки это чувствуют. Оставьте слушатель TCP 443 как запасной путь для сетей, которые его требуют, а UDP оставьте по умолчанию для всего, что ещё пропускает его.

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