Исходящий ESP без ответа не означает, что VPN мёртв
ESP защищает одно направление на ассоциацию и ничего не подтверждает. Сверьте внутренний разговор и входящую SA, прежде чем называть сервер неотвечающим.
Вы захватили трафик на хосте IPsec, увидели уходящие пакеты ESP, не увидели ничего в ответ и заключили, что дальняя сторона сломана. Захват этого вывода не подтверждает. ESP защищает одно направление разговора и ничего не подтверждает на уровне IP, поэтому отсутствие обратного ESP может с равным успехом означать, что приложению нечего было сказать, и что туннель мёртв. Прочитайте внутренний обмен и состояние принимающей стороны, прежде чем винить любой из концов.
Миф: каждый защищённый пакет получает ответ
ESP — не протокол запрос-ответ. Он шифрует и аутентифицирует то, что выбрала политика, а получатель проверяет, расшифровывает и доставляет этот внутренний пакет, не порождая собственного пакета. UDP-запрос, который адресат игнорирует, или эхо ICMP, которое отбрасывает входящая политика, дают тишину в обе стороны как правильный исход. Трактовка этой тишины как сбоя транспорта отправляет вас искать неисправность сети, которой никогда не было.
Односторонний захват на деле доказывает лишь то, что стек отправителя что-то зашифровал в этой точке наблюдения. Ничего о прибытии и ничего о намерении ответить. Полезный вопрос не „почему нет ответа“, а „что должен был произвести внутренний разговор“.
Две SA, два SPI, один разговор
Ассоциации безопасности IPsec однонаправлены, поэтому обычный защищённый обмен ведёт входящую ассоциацию и исходящую ассоциацию с отдельными идентификаторами и независимым состоянием. Поиск обратного трафика по SPI исходящего пакета поэтому является категориальной ошибкой, поскольку любой ответ идёт под собственной исходящей SA партнёра со своим SPI. Сопоставляйте пару по селекторам трафика и адресам партнёра.
Переустановка ключа на несколько секунд усложняет картину, поскольку старое и заменяющее состояние могут перекрываться. Если симптом начался около переустановки ключа, собирайте идентификаторы ассоциаций и отметки времени вместе, а не только имя соединения.
Что должен сделать получатель, прежде чем что-либо ответит
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Каждая строка отказывает независимо, и у каждого сбоя свой владелец, поэтому один захват не может их различить. Входящий счётчик — единственное прямое доказательство прибытия, поскольку пакет, не прошедший аутентификацию или проверку повторов, отбрасывается без какого-либо ответа. Партнёр, у которого входящий счётчик не сдвинулся, вообще не сообщает вам ничего о своей политике.
Доставка — отдельный шаг от расшифровки. Состояние может быть действительным, а пакет всё равно отброшен позже входящей политикой или маршрутом, который не включает внутренний адресат, поэтому проверьте, видел ли целевой хост открытый текст, вместо того чтобы считать, что чистый счётчик означает, будто пакет ушёл куда нужно.
Нативный ESP — не UDP
Нативный ESP — это протокол IP 50, который не является ни TCP, ни UDP и вообще не имеет портов. Поэтому правило брандмауэра, разрешающее IKE по UDP 500, ничего не говорит о пути данных, а фильтр, написанный вокруг портов, может дать туннелю договориться, а затем отбросить всё, что внутри него переносится. Проверяйте путь данных отдельно, в том режиме, который вы действительно наблюдали.
За NAT форма меняется: защищённая нагрузка идёт внутри UDP, обычно на порту 4500, как определяет RFC 3948. Зафиксируйте активный режим до написания любого правила, поскольку устройство на пути может обрабатывать нативный ESP и ESP в инкапсуляции UDP совершенно по-разному, а некоторые промежуточные устройства пропускают одно, отбрасывая другое.
Читайте счётчики, относящиеся к этому инциденту
На хосте strongSwan swanctl --list-sas сообщает счётчики пакетов и байтов по каждой ассоциации в обоих направлениях, чего достаточно, чтобы отделить „так и не пришло“ от „пришло и осталось без ответа“. В Linux /proc/net/xfrm_stat считает суммарные отказы, такие как отсутствующее состояние, отсутствующая политика и ошибки протокола. Эти итоги накапливаются с загрузки и относятся к одному сетевому пространству имён, поэтому большое число — не атрибуция.
Снимите два показания вокруг окна инцидента в правильном пространстве имён и сравните разницы, иначе вы повесите ошибки прошлой недели на сегодняшний тикет. Укажите в тикете пространство имён и обе отметки времени, чтобы следующий читатель мог воспроизвести сравнение, а не полагаться на итог.
Называйте этап, а не подозреваемого
Полезный вывод говорит, где остановился пакет: так и не получен, получен и отброшен, доставлен, но без ответа, или отвечен и потерян на обратном пути. Каждый из них указывает на другого владельца и другую следующую команду. „Нет ответа от VPN-сервера“ сводит четыре разные неисправности в одно предложение, которого захват никогда не оправдывал.
Держите захваты узкими, а сырое состояние ядра не включайте в тикеты, поскольку оно может нести ключевой материал, которому не следует покидать хост. Разницы счётчиков и отметки времени — это те части, которые стоит передать следующему человеку.