IPsec із кількома підмережами втрачає зворотний трафік? Порахуйте reqid

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

Розділіть симптом, перш ніж щось змінювати

Однобічний збій із завершеним узгодженням IKE звужує проблему до шляху даних. Або вихідна політика збіглася й відповідь відкинули, або відповідь узагалі не надійшла, бо інша сторона не мала чим її надіслати. Для застосунку обидва випадки виглядають однаково, а бази xfrm їх розрізняють.

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

Прочитайте базу політик і базу станів

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

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

Класична асиметрія: один reqid на кілька підмереж

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

Виправлення — це зміна конфігурації, а не правило міжмережевого екрана: generate_policy unique; дає кожній політиці власний reqid, тож асоціації партнера на кожну політику мають відповідних партнерів. Застосуйте це, узгодьте заново й порахуйте різні reqid для очікуваних підмереж, перш ніж оголосити успіх.

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

Селектори походять із узгодження, а не з вашої конфігурації

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

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

Перевіряйте в цьому порядку й знайте, як відкотитися

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

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