Hvorfor en OpenVPN-rute taber til en strongSwan XFRM-politik

Pakker kan følge en OpenVPN-rute og alligevel blive opfanget af en IPsec-politik, og den kombination ligner en routingfejl fra alle vinkler undtagen den rigtige. Linux opløser en rute og konsulterer derefter en separat sikkerhedspolitikdatabase, så en mere specifik destinationsrute fortrænger ikke en matchende XFRM-politik. Det synlige symptom er trafik, der forlader værten og aldrig ankommer, mens begge tunneller rapporterer sig sunde. Tre muligheder løser det, og hvilken du vælger afhænger af, hvilken af de to veje der skal bære det præfiks.

To beslutninger, ikke én

Rutevalg besvarer et snævert spørgsmål: hvilket næste hop og hvilken kildeadresse skal bære denne pakke. Sikkerhedspolitikdatabasen besvarer et andet: kræver denne pakke IPsec-beskyttelse, og under hvilke selektorer. Begge kører for den samme pakke, og opfyldelse af det første siger intet om det andet. Derfor kan en ændret metrik eller en tilføjet statisk rute lade symptomet være urørt.

En bred IPsec-selektor er den sædvanlige årsag. En politik, der beskytter 172.16.0.0/12, dækker også 172.20.8.0/24, som en administrator måske i stedet vil nå gennem OpenVPN-tunnellen. Hensigten findes kun i routingtabellen, og politikdatabasen har aldrig erfaret den.

Behandl det som en konflikt mellem to konfigurerede beskyttelsesveje frem for en dyst mellem to metrikker. Rettelsen hører til den komponent, der blev konfigureret med det forkerte omfang.

Læs den rute, som kernen faktisk vælger

Begynd med det opslag, kernen udfører, inklusive kildeadressen og enhver politikregel, der kan lede den til en anden tabel. En rute i hovedtabellen bliver måske aldrig konsulteret, hvis en tidligere regel vælger en anden tabel, og længste præfiks-match gælder kun inden for den tabel, en regel vælger.

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

Den sidste kommando er den, der betyder noget, fordi den udskriver den valgte rute sammen med den kildeadresse, kernen ville bruge. Sammenlign det output med den selektor, IPsec-politikken matcher. Når ruten peger på OpenVPN-interfacet, og politikken stadig matcher det samme par, har du genskabt konflikten uden at gætte.

Hold dumps fri for uvedkommende adresser, før de når en ticket. En routingtabel fra en produktionsvært bærer intern topologi, og kun de linjer, der besvarer spørgsmålet, er værd at indsætte.

Læs den politik, der også gælder

Politiklisten viser retning, selektorer og den skabelon, der afgør, hvad der sker med en matchende pakke. Læs den udgående retning først, derefter indgangssiden for returtrafikken, fordi en envejsundtagelse giver en forbindelse, der starter og aldrig fuldføres.

ip -s xfrm policy
swanctl --list-sas

Sammenlign selektorerne i listen med de præfikser, forbindelsen har forhandlet. Deaktivering af strongSwans ruteinstallation fjerner ikke disse politikker, og en ændret metrik ændrer ikke, hvilket kilde- og destinationspar en politik beskytter. De to ikke-rettelser er værd at udelukke tidligt, fordi det er dem, folk prøver først.

Hvis listen ikke indeholder en politik for det præfiks, du forventede, er problemet et andet sted, og routingtabellen fortæller sandsynligvis sandheden. Hvis den indeholder en bredere politik, der dækker præfikset, har du fundet opfangningen.

Tre muligheder når begge veje er legitime

At indsnævre IPsec-selektoren er den reneste mulighed, når det brede præfiks var en bekvemmelighed frem for et krav. At reducere selektoren for fjern-trafik til de undernet, der reelt hører bag IPsec, fjerner konflikten for alle værter på én gang, og det koster en ny nøgleforhandling frem for en ny komponent.

En passthrough-undtagelse er den kirurgiske mulighed, når den brede selektor skal bestå. strongSwan understøtter en separat forbindelse, hvis child bruger pass-tilstand, hvilket fortæller kernen, at den matchende trafik ikke må behandles af IPsec. Loopback-fjernadressen forhindrer, at den forbindelse vælges for indkommende peers, og selektorerne skal beskrive det reelle autoriserede par frem for alt.

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-konfigurationseksemplerne dokumenterer denne politiktype og loopback-peer-konventionen. Den tredje mulighed er et rutebaseret design med XFRM-interfaces, som binder politik til trafik, der routes gennem et navngivet interface i stedet for til en global selektor. Det er en migrering, ikke en justering, og trafikken skal stadig opfylde de forhandlede selektorer.

Bevis undtagelsen uden at svække resten

Når ændringen er indlæst, test undtagelsen og en almindelig destination, der skal forblive beskyttet. Kontrollér begge retninger, og slip derefter OpenVPN-tunnellen og bekræft, hvad der sker med den undtagne trafik. En undtagelse, der lydløst sender det præfiks i klartekst, når tunnellen er nede, er en politikbeslutning, du bør træffe med vilje, ikke opdage under en hændelse.

Notér, hvilket præfiks der bruger hvilken vej og hvorfor. Ellers vil den næste ingeniør, der ser en bred selektor, genåbne den samme undersøgelse, og svaret vil ligge i en commit-besked, som ingen læser.