strongSwan trap-tilstand: hvorfor IPsec-tunnelen venter på trafik

En inaktiv on-demand IPsec-tunnel viser ingen CHILD SA, før en pakke matcher dens trap-politik. Læs tilstanden, tjek udløseren, og vid hvornår start passer.

Der vises ingen CHILD SA i statusoutputtet, tunnelen ser død ud, og så får et ping til det fjerne subnet den op. I et on-demand IPsec-setup er den sekvens designet, ikke en fejl. En trap-politik installerer en selector og venter, og den første pakke, der matcher den, starter IKE og CHILD SA-forhandlingen.

En del af forvirringen er ordforråd: “up” bruges om to forskellige tilstande. Konfigurationen er indlæst, og kernelpolitikken findes, men dataassociationen gør ikke. En monitor, der kun tæller aktive SA'er, vil rapportere et sundt site som nede, så længe ingen sender trafik til det.

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

En trap-post autentificerer intet i sig selv. Den beder kernen om at holde en politik for den valgte trafik og rejse en acquisition, når en pakke har brug for den politik. Daemonen modtager acquisitionen, matcher den til child-definitionen og forhandler derfra. Indtil da er der heller ingen IKE SA at vise, og derfor kan begge lister være tomme på én gang.

Det er den rækkefølge, der gør loggene læsbare. Acquisitionen kommer først, derefter IKE_SA_INIT og IKE_AUTH, derefter CHILD SA. Hvis loggen slutter lige efter acquisitionen, virkede udløseren. Forhandlingen mislykkedes, og det næste spørgsmål handler om legitimationsoplysninger, forslag eller rækkevidde, ikke om trap.

Med Linux-kernelbackend kan du se politikken, før nogen SA findes. Kør ip xfrm policy og find selectoren med retning out og en skabelon, der peger på forbindelsen. Den post er on-demand-tilstanden, og dens tilstedeværelse er det første, der skal bekræftes.

start_action afgør, om noget overhovedet venter

Hvert child i swanctl.conf har en start_action. start starter, når konfigurationen indlæses, trap installerer politikken og venter, og none overlader opstarten til noget andet. Kun trap giver den ping-og-den-kommer-op-adfærd, der 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 trafikselectorer definerer, hvad der tæller som interessant, og en pakke fra en vært uden for disse præfikser udløser ikke trappen; den router som sædvanligt. At udvide selectorerne for at gøre udløseren mere ivrig udvider også det omfang, tunnelen hævder at beskytte, så udled dem af trafik, du faktisk vil kryptere.

Den swanctl.conf-reference viser de accepterede værdier sammen med de separate close- og DPD-handlinger, der styrer, hvad der sker, når SA'en findes.

Find ud af, om udløseren overhovedet blev udløst

Start med swanctl --list-conns og bekræft, at child'et er indlæst med den handling, du havde tænkt. Send derefter én pakke fra en vært inde i local_ts til en adresse inde i remote_ts og hold øje med swanctl --list-sas. Hvis outputtet ikke ændrer sig, nåede ingen acquisition daemonen.

To almindelige grunde til en tavs trap: pakken blev source-NAT'et, før den ramte politikken, og matcher ikke længere local_ts, eller forbindelsen blev aldrig indlæst på grund af en syntaks- eller legitimationsfejl. Kør swanctl --load-all igen, og læs outputtet, før du rører selectorerne. En forbindelse, der ikke blev indlæst, installerer ingen politik, så der er intet, trafikken kan udløse.

Retningen betyder også noget: en trap installeret til udgående trafik starter ikke på en indgående pakke. Hvis den fjerne side skal rejse tunnelen, har den brug for sin egen trap, eller denne side har brug for start.

At vente på den første pakke er ikke altid den rigtige handel

Interaktive sessioner mærker opsætningsomkostningen. Den første anmodning betaler for IKE-udvekslingen og CHILD-forhandlingen, og en klient med en kort frist kan give op, før SA'en findes. Proaktiv start fjerner den forsinkelse på første pakke. Men den holder en tunnel oppe for trafik, der måske aldrig kommer.

Tre fakta afgør valget: hvor ofte stien bruges, om den første anmodning har en stram frist, og om peer'en kan nås ved boot. Sporadisk batchtrafik og en peer, der måske er offline ved boot, taler begge for trap. En latensfølsom klient og en peer, der altid kan nås, taler for start. Hvis begge sider kan initiere, så aftal, hvem der ejer udløseren, så I ikke får dobbelte forhandlinger.

En installeret politik er heller ikke en lækagesikker garanti. Hvis kravet er fail-closed, skal firewalle droppe trafik uden SA, og den regel lever uden for child-definitionen.

Skriv de tre linjer ned, der afslutter den næste diskussion

Skriv selectorerne, opstarts-handlingen og kommandooutputtet ned, som viser politikken til stede uden SA. De tre linjer skiller “on demand og inaktiv” fra “indlæses ikke” næste gang, nogen rapporterer tunnelen som nede. De tager et minut at fange. Uden dem starter den samme undersøgelse fra nul.

Test fra en vært, der virkelig er inde i selectoren. Et ping fra routeren selv følger ofte en anden vej og beviser intet om politikken, der beskytter subnettet bag den.

Relaterede artikler