Чому маршрут OpenVPN програє політиці XFRM strongSwan

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

Два рішення, а не одне

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

Широкий селектор IPsec — звична причина. Політика, що захищає 172.16.0.0/12, охоплює й 172.20.8.0/24, куди адміністратор, можливо, має намір потрапити через тунель OpenVPN. Намір існує лише в таблиці маршрутизації, і база політик ніколи про нього не знала.

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

Прочитайте маршрут, який ядро справді обирає

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

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

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

Прочитайте також політику, яка застосовується

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

ip -s xfrm policy
swanctl --list-sas

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

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

Три варіанти, коли обидва шляхи законні

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

Виняток із проходженням — хірургічний варіант, коли широкий селектор має залишитися. strongSwan підтримує окреме з’єднання, чий child використовує режим pass, що каже ядру: відповідний трафік не повинен оброблятися IPsec. Віддалена адреса loopback утримує це з’єднання від вибору для вхідних партнерів, а селектори мають описувати реальну дозволену пару, а не все.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Приклади конфігурації strongSwan документують цей тип політики й конвенцію loopback-партнера. Третій варіант — це дизайн на основі маршрутизації з інтерфейсами XFRM, який прив’язує політику до трафіку, маршрутизованого через названий інтерфейс, а не до глобального селектора. Це міграція, а не налаштування, і трафік усе одно має відповідати узгодженим селекторам.

Доведіть виняток, не послаблюючи решту

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

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