Дублирующиеся пакеты IKE: найдите пропущенный переход

Журнал показывает один и тот же запрос IKE дважды, кто-то указывает на мобильный аплинк, и тикет закрывается догадкой. Эта догадка и есть миф: повторный пакет — наблюдение об одном обмене, а не диагноз канала. Повторная передача — нормальное поведение со своими правилами, и оно появляется на здоровых путях всякий раз, когда ответ медленный. Проследите ответ, прежде чем винить интерфейс.

Миф: повторный запрос доказывает потерю на одном канале

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

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

Что на самом деле говорит повторная передача

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

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

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

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

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

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

Найдите первый пропущенный переход

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

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

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

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

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

Что говорит полезный отчёт

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

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

Миф в том, что один дубликат доказывает вину оператора связи. Реальность в том, что один дубликат доказывает истечение таймера, а ответ живёт на пути ответа.