Дубльовані пакети IKE: знайдіть пропущений перехід
Повторений запит IKE — це подія таймера, а не діагноз. Побудуйте один ланцюг доказів від ініціатора до відповіді, з правильними ідентифікаторами версії.
Журнал показує той самий запит IKE двічі, хтось вказує на мобільний аплінк, і тікет закривається здогадкою. Ця здогадка і є міфом: повторений пакет — це спостереження про один обмін, а не діагноз каналу. Повторне надсилання — нормальна поведінка з власними правилами, і воно з'являється на здорових шляхах щоразу, коли відповідь повільна. Простежте відповідь, перш ніж звинувачувати інтерфейс.
Міф: повторений запит доводить втрату на одному каналі
Дві різні речі створюють дубль, і жодна не називає винного. Запитувач може повторити запит, бо не отримав відповіді, або точка захоплення може показати той самий пакет двічі через те, де вона підключена до стеку. Щуп, що бачить вхід і вихід на одному хості, охоче запише один пакет як два, а оператор, який читає цей журнал, не має способу відрізнити їх без ідентифікаторів обміну. Вважайте дубль подією таймера, доки не зможете сказати, який із двох у вас у руках.
Два аплінки погіршують плутанину, а не покращують. Один рядок журналу називає один інтерфейс, тоді як відповідь могла піти через інший, тому інтерфейс у повідомленні описує, де пакет було видно, а не форму розмови. Тому перше питання — який обмін ви дивитеся, а не який канал несправний.
Що насправді каже повторне надсилання
У IKEv2 повторне надсилання працює так: запитувач повторює запит, коли відповідь не надійшла, а відповідач може надіслати свій кешований варіант замість того, щоб обчислювати новий. Ідентифікатори повідомлень належать цьому обміну, і саме це робить повторений запит з тим самим ідентифікатором упізнаваним як робота протоколу, а не як нова спроба. Початкова спроба часто потребує для зіставлення більшого, ніж адреса джерела або SPI ініціатора, тому власний запис обміну платформи кращий за список пакетів. IKEv1 дотримується інших правил з іншими ідентифікаторами, і попередження постачальника про дубль першого пакета не означає того самого в усіх версіях.
Отже, позначка часу повторного надсилання каже, що таймер вичерпано. Вона не каже, який стрибок був повільним, і точно не каже, що винний оператор зв'язку. Це окремі твердження, і в тікеті корисне лише друге.
Практичний наслідок — записати обмін до того, як робити висновок. Запишіть локальну адресу приймання, обраний політикою шлях відповіді, кортеж партнера та ідентифікатори обміну в одному місці, бо кожен із них відповідає на інше питання, коли запис читають пізніше.
Чотири точки спостереження як один ланцюг
Думайте про обмін як про чотири ланки ланцюга, а не як про чотири окремі місця для перегляду. Ланка містить доказ або залишається невідомою, і ланцюг інформативний рівно настільки, наскільки інформативна його найслабша записана ланка. Таблиця нижче — це опис: що може встановити кожна позиція і що залишає недоторканим.
| Позиція | Доказ, який вона може надати | Що залишається відкритим |
|---|---|---|
| Ініціатор надсилає | Запит залишив цей хост | Чи дійшов він до партнера |
| Відповідач приймає | Запит надійшов | Чи створено відповідь |
| Відповідач надсилає | Відповідь залишила шлюз | Чи пішла вона запланованим шляхом |
| Ініціатор приймає | Обмін завершено | Чи політика прийняла результат |
Заповнюйте ланцюг лише там, де маєте доступ, а решту позначайте як невідоме, а не виводьте. Гачок, що записує пакети на одній машині, нічого не каже про те, що отримала віддалена машина, а рядок журналу про те, що запит було помічено, не є доказом, що відповідь колись виходила. Чесні прогалини корисніші за запис, що виглядає повним, але збудований на здогадках.
Знайдіть перший пропущений перехід
Пройдіть ланцюг від ініціатора назовні й зупиніться на першій ланці без доказів. Якщо шлюз ніколи не записує запит, несправність на шляху перед ним. Коли шлюз знову й знову записує той самий запит, а клієнт жодного разу не записує відповідь, підозрілим є зворотний напрямок: адреса джерела, трансляція та фільтрація на кожному кордоні, який ви контролюєте. Якщо відповідь надходить, а клієнт усе одно не просувається, питання залишило транспорт і стало політикою або станом.
Тримайте партнера й протокол незмінними, поки порівнюєте, і пам'ятайте, що затримка, втрати, політика та стан дають кожен свою часову шкалу. Мобільна мережа не є автоматично причиною, а фіксована лінія не є автоматично достатньо надійною для будь-якої вимоги. Захопіть обидва напрямки, поки обмін живий:
tcpdump -ni any -vv 'udp port 500 or udp port 4500'Коли доступ обривається до далекого кінця, запис усе ще допомагає, якщо каже, де він обривається. Захоплення лише на ініціаторі може показати запит, що виходить, і відповідь, що не надходить, що звужує несправність до всього після цього гачка, не вдаючи, що відомо, який стрибок його впустив. Позначте далекі ланки як невідомі й дозвольте наступній людині з доступом заповнити їх. Записане так, воно залишається чесним і водночас коротким.
Порівнюйте, перш ніж щось змінювати. Повторення того самого запиту до того самого партнера з тим самим протоколом залишає змінні обчислюваними, а скидання, оновлення ключа або зміна політики між захопленнями руйнує порівняння. Якщо зміна неминуча, захопіть одразу після неї, щоб до і після все ще описували той самий обмін.
Що каже корисний звіт
Звіт, вартий дії, поєднує один запит із його відповіддю й називає перший крок, за яким немає доказів. Це речення витримує читання за тиждень інженером, якого там не було, і дає наступній людині відправну точку замість підозрюваного.
Ніколи не послаблюйте перевірки автентичності й не розширюйте дозволений набір протоколів лише для перевірки теорії повторного надсилання. Зберігайте оригінальні пакети й записи подій перед будь-яким скиданням, бо скидання знищує саме той матеріал, який ви збиралися зібрати, і стирає хронометраж, що показував, де обмін застряг.
Міф у тому, що один дубль доводить вину оператора зв'язку. Реальність у тому, що один дубль доводить вичерпання таймера, а відповідь живе на шляху відповіді.