Защо маршрут през 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 поддържа отделна връзка, чието дете използва режим 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, което никой не чете.