VPN подключается дома, но в Wi-Fi отеля время ожидания истекает

Ноутбук подключается к домашнему Wi-Fi, клиент соединяется за три секунды, а тот же профиль через час не работает в отеле. Между этим ничего не обновлялось. Разбираться в этом с клиентом перед собой — прежде всего понимать, какая ошибка относится к какому этапу, потому что полезная информация в коде, который печатает клиент, а не в самом факте сбоя. Пройдите четыре шага ниже по порядку, и вы узнаете, кто вас отклонил: имя, пакет, порт или политика.

Читайте код ошибки как этап, а не как приговор

Клиент проходит три отдельных этапа, прежде чем появляется туннель. Он разрешает имя сервера, получает ответ от чего-то в сети и согласовывает ассоциацию безопасности. У каждого этапа своё сообщение об ошибке, и особенно Windows щедр на разные коды, когда вы знаете, к какому этапу они относятся.

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

Будьте соразмерно осторожны, если клиент не Windows. Клиенты третьих сторон большую часть этого сводят к "соединение не удалось", поэтому следующие два шага вообще не полагаются на сообщение.

Проверьте имя, прежде чем винить туннель

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

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Если два ответа различаются, вас направляют, и остальная диагностика бесполезна, пока это не решится. Именно адрес портала охотно примет TCP-соединение, а затем зависнет, поэтому при проверке браузером это может выглядеть как блокировка межсетевого экрана.

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

Выясните, какой внешний пакет исчезает

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

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

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

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

Смените один транспорт и проверьте снова

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

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

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

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

Проверьте тот же профиль во второй сети

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

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

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

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