En uppe, noll anslutande: vad den strongSwan-raden räknar

Läs en statusrad som säger Security Associations (1 up, 0 connecting) och den ser ut som en rapport om en enda tunnel som fungerar. Två subnät skickar trafik genom den samtidigt, så talet verkar ljuga. Det ljuger inte; det räknar IKE-associationer, och en av dem kan hysa flera barn. Läs inventarierna innan du rör en proposition eller en rutt.

Varför rubriken och trafiken inte stämmer

Den gamla stroke-utskriften kallar sin summa säkerhetsassociationer och härleder den från IKE-associationshanteraren. Varje upprättad IKE-association bidrar med en, oavsett hur många CHILD SA som ligger under den. En enda IKEv2-förälder bär vanligtvis flera barn, ett per trafikväljarpar, och ett barns förhandlade väljare kan täcka mer än en adress eller ett prefix. Antalet adresser i din konfiguration har därför ingen fast relation till talet i rubriken.

Modern utskrift visar ibland en summa i stället för den gamla formuleringen “up”, och en swanctl-styrd daemon styrs inte alls av gamla stroke-inställningar. Utgå inte från vare sig formuleringen eller räkneregeln mellan versioner.

Jämför tre inventarier innan du ändrar något

Börja med det som är inläst, sedan det som är förhandlat, sedan det som faktiskt flyttar paket. Det är tre olika frågor och var och en har sitt eget kommando.

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

Den första listar de anslutningsdefinitioner som daemonen accepterade. Den andra listar upprättade IKE-associationer med sina barn, och det är där den verkliga hierarkin syns. En definition som finns i en fil men saknas i den första listan lästes aldrig in, och ingen mängd nya försök från initiativtagaren rättar det. Om du i stället kör det gamla gränssnittet är det motsvarande paret ipsec statusall och samma swanctl-lista, beroende på vilket plugin som äger konfigurationen. Blanda inte verktyg mellan två daemoner på en värd och förvänta dig inte ett enda sammanhängande svar.

swanctl --list-sas --raw | head -40
ip -s xfrm state

Råformen håller identifierare och väljare synliga för jämförelse, och kärnstatuslistan visar vad stacken tror att den har installerat. När daemonen och kärnan inte är överens har antingen daemonen startats om kring ett befintligt barn eller så har kärnobjektet tagits bort under det.

Läs hierarkin, inte summan

En illustrativ upprättad förälder med två barn ser ut som en nod med två barn under sig, var och en märkt med sin egen status och sitt läge. Dumpa den faktiska utskriften och räkna barnen själv i stället för att läsa en sammanfattning som någon klistrat in från en instrumentpanel.

swanctl --list-sas
swanctl --list-conns --raw | grep -A4 'accounting'

En förälder med två installerade barn är en frisk tunnel för två subnät. En förälder med ett installerat och ett saknat barn är en annan situation, och det saknade barnets väljare är det som ska jämföras med den bortre sidans proposition. Under nyckelbytet kan ett gammalt barn och dess ersättare båda synas under ett kort fönster. Behåll tidsstämpeln med ögonblicksbilden, för en räkning tagen mitt i förnyelsen ser ut som duplicering och en tagen efteråt ser ut som förlust.

Inläst, installerat och trafik som passerar

Ett barn i installerat tillstånd har förhandlade parametrar och en kärnpost. Men det har inte nödvändigtvis burit ett paket: väljare kan vara smalare än trafiken du väntar dig, och en rutt kan skicka den trafiken någon annanstans innan tunneln ens ser den. Skicka ett flöde som matchar de förhandlade väljarna från en auktoriserad värd, och läs sedan barnets räknare i stället för rubriken. En räknare som står kvar på noll medan du genererar matchande trafik pekar på routing eller policy, inte på IKE.

swanctl --initiate --child accounting
swanctl --list-sas --raw | grep -E 'bytes|packets'

Att starta ett namngivet barn är en avsiktlig åtgärd med ett synligt resultat, och den skiljer “anslutningen är overksam eftersom ingen bad om den” från “anslutningen kan inte komma upp”. En trap-policy på begäran beter sig exakt som det första fallet, så läs anslutningens startinställning innan du kallar det ett fel.

När räkningen verkligen är fel

Om en definition saknas i det inlästa inventariet, titta på inläsningen av konfigurationen och vilken daemoninstans som körs. Om den är inläst men aldrig förhandlar, jämför propositioner, autentiseringskontext och väljare med motparten, ett barn i taget. Ändra ett element per försök och notera identifieraren du ändrade. Att rulla tillbaka en proposition är trivialt när du vet vilken; det är gissning efter tre ändringar som aldrig separerades.

Rätta till felläsningen först. De flesta rapporter om en “saknad” andra tunnel slutar med två installerade barn under en förälder, och det enda som någonsin var trasigt var sammanfattningsraden som folk litade på i stället för hierarkin.