Kvifor ei OpenVPN-rute tapar mot ein strongSwan XFRM-politikk

Pakkar kan følgje ei OpenVPN-rute og likevel bli fanga opp av ein IPsec-politikk, og den kombinasjonen ser ut som ein rutefeil frå alle vinklar utanom den rette. Linux løyser opp ei rute og rådfører seg deretter med ein eigen tryggleikspolitikkdatabase, så ei meir spesifikk målrute fortrengjer ikkje ein samsvarande XFRM-politikk. Det synlege symptomet er trafikk som forlèt verten og aldri kjem fram, medan begge tunnelane melder seg friske. Tre alternativ løyser det, og kva du vel avheng av kva av dei to vegane som skal bera det prefikset.

To avgjerder, ikkje éi

Ruteval svarar på eit smalt spørsmål: kva neste hopp og kjeldeadresse som skal bera denne pakken. Tryggleikspolitikkdatabasen svarar på eit anna: krev denne pakken IPsec-vern, og under kva selektorar. Begge køyrer for same pakken, og å oppfylle det første seier ingenting om det andre. Difor kan ein endra metrikk eller ei ekstra statisk rute la symptomet vere urørt.

Ein brei IPsec-selektor er den vanlege årsaka. Ein politikk som vernar 172.16.0.0/12 dekkjer òg 172.20.8.0/24, som ein administrator kanskje vil nå gjennom OpenVPN-tunnelen i staden. Intensjonen finst berre i rutetabellen, og politiktdatabasen har aldri fått vita om han.

Handter det som ein konflikt mellom to konfigurerte vernvegar, ikkje som ein konkurranse mellom to metrikkar. Rettelsen høyrer heime i komponenten som vart konfigurert med feil omfang.

Les ruta kjernen faktisk vel

Start med oppslaget kjernen gjer, inkludert kjeldeadressa og kvar politikregel som kan leie henne til ein annan tabell. Ei rute i hovudtabellen blir kanskje aldri rådspurt om ein tidlegare regel vel ein annan tabell, og samsvar med lengste prefiks gjeld berre innanfor tabellen ein regel vel.

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

Den siste kommandoen er den som tel, fordi han skriv ut den valde ruta saman med kjeldeadressa kjernen ville brukt. Samanlikn den utskrifta med selektoren IPsec-politikken samsvarar med. Når ruta peikar på OpenVPN-grensesnittet og politikken framleis samsvarar med same paret, har du attskapt konflikten utan å gissa.

Hald dumpar fri for uvedkomande adresser før dei når ei sak. Ein rutetabell frå ein produksjonsvert ber intern topologi, og berre linjene som svarar på spørsmålet er verd å lime inn.

Les òg politikken som gjeld

Politikklista viser retning, selektorar og malen som avgjer kva som skjer med ein samsvarande pakke. Les utgåande retning først, deretter inngangssida for returtrafikken, fordi eit einvegsunntak gjev ei tilkopling som startar og aldri blir fullført.

ip -s xfrm policy
swanctl --list-sas

Samanlikn selektorane i lista med prefiksa tilkoplinga forhandla. Å slå av ruteinstallasjonen til strongSwan fjernar ikkje desse politikkane, og ein endra metrikk endrar ikkje kva kjelde- og målpar ein politikk vernar. Dei to falske rettingane er verd å utelukke tidleg, fordi det er dei folk prøver først.

Viss lista ikkje inneheld nokon politikk for prefikset du venta, er problemet ein annan stad, og rutetabellen fortel truleg sanninga. Viss ho inneheld ein breiare politikk som dekkjer prefikset, har du funne oppfanginga.

Tre alternativ når begge vegar er legitime

Å avgrense IPsec-selektoren er det reinaste alternativet når det breie prefikset var ei bekvemmelegheit og ikkje eit krav. Å redusere selektoren for fjern trafikk til subnettverka som verkeleg høyrer heime bak IPsec fjernar konflikten for alle vertar på ein gong, og det kostar ei ny nøkkelforhandling i staden for ein ny komponent.

Eit passthrough-unntak er det kirurgiske alternativet når den breie selektoren må bestå. strongSwan støttar ei eiga tilkopling der barnet brukar pass-modus, som fortel kjernen at den samsvarande trafikken ikkje skal handsamast av IPsec. Loopback-fjernadressa hindrar at den tilkoplinga blir vald for innkomande partar, og selektorane må skildre det faktiske autoriserte paret i staden 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-konfigurasjonseksempla dokumenterer denne politikktypen og loopback-partkonvensjonen. Det tredje alternativet er eit rutebasert design med XFRM-grensesnitt, som bind politikk til trafikk som blir ruta gjennom eit namngjeve grensesnitt i staden for til ein global selektor. Det er ein migrasjon og ikkje ei justering, og trafikken må framleis oppfylle dei forhandla selektorane.

Prov unntaket utan å svekkje resten

Etter at endringa er lasta, test unntaket og ein vanleg destinasjon som må halde fram med å vere verna. Kontroller begge retningar, slepp deretter OpenVPN-tunnelen og stadfest kva som skjer med den unnatekne trafikken. Eit unntak som lydlaust sender det prefikset i klartekst når tunnelen er nede, er ei politikkavgjerd du bør ta med vilje, ikkje oppdage under ei hending.

Noter kva prefiks som brukar kva veg og kvifor. Elles vil neste ingeniør som ser ein brei selektor opne same undersøkinga på nytt, og svaret vil liggje i ei commit-melding ingen les.