Hvorfor en OpenVPN-rute taper mot en strongSwan XFRM-policy

Pakker kan følge en OpenVPN-rute og likevel bli fanget opp av en IPsec-policy, og den kombinasjonen ser ut som en rutingsfeil fra alle vinkler unntatt den riktige. Linux løser opp en rute og konsulterer deretter en egen sikkerhetspolicydatabase, så en mer spesifikk destinasjonsrute fortrenger ikke en samsvarende XFRM-policy. Det synlige symptomet er trafikk som forlater verten og aldri kommer frem, mens begge tunnelene rapporterer seg friske. Tre alternativer løser det, og hvilket du velger avhenger av hvilken av de to veiene som skal bære det prefikset.

To beslutninger, ikke én

Rutevalg svarer på et smalt spørsmål: hvilken neste hopp og kildeadresse skal bære denne pakken. Sikkerhetspolicydatabasen svarer på et annet: krever denne pakken IPsec-beskyttelse, og under hvilke selektorer. Begge kjører for samme pakke, og å oppfylle det første sier ingenting om det andre. Derfor kan en endret metrikk eller en ekstra statisk rute la symptomet være urørt.

En bred IPsec-selektor er den vanlige årsaken. En policy som beskytter 172.16.0.0/12 dekker også 172.20.8.0/24, som en administrator kanskje vil nå gjennom OpenVPN-tunnelen i stedet. Intensjonen finnes bare i rutetabellen, og policydatabasen har aldri fått vite om den.

Behandle det som en konflikt mellom to konfigurerte beskyttelsesveier, ikke som en konkurranse mellom to metrikker. Rettelsen hører hjemme i komponenten som ble konfigurert med feil omfang.

Les ruten kjernen faktisk velger

Start med oppslaget kjernen gjør, inkludert kildeadressen og enhver policyregel som kan lede den til en annen tabell. En rute i hovedtabellen blir kanskje aldri konsultert hvis en tidligere regel velger en annen tabell, og samsvar med lengste prefiks gjelder bare innenfor tabellen en regel velger.

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 betyr noe, fordi den skriver ut den valgte ruten sammen med kildeadressen kjernen ville brukt. Sammenlign den utskriften med selektoren IPsec-policyen samsvarer med. Når ruten peker på OpenVPN-grensesnittet og policyen fortsatt samsvarer med samme par, har du gjenskapt konflikten uten å gjette.

Hold dumper fri for uvedkommende adresser før de når en sak. En rutetabell fra en produksjonsvert bærer intern topologi, og bare linjene som svarer på spørsmålet er verdt å lime inn.

Les også policyen som gjelder

Policylisten viser retning, selektorer og malen som avgjør hva som skjer med en samsvarende pakke. Les utgående retning først, deretter inngangssiden for returtrafikken, fordi et enveisunntak gir en tilkobling som starter og aldri fullføres.

ip -s xfrm policy
swanctl --list-sas

Sammenlign selektorene i listen med prefiksene tilkoblingen forhandlet. Å slå av strongSwans ruteinstallasjon fjerner ikke disse policyene, og en endret metrikk endrer ikke hvilket kilde- og destinasjonspar en policy beskytter. De to falske rettelsene er verdt å utelukke tidlig, fordi det er dem folk prøver først.

Hvis listen ikke inneholder noen policy for prefikset du forventet, er problemet et annet sted, og rutetabellen forteller sannsynligvis sannheten. Hvis den inneholder en bredere policy som dekker prefikset, har du funnet oppfangingen.

Tre alternativer når begge veier er legitime

Å avgrense IPsec-selektoren er det reneste alternativet når det brede prefikset var en bekvemmelighet og ikke et krav. Å redusere selektoren for ekstern trafikk til subnettene som virkelig hører hjemme bak IPsec fjerner konflikten for alle verter på én gang, og det koster en ny nøkkelforhandling i stedet for en ny komponent.

Et passthrough-unntak er det kirurgiske alternativet når den brede selektoren må bestå. strongSwan støtter en egen tilkobling der barnet bruker pass-modus, som forteller kjernen at den samsvarende trafikken ikke skal behandles av IPsec. Loopback-fjernadressen hindrer at den tilkoblingen velges for innkommende parter, og selektorene må beskrive det faktiske autoriserte paret i stedet 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-konfigurasjonseksemplene dokumenterer denne policytypen og loopback-partkonvensjonen. Det tredje alternativet er et rutebasert design med XFRM-grensesnitt, som binder policy til trafikk som rutes gjennom et navngitt grensesnitt i stedet for til en global selektor. Det er en migrering og ikke en justering, og trafikken må fortsatt oppfylle de forhandlede selektorene.

Bevis unntaket uten å svekke resten

Etter at endringen er lastet, test unntaket og en vanlig destinasjon som må forbli beskyttet. Kontroller begge retninger, slipp deretter OpenVPN-tunnelen og bekreft hva som skjer med den unntatte trafikken. Et unntak som lydløst sender det prefikset i klartekst når tunnelen er nede, er en policybeslutning du bør ta med vilje, ikke oppdage under en hendelse.

Noter hvilket prefiks som bruker hvilken vei og hvorfor. Ellers vil neste ingeniør som ser en bred selektor gjenåpne samme undersøkelse, og svaret vil ligge i en commit-melding ingen leser.