strongSwan trap-modus: hvorfor IPsec-tunnelen venter på trafikk

Ingen CHILD SA vises i statusutdataene, tunnelen ser død ut, og så får et ping til det fjerne subnettet den opp. I et on-demand IPsec-oppsett er den sekvensen designet, ikke en feil. En trap-policy installerer en selector og venter, og den første pakken som samsvarer med den, starter IKE og CHILD SA-forhandlingen.

En del av forvirringen er ordforråd: «up» brukes om to forskjellige tilstander. Konfigurasjonen er lastet og kjernepolicyen finnes, men dataassosiasjonen gjør det ikke. En monitor som bare teller aktive SA-er, vil rapportere et sunt nettsted som nede så lenge ingen sender trafikk dit.

En inaktiv on-demand-tunnel har ingen CHILD SA å vise

En trap-oppføring autentiserer ingenting i seg selv. Den ber kjernen holde en policy for den valgte trafikken og reise en acquisition når en pakke trenger den policyen. Daemonen mottar acquisitionen, matcher den mot child-definisjonen og forhandler derfra. Fram til det punktet finnes det heller ingen IKE SA å vise, og derfor kan begge listene være tomme samtidig.

Det er den rekkefølgen som gjør loggene lesbare. Acquisitionen kommer først, deretter IKE_SA_INIT og IKE_AUTH, deretter CHILD SA. Hvis loggen slutter rett etter acquisitionen, virket utløseren. Forhandlingen mislyktes, og neste spørsmål handler om legitimasjon, forslag eller rekkevidde, ikke om trap.

Med Linux-kjernebackend kan du se policyen før noen SA finnes. Kjør ip xfrm policy og se etter selectoren med retning out og en mal som peker på forbindelsen. Den oppføringen er on-demand-tilstanden, og tilstedeværelsen er det første som må bekreftes.

start_action avgjør om noe i det hele tatt venter

Hver child i swanctl.conf har en start_action. start starter når konfigurasjonen lastes, trap installerer policyen og venter, og none overlater oppstarten til noe annet. Bare trap gir oppførselen «ping og den kommer opp» som er beskrevet ovenfor.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

De to trafikkselectorene definerer hva som regnes som interessant, og en pakke fra en vert utenfor disse prefiksene utløser ikke trapen; den rutes som vanlig. Å utvide selectorene for å gjøre utløseren mer ivrig utvider også omfanget tunnelen hevder å beskytte, så utled dem fra trafikk du faktisk vil kryptere.

Den swanctl.conf-referansen viser de aksepterte verdiene, sammen med de separate close- og DPD-handlingene som styrer hva som skjer når SA-en finnes.

Finn ut om utløseren ble utløst i det hele tatt

Start med swanctl --list-conns og bekreft at child-en er lastet med handlingen du hadde tenkt. Send deretter én pakke fra en vert inne i local_ts til en adresse inne i remote_ts og følg med på swanctl --list-sas. Hvis utdataene ikke endres, nådde ingen acquisition daemonen.

To vanlige grunner til en stille trap: pakken ble source-NAT-et før den traff policyen og samsvarer ikke lenger med local_ts, eller forbindelsen ble aldri lastet på grunn av en syntaks- eller legitimasjonsfeil. Kjør swanctl --load-all på nytt og les utdataene før du rører selectorene. En forbindelse som ikke ble lastet, installerer ingen policy, så det er ingenting trafikken kan utløse.

Retningen betyr også noe: en trap installert for utgående trafikk starter ikke på en innkommende pakke. Hvis den fjerne siden skal reise tunnelen, trenger den sin egen trap, eller denne siden trenger start.

Å vente på den første pakken er ikke alltid den riktige handelen

Interaktive sesjoner merker oppsettkostnaden. Den første forespørselen betaler for IKE-utvekslingen og CHILD-forhandlingen, og en klient med kort frist kan gi opp før SA-en finnes. Proaktiv start fjerner den forsinkelsen på første pakke. Men den holder en tunnel oppe for trafikk som kanskje aldri kommer.

Tre fakta avgjør valget: hvor ofte stien brukes, om den første forespørselen har en stram frist, og om peer-en er tilgjengelig ved oppstart. Sporadisk batchtrafikk og en peer som kanskje er offline ved oppstart taler begge for trap. En latensfølsom klient og en peer som alltid er tilgjengelig taler for start. Hvis begge sider kan initiere, blir dere enige om hvem som eier utløseren, så dere ikke får doble forhandlinger.

En installert policy er heller ikke en lekkerhetsgaranti. Hvis kravet er fail-closed, må brannmuren droppe trafikk uten SA, og den regelen lever utenfor child-definisjonen.

Skriv ned de tre linjene som avslutter neste diskusjon

Skriv ned selectorene, oppstarts-handlingen og kommando-utdataene som viser policyen til stede uten SA. De tre linjene skiller «on demand og inaktiv» fra «lastes ikke» neste gang noen rapporterer tunnelen som nede. De tar et minutt å fange. Uten dem starter samme undersøkelse fra null.

Test fra en vert som virkelig er inne i selectoren. Et ping fra ruteren selv følger ofte en annen vei og beviser ingenting om policyen som beskytter subnettet bak den.