Як відрізнити фрагментацію IKEv2 від проблеми з ланцюжком сертифікатів

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

Два механізми фрагментації, один симптом

IKEv2 має власне розширення фрагментації, визначене в RFC 7383, яке ділить захищені повідомлення IKE на менші повідомлення IKE. Сторони домовляються про цю можливість, а повідомлення збирається реалізацією IKE, а не рівнем IP.

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

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

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

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

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

Змініть шлях, а не сертифікат

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

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

Виміряйте обмін, перш ніж щось змінювати

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

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Перші два дають кількість сертифікатів і розмір файлу, що є розумним показником того, наскільки великим буде повідомлення автентифікації. Перевірка ping повідомляє, чи виживає дейтаграма такого розміру на шляху, а лічильники інтерфейсу показують, чи були фрагменти відкинуті на вашому боці. У Windows еквівалентна перевірка — це ping з прапорцем do-not-fragment і явним розміром корисного навантаження.

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

Виправте той рівень, який справді зламаний

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

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

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