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

Два задіяні призначення не взаємозамінні. Маршрутизація має сказати це явно.

Куди насправді потрапляє пошук партнера

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

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

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

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

Варіанти виключення на сучасному шлюзі

Документація strongSwan про VPN на основі маршрутизації наводить дві практичні відповіді. Одна позначає IKE і ESP, щоб правило на таблицю XFRM на них не поширювалося. Інша залишає маршрут до партнера або виключення, до якого пошук ще може дістатися.

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

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

Мітка — це один біт у fwmark пакета, на який більше ніщо на шлюзі не претендує: 0x1 з маскою 0x1 — звичний вибір, і її треба задати у двох місцях, щоб виключення працювало. Charon потребує її на сокеті IKE, а налаштуванням вхідної та вихідної мітки дочірнього з'єднання потрібне те саме значення, щоб інкапсульовані пакети теж виходили позначеними. Маска 0x1 замість 0xffffffff залишає решту бітів вільними, що важливо, коли інша підсистема вже позначає пакети на тому самому хості. Коли задано обидва, правило записується як виключення, тож позначені пакети пропускають таблицю з маршрутом XFRM і потрапляють до основної таблиці:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

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

Що автоматичне встановлення припускає про збірку

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

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

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

Стежте за першим оновленням

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

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

Тимчасове видалення захищеного маршруту за замовчуванням зазвичай відновлює зв'язність. Цей результат діагностичний, а не остаточний.

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

Схожі статті