ESP розшифровує нормально, а внутрішній пакет усе одно нікуди не доходить

Лічильник приймання ESP зростає, тунель лишається піднятим, а застосунок так і не бачить пакета. Розшифрування відбулося, перевірка цілісності пройшла, і далі одержувач мав вирішити, чим насправді є захищене корисне навантаження. Саме на цьому останньому кроці й з'являється невідповідність формату, а ззовні це зовсім не схоже на проблему міжмережевого екрана.

Що ви бачите, коли мітка бреше

Ніщо в журналі клієнта не відрізняє це від чорної діри маршрутизації. І те, і те дає тайм-аут застосунку поруч зі здоровим тунелем, тому першими звинувачують лічильники.

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

Тип живе в трейлері

У звичайному режимі тунелю IPsec захищене ESP корисне навантаження містить повний внутрішній IP-пакет. Поле наступного заголовка в трейлері визначає, що це за навантаження, і це не порт TCP, не номер протоколу в зовнішньому заголовку і не частина початкового поля SPI та порядкового номера. RFC 4303 розділ 2.6 визначає його як поле типу навантаження, тобто точна назва для точної роботи.

Значення, які вам трапляться, малі й варті запам'ятовування: IPv4 це 4 (0x04), а IPv6 це 41 (0x29).

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

Як відрізнити це від звичних підозрюваних

Більшість зниклих пакетів це не дефекти кодування. Спершу перевірте селектори, бо селектор трафіку, що виключає префікс IPv6, відкидає трафік ще до того, як щось буде інкапсульовано. Далі перевірте маршрутизацію, а потім локальну фільтрацію на приймальному хості. І лише коли це виключено, невідповідність формату навантаження стає правдоподібним поясненням.

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

Якщо ніхто не може надати цей доказ, у вас немає помилки формату. У вас є теорія, і селектори залишаються вигіднішою ставкою.

Чим ремонт не є

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

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

Перевіряйте потік, а не лічильник

Після виправлення перевірте реальний потік IPv6 від початку до кінця: запит застосунку через тунель, відповідь на нього і пару адрес, яку бачить кожна сторона. Зростаючий лічильник ESP доводить лише те, що пакети приймаються й автентифікуються. Він нічого не каже про те, чи був внутрішній пакет придатним до використання.

Запишіть у тікет обидва результати. Рух лічильника разом із робочим потоком це виправлення; сам лише рух лічильника це рівно те, що було у вас до початку.