Зошто 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 поддржува одделна врска чие 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 порака што никој не ја чита.