VPN постоянно отключается: проверьте радио до сервера

Отключение VPN может начаться задолго до того, как хоть какой-то трафик дойдёт до сервера. Потеря Wi-Fi, переход с Wi-Fi на сотовую сеть, перегрузка локальной точки доступа и засыпающий телефон могут прервать внешний путь, пока программное обеспечение туннеля сообщает о чистой ошибке. Идите от устройства наружу: сначала канал, затем события самого клиента, затем контролируемое сравнение и только потом сервер. Такой порядок удерживает от смены выходных узлов ради проблемы, которая живёт в комнате.

Следите за каналом, а не за значком сигнала

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

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

Читайте собственные события переподключения клиента

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

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

Сравнивайте вторую конечную точку осторожно

Вторая конечная точка — полезное сравнение, и сама по себе она не является контролируемым экспериментом. Она меняет маршрут, инфраструктуру и часто страну, поэтому разница между двумя конечными точками не доказывает, что первый сервер неисправен.

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

Соотносите с сервером, который вы администрируете

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

Один ответ партнёра не подтверждает непрерывное здоровье приложения. После восстановления проверьте ресурс, который действительно нужен, потому что успешное рукопожатие и доступный сервер могут существовать вместе со сломанным путём приложения.

Напишите отчёт, который сужает круг

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

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

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