strongSwan trap-modus: kvifor IPsec-tunnelen ventar på trafikk

Ein inaktiv on-demand IPsec-tunnel viser ingen CHILD SA før ein pakke samsvarer med trap-policyen. Les tilstanden, sjekk utløysaren og vit når start passar.

Ingen CHILD SA viser seg i statusutdata, tunnelen ser daud ut, og så får eit ping til det fjerne subnettet han opp. I eit on-demand IPsec-oppsett er den sekvensen designet, ikkje ein feil. Ein trap-policy installerer ein selector og ventar, og den første pakken som samsvarer med han, startar IKE og CHILD SA-forhandlinga.

Ein del av forvirringa er ordforråd: «up» vert brukt om to ulike tilstandar. Konfigurasjonen er lasta og kjernepolicyen finst, men dataassosiasjonen gjer det ikkje. Ein monitor som berre tel aktive SA-ar, vil rapportere eit sunt nettstad som nede så lenge ingen sender trafikk dit.

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

Ei trap-oppføring autentiserer ingenting i seg sjølv. Ho ber kjernen halde ein policy for den valde trafikken og reise ein acquisition når ein pakke treng den policyen. Daemonen mottek acquisitionen, matchar han mot child-definisjonen og forhandlar derifrå. Fram til det punktet finst det heller ingen IKE SA å vise, og difor kan begge listene vere tomme samtidig.

Det er den rekkefølgja som gjer loggane lesbare. Acquisitionen kjem først, deretter IKE_SA_INIT og IKE_AUTH, deretter CHILD SA. Viss loggen sluttar rett etter acquisitionen, verka utløysaren. Forhandlinga mislukkast, og neste spørsmål handlar om legitimasjon, forslag eller rekkevidd, ikkje om trap.

Med Linux-kjernebackend kan du sjå policyen før nokon SA finst. Køyr ip xfrm policy og sjå etter selectoren med retning out og ein mal som peikar på sambandet. Den oppføringa er on-demand-tilstanden, og tilstadeværet er det første som må stadfestast.

start_action avgjer om noko i det heile ventar

Kvar child i swanctl.conf har ein start_action. start startar når konfigurasjonen vert lasta, trap installerer policyen og ventar, og none overlèt oppstarten til noko anna. Berre trap gjev åtferda «ping og han kjem opp» som er skildra ovanfor.

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

Dei to trafikkselectora definerer kva som vert rekna som interessant, og ein pakke frå ein vert utanfor desse prefiksa utløyser ikkje trapen; han vert ruta som vanleg. Å utvide selectorane for å gjere utløysaren meir ivrig utvidar òg omfanget tunnelen hevdar å verne, så leid dei ut frå trafikk du faktisk vil kryptere.

Den swanctl.conf-referansen viser dei aksepterte verdiane, saman med dei separate close- og DPD-handlingane som styrer kva som skjer når SA-en finst.

Finn ut om utløysaren vart utløyst i det heile

Start med swanctl --list-conns og stadfest at child-en er lasta med handlinga du hadde tenkt. Send deretter éin pakke frå ein vert inne i local_ts til ei adresse inne i remote_ts og følg med på swanctl --list-sas. Viss utdata ikkje endrar seg, nådde ingen acquisition daemonen.

To vanlege grunnar til ein stille trap: pakken vart source-NAT-a før han traff policyen og samsvarer ikkje lenger med local_ts, eller sambandet vart aldri lasta på grunn av ein syntaks- eller legitimasjonsfeil. Køyr swanctl --load-all på nytt og les utdata før du rører selectorane. Eit samband som ikkje vart lasta, installerar ingen policy, så det er ingenting trafikken kan utløyse.

Retninga betyr òg noko: ein trap installert for utgåande trafikk startar ikkje på ein innkomande pakke. Viss den fjerne sida skal reise tunnelen, treng ho sin eigen trap, eller denne sida treng start.

Å vente på den første pakken er ikkje alltid den rette handelen

Interaktive sesjonar merkar oppsettkostnaden. Den første førespurnaden betaler for IKE-utvekslinga og CHILD-forhandlinga, og ein klient med kort frist kan gje opp før SA-en finst. Proaktiv start fjernar den forseinkinga på første pakke. Men han held ein tunnel oppe for trafikk som kanskje aldri kjem.

Tre fakta avgjer valet: kor ofte stien vert brukt, om den første førespurnaden har ein stram frist, og om peer-en er tilgjengeleg ved oppstart. Sporadisk batchtrafikk og ein peer som kanskje er offline ved oppstart talar begge for trap. Ein latensfølsam klient og ein peer som alltid er tilgjengeleg talar for start. Viss begge sider kan initiere, blir de einige om kven som eig utløysaren, så de ikkje får doble forhandlingar.

Ein installert policy er heller ikkje ein lekkasjegaranti. Viss kravet er fail-closed, må brannmuren droppe trafikk utan SA, og den regelen lever utanfor child-definisjonen.

Skriv ned dei tre linjene som avsluttar neste diskusjon

Skriv ned selectorane, oppstarts-handlinga og kommando-utdata som viser policyen til stades utan SA. Dei tre linjene skil «on demand og inaktiv» frå «vert ikkje lasta» neste gong nokon rapporterer tunnelen som nede. Dei tar eit minutt å fange. Utan dei startar same undersøkinga frå null.

Test frå ein vert som verkeleg er inne i selectoren. Eit ping frå ruteren sjølv følgjer ofte ein annan veg og beviser ingenting om policyen som vernar subnettet bak han.

Relaterte artiklar