Зашто OpenVPN рута губи од strongSwan XFRM политике

Пакети могу да прате 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 поруци коју нико не чита.