De ce o rută OpenVPN pierde în fața unei politici XFRM strongSwan

Pachetele pot urma o rută OpenVPN și totuși pot fi capturate de o politică IPsec, iar această combinație arată ca o eroare de rutare din orice unghi, în afară de cel corect. Linux rezolvă o rută și apoi consultă o bază de date separată a politicilor de securitate, așa că o rută de destinație mai specifică nu înlătură o politică XFRM potrivită. Simptomul vizibil este traficul care părăsește gazda și nu ajunge niciodată, în timp ce ambele tuneluri se declară sănătoase. Trei opțiuni rezolvă asta, iar care dintre ele este aleasă depinde de care dintre cele două căi ar trebui să ducă acel prefix.

Două decizii, nu una

Selecția rutei răspunde la o întrebare îngustă: care următorul salt și care adresă sursă ar trebui să ducă acest pachet. Baza de date a politicilor de securitate răspunde la alta: are acest pachet nevoie de protecție IPsec și sub ce selectori. Ambele rulează pentru același pachet, și îndeplinirea primei nu spune nimic despre a doua. De aceea schimbarea unei metrici sau adăugarea unei rute statice poate lăsa simptomul neatins.

Un selector IPsec larg este cauza obișnuită. O politică ce protejează 172.16.0.0/12 acoperă și 172.20.8.0/24, unde un administrator poate intenționa să ajungă prin tunelul OpenVPN. Intenția există doar în tabela de rutare, iar baza de date a politicilor nu a aflat niciodată despre ea.

Tratați asta ca un conflict între două căi de protecție configurate, nu ca o competiție între două metrici. Corecția aparține componentei care a fost configurată cu sfera greșită.

Citiți ruta pe care kernelul o alege efectiv

Începeți cu căutarea pe care o face kernelul, inclusiv adresa sursă și orice regulă de politică ce ar putea-o devia către altă tabelă. O rută din tabela principală poate să nu fie consultată niciodată dacă o regulă anterioară alege altă tabelă, iar potrivirea celui mai lung prefix se aplică doar în tabela pe care o alege o regulă.

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

Ultima comandă este cea care contează, pentru că afișează ruta aleasă împreună cu adresa sursă pe care kernelul ar folosi-o. Comparați acea ieșire cu selectorul cu care se potrivește politica IPsec. Când ruta indică interfața OpenVPN, iar politica se potrivește în continuare cu aceeași pereche, ați reprodus conflictul fără să ghiciți.

Țineți dump-urile fără adrese irelevante înainte să ajungă la un tichet. O tabelă de rutare de pe o gazdă de producție poartă topologie internă, și doar liniile care răspund la întrebare merită lipite.

Citiți și politica ce se aplică

Lista politicilor arată direcția, selectorii și șablonul care decide ce se întâmplă cu un pachet potrivit. Citiți mai întâi direcția de ieșire, apoi partea de intrare pentru traficul de retur, pentru că o excepție unidirecțională produce o conexiune care începe și nu se termină niciodată.

ip -s xfrm policy
swanctl --list-sas

Comparați selectorii din listă cu prefixele pe care le-a negociat conexiunea. Dezactivarea instalării rutelor în strongSwan nu elimină acele politici, iar schimbarea unei metrici nu schimbă perechea sursă-destinație pe care o protejează o politică. Aceste două pseudo-corecții merită excluse devreme, pentru că oamenii le încearcă primele.

Dacă lista nu conține nicio politică pentru prefixul așteptat, problema este în altă parte, iar tabela de rutare probabil spune adevărul. Dacă conține o politică mai largă care acoperă prefixul, ați găsit captura.

Trei opțiuni când ambele căi sunt legitime

Restrângerea selectorului IPsec este opțiunea cea mai curată când prefixul larg a fost o comoditate, nu o cerință. Reducerea selectorului de trafic la distanță la subrețelele care aparțin cu adevărat în spatele IPsec elimină conflictul pentru fiecare gazdă deodată, și costă o renegociere de chei, nu o componentă nouă.

O excepție passthrough este opțiunea chirurgicală când selectorul larg trebuie să rămână. strongSwan acceptă o conexiune separată al cărei copil folosește modul pass, ceea ce îi spune kernelului că traficul potrivit nu trebuie procesat de IPsec. Adresa la distanță de loopback împiedică selectarea acelei conexiuni pentru partenerii de intrare, iar selectorii trebuie să descrie perechea autorizată reală, nu totul.

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
            }
        }
    }
}

Exemplele de configurare strongSwan documentează acest tip de politică și convenția de partener loopback. A treia opțiune este un design bazat pe rutare cu interfețe XFRM, care leagă politica de traficul rutat printr-o interfață numită, în loc de un selector global. Este o migrare, nu o ajustare, iar traficul trebuie totuși să îndeplinească selectorii negociați.

Dovediți excepția fără a slăbi restul

După încărcarea modificării, testați excepția și o destinație obișnuită care trebuie să rămână protejată. Verificați ambele sensuri, apoi coborâți tunelul OpenVPN și confirmați ce se întâmplă cu traficul exceptat. O excepție care trimite tăcut acel prefix în clar când tunelul este căzut este o decizie de politică pe care ar trebui să o luați intenționat, nu să o descoperiți în timpul unui incident.

Notați care prefix folosește care cale și de ce. Altfel următorul inginer care vede un selector larg va redeschide aceeași investigație, iar răspunsul va sta într-un mesaj de commit pe care nimeni nu îl citește.