Eén omhoog, nul verbindend: wat die strongSwan-regel telt

Lees je een statusregel met Security Associations (1 up, 0 connecting), dan lijkt het een rapport over één werkende tunnel. Twee subnetten sturen er tegelijk verkeer doorheen, dus het getal lijkt te liegen. Het liegt niet; het telt IKE-associaties, en één daarvan kan meerdere kinderen huisvesten. Lees de inventarissen voordat je een voorstel of een route aanraakt.

Waarom de kop en het verkeer niet overeenkomen

De oude stroke-uitvoer noemt zijn totaal beveiligingsassociaties en leidt dat af van de IKE-associatiebeheerder. Elke opgezette IKE-associatie draagt er één bij, ongeacht hoeveel CHILD SA’s eronder zitten. Eén IKEv2-ouder draagt meestal meerdere kinderen, één per paar verkeersselectoren, en de onderhandelde selectoren van een kind kunnen meer dan één adres of prefix dekken. Het aantal adressen in je configuratie heeft dus geen vaste relatie met het getal in de kop.

Moderne uitvoer toont soms een totaal in plaats van de oude formulering “up”, en een door swanctl beheerde daemon wordt helemaal niet door oude stroke-instellingen aangestuurd. Ga niet uit van de formulering en ook niet van de telregel tussen versies.

Vergelijk drie inventarissen voordat je iets wijzigt

Begin met wat geladen is, dan wat onderhandeld is, dan wat daadwerkelijk pakketten verplaatst. Dat zijn drie verschillende vragen en elk heeft zijn eigen commando.

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

De eerste somt verbindingsdefinities op die de daemon heeft geaccepteerd. De tweede somt opgezette IKE-associaties met hun kinderen op, en daar verschijnt de echte hiërarchie. Een definitie die in een bestand staat maar in de eerste lijst ontbreekt, is nooit geladen, en geen enkele hoeveelheid herhaalpogingen van de initiator lost dat op. Als je in plaats daarvan de oude interface draait, is het equivalente paar ipsec statusall en dezelfde swanctl-lijst, afhankelijk van welke plug-in de configuratie bezit. Meng geen gereedschap tussen twee daemons op één host en verwacht geen één samenhangend antwoord.

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

De ruwe vorm houdt identificaties en selectoren zichtbaar voor vergelijking, en de kernelstatuslijst laat zien wat de stack denkt dat hij heeft geïnstalleerd. Wanneer de daemon en de kernel het niet eens zijn, is de daemon opnieuw gestart rond een bestaand kind of is het kernelobject eronder verwijderd.

Lees de hiërarchie, niet het totaal

Een illustratieve opgezette ouder met twee kinderen ziet eruit als één knooppunt met twee kinderen eronder, elk gelabeld met zijn eigen status en modus. Dump de werkelijke uitvoer en tel de kinderen zelf in plaats van een samenvatting te lezen die iemand uit een dashboard heeft geplakt.

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

Eén ouder met twee geïnstalleerde kinderen is een gezonde tunnel voor twee subnetten. Eén ouder met één geïnstalleerd en één ontbrekend kind is een andere situatie, en de selectoren van het ontbrekende kind zijn wat je met het voorstel van de andere kant moet vergelijken. Tijdens sleutelvernieuwing kunnen een oud kind en zijn vervanger kort samen verschijnen. Bewaar de tijdstempel bij de momentopname, want een telling midden in de vernieuwing lijkt op duplicatie en een telling erna lijkt op verlies.

Geladen, geïnstalleerd en verkeer dat passeert

Een kind in de geïnstalleerde status heeft onderhandelde parameters en een kernelvermelding. Maar het heeft niet noodzakelijk een pakket gedragen: selectoren kunnen smaller zijn dan het verkeer dat je verwacht, en een route kan dat verkeer elders heen sturen voordat de tunnel het ooit ziet. Stuur een stroom die bij de onderhandelde selectoren past vanaf een geautoriseerde host, en lees daarna de tellers van het kind in plaats van de kop. Een teller die op nul blijft staan terwijl je passend verkeer genereert, wijst op routering of beleid, niet op IKE.

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

Een benoemd kind starten is een bewuste handeling met een zichtbaar resultaat, en het scheidt “de verbinding is inactief omdat niemand erom vroeg” van “de verbinding kan niet omhoogkomen”. Een trapbeleid op aanvraag gedraagt zich precies als het eerste geval, dus lees de startinstelling van de verbinding voordat je het een fout noemt.

Wanneer de telling echt fout is

Als een definitie in de geladen inventaris ontbreekt, kijk dan naar het laden van de configuratie en welke daemon-instantie draait. Als hij geladen is maar nooit onderhandelt, vergelijk dan voorstellen, authenticatiecontext en selectoren met de peer, één kind tegelijk. Wijzig één element per poging en noteer de identificatie die je hebt gewijzigd. Een voorstel terugdraaien is triviaal als je weet welke; het is giswerk na drie wijzigingen die nooit zijn gescheiden.

Herstel eerst de verkeerde lezing. De meeste meldingen van een “ontbrekende” tweede tunnel eindigen met twee geïnstalleerde kinderen onder één ouder, en het enige dat ooit kapot was, was de samenvattingsregel waar mensen op vertrouwden in plaats van de hiërarchie.