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

Три разные вещи, которые называют «подключено»

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

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

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

Какой счётчик доказывает, что пакеты пошли

В IPsec ассоциация IKE и ассоциация CHILD — отдельные объекты, и только child несёт счётчики, отвечающие на этот вопрос. Выведите child, наблюдайте, растут ли пакеты в обе стороны, и сравните это с тем, что пытается делать приложение. Установленная ассоциация на нуле — это другой вывод, чем растущая, пока приложение всё ещё терпит неудачу; первое означает, что трафик не выбирается, второе — что он идёт, а отказ дальше. Прочитайте счётчики дважды с интервалом в несколько секунд, потому что один замер не покажет тенденцию.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Нулевые счётчики указывают на выбор: маршрутизацию, политику, пространство имён, откуда вышел пакет, или интерфейс, к которому клиент так и не привязался. Растущие счётчики указывают прочь от туннеля, поэтому продолжайте с пересылкой на дальнем конце, разрешением имён, обратным путём и целевым сервисом — именно в этом порядке. Протокол без отдельного объекта child показывает те же доказательства в своих терминах, поэтому используйте то, что он сообщает о состоянии партнёра и числе пакетов, вместо того чтобы заимствовать словарь IPsec. Форма показания важнее инструмента, который его получил.

Где находится отказ после того, как счётчики пошли

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

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

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

Запишите триггер, затем измените одну вещь

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

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

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

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