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

Що це за пристрій і чим він не є

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

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

Ще одна межа: ідентифікатор інтерфейсу — це не ім'я. Два пристрої зі схожими іменами та різними ідентифікаторами не поділяють стан, а з'єднання, налаштоване з неправильним ідентифікатором, встановлює стан, який не використає жоден маршрут.

Побудуйте один у правильному порядку

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

Підніміть пристрій, потім підтвердьте ідентифікатор, який записало ядро, перш ніж торкатися конфігурації VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

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

Тримайте IKE і ESP поза маршрутом тунелю

Маршрут за замовчуванням, спрямований у пристрій XFRM, перехоплює інкапсульовані пакети й трафік, який вони несуть. Результат — петля: шлюз намагається надіслати свій ESP через тунель, який ESP має побудувати.

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

Хоч би що ви обрали, перевірте, що зовнішній пакет виходить неінкапсульованим. Швидка перевірка — пінг зовнішньої адреси партнера після підняття тунелю; якщо це не вдається, поки інтерфейс піднято, підозрюйте перехоплення, а не доступність. Те саме міркування стосується порту IKE, бо власний UDP-трафік демона не має маршрутизуватися в пристрій, який він намагається встановити.

Перевірте лічильники у двох місцях, перш ніж звинувачувати шифрування

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

Прочитайте обидва, потім прочитайте погляд демона на дочірню асоціацію:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

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

Вирішіть, хто встановлює маршрути

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

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

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

Схожі статті