Een geladen strongSwan-profiel is geen actieve tunnel

Een verbinding in de strongSwan-configuratie opnemen bewijst alleen dat er een definitie is geladen. Het betekent niet dat de peer is benaderd, dat er een IKE-SA bestaat of dat er verkeer wordt beschermd. De daemon behandelt definities en levende associaties als aparte objecten, en de afstand daartussen is een bewuste ontwerpkeuze. Weten welk object je bekijkt, maakt van een vage storing een concrete volgende opdracht.

Laden is geen verbinden

Een geladen verbinding is een uitspraak over wat later onderhandeld kan worden: peeradressen, inloggegevens, voorstellen en verkeersselectors. Niets in die uitspraak vereist dat de daemon iemand heeft gebeld. Een gateway kan op de andere kant wachten, bij het opstarten zelf initiëren, of wachten tot passend verkeer hem wekt. Alle drie zijn geldig, en alle drie zien er in het configuratiebestand identiek uit tot je het startbeleid leest.

Beheerders komen in de problemen door de definitielijst als statuslijst te lezen. Het profiel staat er, dus de tunnel wordt als actief beschouwd, en het volgende uur gaat op aan het debuggen van routes voor een associatie die nooit is opgebouwd.

De omgekeerde fout komt net zo vaak voor. Een ontbrekend profiel stuurt mensen op zoek naar een netwerkstoring terwijl de configuratie nooit is geladen. Benoem het object en voer dan de opdracht uit die het waarneemt.

Drie objecten, drie waarnemingen

strongSwan houdt een geladen definitie, een IKE-SA en een CHILD-SA bij. De eerste is configuratie, de tweede een geauthenticeerde beheersrelatie en de derde onderhandelde bescherming voor geselecteerd verkeer. Ze hebben zelfs aparte namen, dus een profiel met de naam hq kan een child met de naam hq-lan hebben.

De tabel koppelt elke laag aan de opdracht die hem toont. Lees de rij voordat je de log leest.

Het opvragen van het child bouwt eerst de bovenliggende IKE-SA op als die er niet is. Alleen de IKE-SA opvragen is een andere aanroep. Een beheerkanaal dat netjes authenticeert, garandeert niet het child dat je hebt opgevraagd.

Dat verschil telt bij een gedeeltelijke storing. Een IKE-SA kan gezond zijn terwijl het child faalt op een selectorverschil of een voorstel dat de peer niet accepteert. De twee objecten falen om verschillende redenen, dus ze verdienen aparte waarnemingen.

Kies de startactie bewust

In swanctl.conf bepaalt start_action van een child het gedrag na het laden. De standaard none laat de definitie over aan handmatige initiatie of gebruik als responder. start kiest de verbinding, terwijl trap een beleid achterlaat dat onderhandelt zodra passend verkeer opduikt.

Dus zowel 'laden start nooit een tunnel' als 'laden start altijd een tunnel' is onjuist. De actie hoort bij het profiel en moet passen bij de rol van de peer. Twee gateways die beide op de andere kant wachten, produceren stilte, geen tunnel.

Met trap moet het verkeer bij de selectors passen, dus een losse ping wekt niets. Met start moet het peeradres bruikbaar zijn en moeten beide kanten het eens zijn over authenticatie en voorstellen. Geen van beide acties vervangt het controleren van die voorwaarden.

Herstel is een apart beleid

Opstarten is geen keepalive. Dead-peer-detectie, expliciet sluiten door de peer, rekeying en een procesherstart zijn verschillende gebeurtenissen in de levenscyclus met eigen instellingen. Configureer elk daarvan bewust in plaats van te verwachten dat een eerste start ze allemaal afdekt.

Een tunnel die bij het opstarten opkomt en een uur later sterft, is een herstelvraag. Het startbeleid deed zijn werk en deed er daarna niet meer toe. Kijk naar DPD- en rekey-instellingen voordat je de eerste onderhandeling de schuld geeft.

Het vervangen van geladen definities is een eigen handeling. Niet-standaard startbeleid heeft gedocumenteerde tegenacties, en een reload is een operationele wijziging in plaats van de aanname dat elke associatie ter plaatse is bijgewerkt. Voer reloads gefaseerd uit waar een herverbinding acceptabel is. Houd de oude configuratie tot de nieuwe bewezen is.

Controleer wat bestaat voordat je routing debugt

Voer de drie waarnemingen op volgorde uit: geladen definities, actieve IKE-SA's en child-vermeldingen. Elk antwoord verkleint de volgende vraag. Sla een stap over en je debugt uiteindelijk een laag die nooit is opgebouwd.

Begin met wat geladen is en wat daadwerkelijk tot stand is gebracht:

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

Ontbreekt het child terwijl het profiel correct is, initieer het dan bij naam en kijk wat er gebeurt. De uitvoer zegt meestal of de bovenliggende verbinding eerst opkwam.

swanctl --initiate --child hq-lan

Een actieve CHILD-SA is niet de finish. Doorstuurregels, routes en de eigen autorisatie van de applicatie moeten nog steeds kloppen. De levenscyclus beantwoordt wat is onderhandeld; hij kan niet beslissen wie de dienst mag gebruiken.