Як читати перший обмін IKEv2 у перехопленні пакетів

Перехоплення, початі в середині сеансу, — звичайна причина, чому слід IKEv2 виглядає як шум: на момент початку запису сторони вже оновлюють ключі або обмінюються зашифрованими навантаженнями. Почніть натомість із нової спроби з'єднання, щоб перше повідомлення у файлі було тим, яке відкриває переговори. Порядок читання нижче це припускає і позначає точку, у якій пакет перестає щось доводити про дальню сторону. Саме пропуск цього кроку призводить до того, що робочий тунель діагностують як заблокований порт.

Переконайтеся, що ви дивитеся на початковий обмін

Переговори IKEv2 починаються з IKE_SA_INIT, тип обміну 34, ідентифікатор повідомлення 0. Ініціатор обирає ненульовий SPI, а SPI відповідача в цьому першому запиті дорівнює нулю і ненульовий у відповіді. Ці три факти відрізняють нову спробу від оновлення ключів або від повідомлення IKE_AUTH, яке випадково опинилося на початку перехоплення.

Поля заголовка читабельні, як і навантаження пропозиції, обміну ключами та nonce. Читабельність не означає автентифікацію: жодна сторона не довела особу на цьому етапі, а закрите значення Diffie-Hellman ніколи не з'являється на лінії.

Друкуйте поля таблицею, а не прокручуйте панель декодування, бо повторні передачі та незбіжні SPI стають очевидними в стовпцях.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Читайте вивід парами. Запит з ідентифікатором повідомлення 0, за яким іде відповідь з тим самим ідентифікатором і ненульовим SPI відповідача, — це один обмін, навіть якщо він з'являється тричі, бо запит було передано повторно. Три однакові запити — не три входи, і саме таке ставлення приводить до висновку, що клієнт крутиться в циклі, тоді як він просто терплячий. Відсортуйте за ідентифікатором повідомлення, потім за міткою часу, і вся розмова згортається в короткий список спроб.

Прочитайте відмову раніше, ніж успіх

Відповідь не є автоматично просуванням. Відповідач може відповісти повідомленням cookie і чекати, що ініціатор спробує ще раз, або INVALID_KE_PAYLOAD, назвавши групу, яку він радше прийняв би. Обидва приходять як коректно сформовані повідомлення IKE, і обидва виглядають як завершений обмін для фільтра, що лише рахує пакети.

Відкрийте навантаження повідомлення і прочитайте тип перед усім іншим. Виклик cookie означає, що відповідач захищається від підроблених адрес джерела, і клієнт має надіслати запит повторно з доданим cookie. Неприпустима група означає, що дві пропозиції не збігаються, і жодна кількість повторів цього не змінить, доки не зміниться конфігурація однієї зі сторін.

Лише IKE_AUTH, другий обмін, несе зашифровану особу та навантаження автентифікації. Тому завершений IKE_SA_INIT каже, що сторони згодні щодо алгоритмів і похідних ключів, і зовсім нічого про те, чи будуть прийняті облікові дані. Очікуйте там також двох повідомлень і очікуйте, що обидва будуть непрозорими без ключів сеансу.

Порт 4500 — не один протокол

UDP 500 зазвичай несе початковий обмін. Після виконання виявлення NAT IKE переходить на 4500 і ставить перед кожним повідомленням чотирибайтовий нульовий маркер, що не є ESP. Інкапсульований ESP на тому самому порту починається, навпаки, з ненульового SPI ESP, а однобайтовий NAT keepalive — третя форма, що з'являється, коли більше нічого не відбувається.

Фільтр, що збігається лише за портом, змішує всі три, і тому "на 4500 є трафік" вирішує так мало. Розділіть подання за протоколом, перш ніж робити висновки про дальню сторону.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Тиша описує точку спостереження

Запити без відповідей встановлюють рівно одне: у цій точці перехоплення відповідь не з'явилася. Фільтрація, маршрут, що надсилає відповідь в інше місце, недосяжний відповідач або відповідач, якому не подобається пропозиція, дають той самий порожній результат, і загальна перевірка UDP їх не розділить.

ICMP-недосяжність — доказ іншого роду. Прочитайте цитований пакет усередині нього і визначте, який пристрій його випустив, бо адміністративна відмова маршрутизатора не є автентифікованою помилкою від дальньої сторони.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Зіставте ту саму спробу з журналами на боці сервера там, де вам дозволено їх читати. Чи надійшов запит, чи відповіла служба і де відповідь зупинилася? Ці три відповіді направлять вас до проблеми шляху або до проблеми політики, і вони коштують менше, ніж четверта зміна облікових даних.