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

Четыре этапа, четыре разных сбоя

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

StageLooks likeWhat it does not prove
Name resolutionfails in under a second, before any contactnothing about the server being up
Transportwaits the full timeout, then gives upnothing about the VPN service behind the port
Negotiationconnects, then stalls at handshakenothing about credentials
Logina reply arrives and is rejected or hangs on a promptnothing about reachability

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

Разрешение имени завершается сбоем до любого контакта

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

Старый адрес, скопированный из сообщения на форуме, — частая причина тайм-аута, который выглядит как проблема сервера, потому что адрес теперь принадлежит чему-то другому или ничему. Используйте текущий профиль оператора вместо замены адреса, который раньше работал. Отсутствие ответа на ping ничего не доказывает ни в одну сторону: многие конечные точки отбрасывают ICMP, но при этом отлично обслуживают.

Настройка транспорта ждёт пакет, который не придёт

Когда DNS в порядке, а клиент всё равно сжигает весь тайм-аут, подозреваемый — транспортный уровень. По TCP порт можно проверить напрямую; Test-NetConnection в Windows или nc -vz в Linux скажет, принимает ли что-то соединение, и это полезнее ping. По UDP так проверить нельзя, потому что на этом уровне нет рукопожатия, которое нужно завершить, и эта асимметрия порождает много ошибочных выводов.

То, что доказывает TCP-тест, ограничено: служба, принимающая порт 443, не обязательно является слушателем VPN, а конечная точка только с UDP не имеет TCP-порта, чтобы что-то принять. Переписывание профиля с UDP на TCP не создаёт слушателя на другой стороне; оно только меняет то, чего ждёт ваш клиент. Если сеть фильтрует протокол, изменение даёт другой тайм-аут на том же этапе.

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

Согласование и вход означают, что сервер ответил

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

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

Сравните доказательства, прежде чем менять повтор

Держите устройство и профиль неизменными и меняйте по одному, начиная с сети. Если тот же профиль подключается через точку доступа телефона и истекает по времени в Wi-Fi отеля, переменная — это путь, а не сервер. Если он терпит неудачу везде, переменная — профиль или конечная точка. Если он терпит неудачу только в определённое время суток, зафиксируйте отметку времени и сравните её с событиями на стороне сервера, прежде чем что-либо предполагать о нагрузке.

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

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

Похожие статьи