VPN подключён, но один сервис не работает: изолируйте этап

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

Начните с имени, а не с туннеля

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

resolvectl query host.internal
getent hosts host.internal

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

Спросите ядро, какой путь оно выбрало

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

ip route get 10.20.30.40
ip -brief address show

Читайте поля dev, via и src именно в этом порядке, потому что каждое снимает своё подозрение. Этот этап отвечает и за состояние, установленное клиентом, так как правила файрвола и маршруты могут остаться после аварийного выхода. Поэтому «нет интернета без туннеля» и «нет интернета, пока не запущен клиент» — одна семья неисправностей, а не две.

Проверьте размер пакета

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

ping -M do -s 1400 10.20.30.40

Маленькие зонды проходят, пока листинг каталога или загрузка висят, — это подпись этого этапа. Жалоба звучит как учётные данные или правило файрвола, и это ни то ни другое.

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

Проверьте дальнюю сторону

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

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

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

Соотнесите жалобу с одним этапом

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

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

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