En inläst strongSwan-profil är inte en aktiv tunnel

Att lista en anslutning i strongSwan-konfigurationen bevisar bara att en definition har lästs in. Det betyder inte att motparten har kontaktats, att det finns en IKE-SA eller att någon trafik skyddas. Daemonen behandlar definitioner och levande associationer som separata objekt, och avståndet mellan dem är ett medvetet designval. Att veta vilket objekt du undersöker gör ett vagt fel till ett konkret nästa kommando.

Inläsning är inte anslutning

En inläst anslutning är ett påstående om vad som kan förhandlas senare: motpartsadresser, autentiseringsuppgifter, förslag och trafikväljare. Inget i det påståendet kräver att daemonen har ringt någon. En gateway kan vänta på andra sidan, initiera vid start eller vänta på att matchande trafik ska väcka den. Alla tre är giltiga, och alla tre ser identiska ut i konfigurationsfilen tills du läser startpolicyn.

Operatörer hamnar i problem genom att läsa definitionslistan som en statuslista. Profilen finns där, så tunneln antas vara uppe, och nästa timme går åt till att felsöka rutter för en association som aldrig byggdes.

Det motsatta misstaget är lika vanligt. En saknad profil skickar folk på jakt efter ett nätverksfel när konfigurationen aldrig lästes in. Namnge objektet och kör sedan kommandot som observerar det.

Tre objekt, tre observationer

strongSwan håller en inläst definition, en IKE-SA och en CHILD-SA. Den första är konfiguration, den andra är en autentiserad kontrollrelation och den tredje är förhandlat skydd för vald trafik. De har till och med separata namn, så en profil som heter hq kan äga en child som heter hq-lan.

Tabellen kopplar varje lager till kommandot som visar det. Läs raden innan du läser loggen.

Att begära childen bygger först dess överordnade IKE-SA när ingen finns. Att bara begära IKE-SA:n är ett annat anrop. En kontrollkanal som autentiserar fint garanterar inte den child du bad om.

Den skillnaden spelar roll vid ett delvis fel. En IKE-SA kan vara frisk medan childen misslyckas på en väljaravvikelse eller ett förslag som motparten inte accepterar. De två objekten misslyckas av olika skäl, så de förtjänar separata observationer.

Välj starthandlingen medvetet

I swanctl.conf styr en childs start_action beteendet efter inläsningen. Standardvärdet none lämnar definitionen för manuell initiering eller responder-användning. start ringer upp, medan trap lämnar en policy som förhandlar så snart matchande trafik dyker upp.

Så både 'inläsning startar aldrig en tunnel' och 'inläsning startar alltid en' är fel. Handlingen är en del av profilen och bör matcha motpartens roll. Två gateways som båda väntar på andra sidan ger tystnad, inte en tunnel.

Med trap måste trafiken matcha väljarna, så en orelaterad ping väcker ingenting. Med start måste motpartsadressen vara användbar och båda sidor måste enas om autentisering och förslag. Ingen av handlingarna ersätter kontrollen av dessa förutsättningar.

Återhämtning är en separat policy

Uppstart är inte en keepalive. Döda-motparter-detektering, uttrycklig stängning från motparten, omslutning av nycklar och en omstart av processen är olika livscykelhändelser med egna inställningar. Konfigurera var och en medvetet i stället för att förvänta dig att en första start täcker alla.

En tunnel som kommer upp vid start och dör en timme senare är en återhämtningsfråga. Startpolicyn gjorde sitt jobb och slutade sedan spela roll. Titta på DPD- och nyckelomslutningsinställningar innan du skyller på den första förhandlingen.

Att ersätta inlästa definitioner är en egen operation. Icke-standardmässiga startpolicyn har dokumenterade omvända åtgärder, och en omladdning är en driftförändring snarare än ett antagande att varje association uppdaterades på plats. Genomför omladdningar i steg där en återanslutning är acceptabel. Behåll den gamla konfigurationen tills den nya är bevisad.

Kontrollera vad som finns innan du felsöker routing

Kör de tre observationerna i ordning: inlästa definitioner, aktiva IKE-SA:er och child-poster. Varje svar snävar in nästa fråga. Hoppa över ett steg och du felsöker till slut ett lager som aldrig byggdes.

Börja med det som är inläst och det som faktiskt är upprättat:

swanctl --list-conns
swanctl --list-sas

Om childen saknas medan profilen är korrekt, initiera den vid namn och se vad som händer. Utdata säger oftast om den överordnade kom upp först.

swanctl --initiate --child hq-lan

En aktiv CHILD-SA är inte mållinjen. Vidarebefordringsregler, rutter och applikationens egen auktorisering måste fortfarande stämma. Livscykeln svarar på vad som förhandlades; den kan inte avgöra vem som får använda tjänsten.