strongSwan trap-läge: varför IPsec-tunneln väntar på trafik

En inaktiv on-demand IPsec-tunnel visar ingen CHILD SA förrän ett paket matchar dess trap-policy. Läs tillståndet, kontrollera utlösaren och vet när start passar.

Ingen CHILD SA visas i statusutdata, tunneln ser död ut, och sedan får en ping till det avlägsna subnätet upp den. I ett on-demand IPsec-upplägg är den sekvensen designen, inte ett fel. En trap-policy installerar en selector och väntar, och det första paketet som matchar den startar IKE och CHILD SA-förhandlingen.

En del av förvirringen är ordförråd: ”up” används för två olika tillstånd. Konfigurationen är inläst och kernelpolicyn finns, men dataassociationen gör det inte. En monitor som bara räknar aktiva SA:er rapporterar en frisk plats som nere så länge ingen skickar trafik dit.

En inaktiv on-demand-tunnel har ingen CHILD SA att visa

En trap-post autentiserar ingenting i sig själv. Den ber kärnan hålla en policy för den valda trafiken och resa en acquisition när ett paket behöver den policyn. Daemonen tar emot acquisitionen, matchar den mot child-definitionen och förhandlar därifrån. Fram till dess finns ingen IKE SA att visa heller, vilket är varför båda listorna kan vara tomma samtidigt.

Det är den ordningen som gör loggarna läsbara. Först kommer acquisitionen, sedan IKE_SA_INIT och IKE_AUTH, sedan CHILD SA. Om loggen slutar direkt efter acquisitionen fungerade utlösaren. Förhandlingen misslyckades, och nästa fråga handlar om autentiseringsuppgifter, förslag eller nåbarhet, inte om trapen.

Med Linux-kärnbackend kan du se policyn innan någon SA finns. Kör ip xfrm policy och leta efter selectorn med riktning out och en mall som pekar på anslutningen. Den posten är on-demand-tillståndet, och dess närvaro är det första som måste bekräftas.

start_action avgör om något alls väntar

Varje child i swanctl.conf bär en start_action. start startar när konfigurationen läses in, trap installerar policyn och väntar, och none lämnar starten till något annat. Bara trap ger beteendet ”ping och den kommer upp” som beskrivs ovan.

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

De två trafikselectorerna definierar vad som räknas som intressant, och ett paket från en värd utanför dessa prefix utlöser inte trapen; det routas som vanligt. Att vidga selectorerna för att göra utlösaren ivrigare vidgar också det omfång tunneln hävdar att den skyddar, så härled dem från trafik du faktiskt vill kryptera.

Den swanctl.conf-referensen listar de accepterade värdena, tillsammans med de separata close- och DPD-åtgärderna som styr vad som händer när SA:n finns.

Ta reda på om utlösaren utlöstes alls

Börja med swanctl --list-conns och bekräfta att childen är inläst med den avsedda åtgärden. Skicka sedan ett paket från en värd inne i local_ts till en adress inne i remote_ts och följ swanctl --list-sas. Om utdata inte ändras nådde ingen acquisition daemonen.

Två vanliga skäl till en tyst trap: paketet source-NAT:ades innan det träffade policyn och matchar inte längre local_ts, eller så lästes anslutningen aldrig in på grund av ett syntax- eller autentiseringsfel. Kör swanctl --load-all igen och läs utdata innan du rör selectorerna. En anslutning som inte lästes in installerar ingen policy, så det finns inget för trafiken att utlösa.

Riktningen spelar också roll: en trap installerad för utgående trafik startar inte på ett inkommande paket. Om den avlägsna sidan ska resa tunneln behöver den sin egen trap, eller så behöver den här sidan start.

Att vänta på det första paketet är inte alltid rätt byte

Interaktiva sessioner märker etableringskostnaden. Den första begäran betalar för IKE-utbytet och CHILD-förhandlingen, och en klient med kort tidsfrist kan ge upp innan SA:n finns. Proaktiv start tar bort den fördröjningen på första paketet. Men den håller en tunnel uppe för trafik som kanske aldrig kommer.

Tre fakta avgör valet: hur ofta vägen används, om den första begäran har en stram tidsfrist och om peeren är nåbar vid uppstart. Sporadisk batchtrafik och en peer som kanske är offline vid uppstart talar båda för trap. En latenskänslig klient och en peer som alltid är nåbar talar för start. Om båda sidor kan initiera, kom överens om vem som äger utlösaren så att ni inte får dubbla förhandlingar.

En installerad policy är inte heller någon läckagesäker garanti. Om kravet är fail-closed måste brandväggen släppa trafik utan SA, och den regeln lever utanför child-definitionen.

Skriv ner de tre raderna som avslutar nästa diskussion

Skriv ner selectorerna, startåtgärden och kommandoutdata som visar policyn närvarande utan SA. De tre raderna skiljer ”on demand och inaktiv” från ”läses inte in” nästa gång någon rapporterar tunneln som nere. De tar en minut att fånga. Utan dem börjar samma utredning från noll.

Testa från en värd som verkligen ligger inne i selectorn. En ping från routern själv följer ofta en annan väg och bevisar ingenting om policyn som skyddar subnätet bakom den.

Relaterade artiklar