IPsec усередині IPsec: які адреси має нести зовнішній тунель

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

Вкладений IPsec легше осмислити, коли два рівні закінчуються на різних машинах. Чотири шлюзи, два тунелі й одне питання, яке вирішує, чи працює схема: що зовнішній тунель насправді бачить, коли внутрішній завершив роботу з пакетом? Дайте на нього відповідь, і селектори, маршрути та порядок пошуку несправностей підтягнуться самі. Помилитеся — витратите день на налагодження тунелю, який технічно піднято.

Модель чотирьох шлюзів

Зовнішні шлюзи A і B будують перший тунель між двома майданчиками. За A стоїть внутрішній шлюз C з транзитною адресою 10.60.0.2; за B стоїть внутрішній шлюз D з транзитною адресою 10.70.0.2. Мережі застосунків живуть за C і D, і всі адреси в прикладі навмисно не перетинаються.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

Кожен рівень знімає лише свій захист

C шифрує пакет застосунку для D. Результат адресовано від C до D, і саме він досягає A. Усе далі залежить від цього переписування.

A шифрує його знову для B. B розшифровує зовнішній рівень, бачить пакет від C до D і пересилає його все ще зашифрованим. D знімає внутрішній захист і доставляє пакет застосунку.

Отже, A і B бачать внутрішні кінцеві точки та їхні метадані, але не є сторонами, які розшифровують корисне навантаження застосунку. Це реальна властивість схеми, а не твердження, що C, D або хости застосунків заслуговують довіри.

Зовнішні селектори називають внутрішні шлюзи

Тут більшість таких побудов і зазнає невдачі. Для зовнішнього тунелю на основі політик селектори, які ви узгоджуєте, мають містити адреси, якими A і B справді оперують: 10.60.0.2/32 і 10.70.0.2/32, у правильному локальному та віддаленому порядку.

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

Не звужуйте зовнішній дозвіл до UDP 500. Внутрішнє з'єднання має власний шлях даних, який використовує ESP або інкапсуляцію UDP залежно від того, що узгоджено, і зовнішня політика має дозволяти цей протокол.

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

Пересилання та пастка рекурсії

Селектори не замінюють маршрутизацію. A і B мають пересилати трафік між C і D в обох напрямках, що означає ввімкнене пересилання IP, маршрути, що вказують на тунель, і зворотний шлях, який існує на іншому боці.

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

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

Перегляньте трансляцію перед додаванням рівнів

Подивіться на будь-який source NAT на A і B, перш ніж щось інше налаштовувати. Правило, яке переписує адресу C до застосування політики IPsec, може зламати узгоджені селектори, а також змінити те, що D отримує на іншому боці.

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

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

Доведіть fail-closed і перевірте MTU

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

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

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

Схожі статті