Режим trap у strongSwan: чому тунель IPsec чекає трафіку

Неактивний IPsec-тунель за вимогою не показує CHILD SA, доки пакет не збіжиться з його політикою trap. Прочитайте стан, перевірте тригер і знайте, коли пасує start.

У виводі стану не з'являється CHILD SA, тунель виглядає мертвим, і тут ping до віддаленої підмережі піднімає його. У налаштуванні IPsec за вимогою ця послідовність і є задумом, а не несправністю. Політика trap встановлює селектор і чекає, і саме перший відповідний пакет запускає IKE і узгодження CHILD SA.

Частина плутанини у словнику: «up» вживається для двох різних станів. Конфігурацію завантажено, і політика ядра існує, а асоціація даних — ні. Монітор, що рахує лише активні SA, показуватиме здоровий сайт як недоступний, доки ніхто не надсилає туди трафік.

У простоюючого тунелю за вимогою немає CHILD SA для показу

Запис trap сам по собі нічого не автентифікує. Він просить ядро тримати політику для вибраного трафіку і піднімати acquisition, коли пакету потрібна ця політика. Демон отримує acquisition, зіставляє його з визначенням child і веде переговори звідти. До цього моменту показувати немає і IKE SA, тому обидва списки можуть бути порожні одночасно.

Саме цей порядок робить журнали читабельними. Спершу приходить acquisition, потім IKE_SA_INIT і IKE_AUTH, потім CHILD SA. Якщо журнал закінчується одразу після acquisition, тригер спрацював. Узгодження не вдалося, і наступне питання — про облікові дані, пропозиції або доступність, а не про trap.

З бекендом ядра Linux ви можете побачити політику до появи будь-якого SA. Виконайте ip xfrm policy і знайдіть селектор із напрямком out і шаблоном, що вказує на з'єднання. Цей запис і є станом за вимогою, і його наявність — перше, що треба підтвердити.

start_action вирішує, чи взагалі щось чекатиме

Кожен child у swanctl.conf несе start_action. start запускається під час завантаження конфігурації, trap встановлює політику і чекає, а none залишає запуск чомусь іншому. Лише trap створює описану вище поведінку «ping — і він піднімається».

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

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

Довідник swanctl.conf перелічує прийнятні значення разом з окремими діями close і DPD, які визначають, що відбувається після появи SA.

З'ясуйте, чи тригер спрацював узагалі

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

Дві звичайні причини тихого trap: пакет пройшов source-NAT до потрапляння в політику і більше не відповідає local_ts, або з'єднання взагалі не завантажилося через синтаксичну помилку чи помилку облікових даних. Запустіть знову swanctl --load-all і прочитайте вивід, перш ніж чіпати селектори. З'єднання, яке не завантажилося, не встановлює політику, тож трафіку нема чого запускати.

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

Очікування першого пакета не завжди правильний обмін

Інтерактивні сеанси відчувають вартість налаштування. Перший запит платить за обмін IKE і узгодження CHILD, і клієнт із коротким терміном може здатися до появи SA. Проактивний start прибирає цю затримку першого пакета. Але тримає тунель піднятим для трафіку, який може ніколи не прийти.

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

Встановлена політика теж не гарантія від витоків. Якщо вимога fail-closed, міжмережевий екран має відкидати трафік без SA, і це правило живе поза визначенням child.

Запишіть три рядки, які завершать наступну суперечку

Запишіть селектори, дію під час запуску і вивід команди, що показує політику без SA. Ці три рядки відділяють «за вимогою і простоює» від «не завантажується» наступного разу, коли хтось повідомить, що тунель не працює. Їх фіксація займає хвилину. Без них те саме розслідування починається з нуля.

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

Схожі статті