IPsec ESP: що він переносить і як довести, що трафік іде
ESP у тунельному режимі інкапсулює внутрішній IP-пакет і визначає свою асоціацію за SPI. Прочитайте стан, потім подивіться, як один потік рухає лічильники.
ESP переносить трафік у VPN на базі IPsec, і його runbook починається з одного правила: прочитайте асоціацію безпеки, перш ніж змінювати політику. Більшість незрозумілої поведінки ESP зводиться до селектора, який не збігся, режиму, який припустили, а не прочитали, або лічильника, який ніхто не перевірив, поки йшов один потік. Три кроки нижче встановлюють, що що переносить, доводять, що один потік це використовує, і залишають відкат, який не залежить від пам'яті. Кожен крок дає одне спостереження, яке варто записати.
Знайте поля, перш ніж їх читати
ESP ставить заголовок перед захищеними даними і трейлер після них. Заголовок несе індекс параметрів безпеки, який визначає, яку асоціацію має використовувати отримувач, номер послідовності для виявлення повторів і в трейлері заповнення, яке тримає корисне навантаження вирівняним для шифру. Поле наступного заголовка в трейлері каже, що є захищеним вмістом, і саме так отримувач дізнається, що він декапсулював.
Режим змінює те, що міститься всередині цього захисту. У тунельному режимі захищений матеріал — це повний внутрішній IP-пакет, і новий зовнішній заголовок переносить його між кінцевими точками. У транспортному режимі захист охоплює корисне навантаження верхнього рівня наявного пакета, тому другого IP-заголовка для розкриття немає. Який режим використовується — це факт конфігурації, а не питання тлумачення. Читайте його із запису стану, а не виводьте зі схеми.
Жоден із режимів не приховує зовнішньої адресації, яка має доставити пакет. Це властивість задуму, а не вада, і саме тому проміжний спостерігач усе ще бачить, які дві адреси розмовляють, навіть коли корисне навантаження непрозоре.
Крок перший: прочитайте стан, потім політику
Записи стану зберігають ключі та лічильники; записи політики зберігають селектори, які вирішують, кому дозволено ними користуватися. У Linux обидва видно без перехоплення пакетів, і читання їх у цьому порядку залишає два питання окремими.
ip xfrm state
ip xfrm policyУ виводі стану перевірте джерело й призначення асоціації, режим і те, чи показує інкапсуляція порти UDP. Ці порти означають, що використовується проходження через NAT, що змінює те, що має дозволити проміжний міжмережевий екран, але не те, які селектори чи ключі діють на кінцевих точках.
Потім прочитайте селектори в політиці. Селектор, який називає вужчий префікс, ніж тестований трафік, — найпоширеніша причина, чому робочий тунель ніби ігнорує потік, а селектор для неправильного протоколу дає ту саму тишу.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
Інструменти виробників виводять ту саму інформацію в зручнішій формі. ipsec statusall у strongSwan перелічує дочірні асоціації, їхні селектори та лічильники байтів, що часто швидше, ніж читати сирий вивід xfrm, коли ви вже знаєте, на яку дочірню асоціацію дивитися.
Крок другий: доведіть, що один потік рухає лічильники
Лічильники мають сенс лише тоді, коли ви знаєте, що мало їх зрушити, тому виберіть джерело й призначення, які селектор точно покриває, і надішліть один нешкідливий запит. Потім прочитайте той самий запис ще раз і порівняйте.
ip -s xfrm state
tcpdump -ni any espДва читання розповідають різні історії. Пакети, що зростають на вихідному боці, але ніколи на вхідному, вказують на проблему пересилання або зворотного шляху, а не ключа, бо пакет був інкапсульований і пішов. Якщо не рухається жоден лічильник, трафік жодного разу не збігся з політикою, і селектор — те місце, де треба дивитися.
Перехоплення на тому самому кроці підтверджує інкапсуляцію на дроті, зокрема те, чи зовнішні пакети є ESP чи ESP з інкапсуляцією в UDP. Воно також показує адреси, які справді переносили потік, і вони іноді відрізняються від тих, що були в конфігурації, яку ви читали.
Крок третій: змініть одну річ і збережіть відкат
Запишіть джерело, призначення, режим, селектори й лічильники асоціації, перш ніж щось редагувати. Якщо зміна погіршить стан, саме цей запис дозволить відновити попередній стан, а не збирати робочу конфігурацію заново зі здогаду. Запис займає хвилину і економить годину пізніше. Це також єдиний артефакт, який переживає людину, що зробила зміну.
Змініть один селектор або один параметр, перезавантажте його і повторіть другий крок на тому самому потоці. Видалення асоціації руйнує кожен потік, що її використовує, тому точкове редагування й перезавантаження дочірньої асоціації майже завжди кращі за очищення стану, щоб побачити, що станеться.
Відкат редагування селектора — це відновлення попередньої політики та її перезавантаження, із застереженням, що партнеру може знадобитися відповідна зміна, якщо селектор узгоджується, а не є локальним. Запишіть цю залежність, поки вона свіжа, бо наполовину відновлену пару важче осмислити, ніж будь-який із двох кінцевих станів.
Насамкінець, тримайте межі чесними. Робоча асоціація ESP доводить, що два шлюзи захищають і доставляють сегмент, і нічого не каже про те, чи автентифікує застосунок угорі своїх користувачів або чи шифрує те, що зберігає. Це окремі контролі з окремими доказами, і runbook завершений лише тоді, коли наступна людина може повторити його за нотатками.