IKE SA staat, CHILD SA ontbreekt: waar de gegevens stoppen

De client zegt dat de authenticatie is gelukt, de IKE-status ziet er gezond uit en de tellers voor pakketten blijven op nul staan. Die combinatie is geen tegenspraak: IKEv2 scheidt een controlerelatie en een gegevensrelatie van elkaar, en de eerste kan slagen terwijl de tweede nooit opkomt. De parent regelt de onderhandeling; het child regelt het verkeer. Lees de twee lagen afzonderlijk voordat je de tunnel als defect bestempelt.

Wat de twee SAs doen

De IKE SA is de controlerelatie: hij authenticeert de peers en draagt de uitwisselingen die beveiliging onderhandelen, vervangen en verwijderen. Hij draagt nooit je applicatiepakketten. Een gezonde parent bewijst dus dat beide uiteinden het over het beveiligingsbeleid eens kunnen worden, en niets meer.

Een CHILD SA is de gegevensrelatie, onder de parent aangemaakt, met verkeersselectors en sleutelmateriaal voor een beschermde set. Hij is directioneel, dus de statusuitvoer toont een inkomende en een uitgaande associatie met aparte identificaties, en meestal aparte tellers per richting. Die koppeling is de reden waarom een richting kan werken terwijl de andere wegvalt, en waarom de zin de tunnel staat niets zegt over verkeer. Een parent kan ook meerdere children bevatten, en zo verbergt een enkel verbindingslabel precies degene die je nodig hebt.

Lees de child-vermeldingen, niet het verbindingslabel

Open de parentstatus en de childlijst samen en zoek het child waarvan de selectors overeenkomen met de flow die je test. Noteer zijn verkeersselectors, de onderhandelde algoritmen, zijn levensduur en de tellers in beide richtingen. Als er meerdere children bestaan, vergelijk dan op selectors en niet op positie, want de positie verandert na een rekey. Schrijf de identificaties op voordat je iets wijzigt.

Als de parent een andere verkeersset vermeldt dan degene die je test, lees je het verkeerde child. Dat is een probleem met de selectors, geen kapotte tunnel.

Leg ook tijdstempels vast. Een rekey kan een laag vervangen terwijl de andere opgezet blijft, en een child dat nieuw lijkt, kan de vervanger zijn van degene die je bekeek. Vergelijk de identificaties voordat je concludeert dat een child verdwenen is.

Wanneer er geen child bestaat

De authenticatie kan slagen terwijl het gegevensvoorstel of de selectors mislukken, en dan blijft er een parent zonder enig child over. De gebruikelijke oorzaak is een algoritmeverschil of een verschil in verkeersselectors, en beide peers loggen het geweigerde voorstel. Lees beide uiteinden, want de kant die je bereikt, kan alleen de weigering tonen. Repareer het verschil in plaats van de parent te herstarten, want dat herhaalt dezelfde mislukte onderhandeling en voegt een storing toe aan het bewijs.

Een parent die zich steeds opnieuw opzet, is een ander falen dan een parent die blijft staan zonder child. In het tweede geval noemen de logs het voorstel dat geweigerd werd, dus verzamel dat voorstel van beide uiteinden voordat je een beleid wijzigt.

Wanneer het child bestaat maar de tellers op nul blijven

Stuur een nieuwe aanvraag die bij de child-selectors past. Een aanvraag naar een bestemming buiten dat beleid beweegt de tellers niet, hoe succesvol ze er ook uitziet.

Controleer de route die de flow in de tunnel moet duwen, want een child zonder verkeer is vaak een child waarnaar niets wordt gerouteerd. Tellers die maar in een richting bewegen, wijzen op een verschil in selectors of beleid op het retourpad. Kijk naar de retourselectors van de remote peer voordat je de lokale kant aanraakt. Een nieuwe aanvraag geeft je ook een tijdstempel om tegen de statusuitvoer van beide uiteinden te leggen.

Benoem de laag in het verslag

Meld het falen als drie velden en niet als een oordeel: de laag die faalde, de uitwisseling of het child dat je onderzocht, en het bewijs dat je hebt. De laag is een van drie: de parent werd nooit opgezet, de child-onderhandeling werd geweigerd, of er bestaat een child en het verkeer bereikt het niet. Het bewijs is de child-identificatie met haar selectors en tellers, of het geweigerde voorstel geciteerd uit beide logs. Iedereen die dat leest, kan meteen naar de uitwisseling die ertoe doet en hoeft niet te vragen welke VPN je bedoelt.

De strongSwan IKEv2-documentatie laat zien hoe die lagen in de statusuitvoer verschijnen. Voeg de child-uitvoer toe die je getest hebt, niet alleen de parent-samenvatting.