IKEv2 is niet één handdruk: IKE SA, authenticatie en dan CHILD SA

Je denkt misschien dat een IKEv2-verbinding één uitwisseling is die eindigt met versleuteld verkeer. Het zijn er minstens twee, en de eerste authenticeert niemand. De peers beginnen met controleboodschappen, spreken cryptografische parameters af, bewijzen identiteit en onderhandelen pas daarna over de toestand die applicatiepakketten draagt. Die volgorde verklaart de mismatch die mensen steeds melden: de gateway antwoordt, de client zegt verbonden, en de private applicatie loopt nog steeds in een time-out. Hier is wat elke fase werkelijk doet, en wat daarna waar moet zijn.

De mythe: als de gateway antwoordt, ben je verbonden

Een antwoord op het eerste bericht bewijst dat het eindpunt bereikbaar en bereid is te praten. Het bewijst niet dat een account is geaccepteerd, dat een certificaatketen is gevalideerd, of dat enig databeleid is geïnstalleerd.

Die fouten gebeuren later, en ze geven andere symptomen. Een certificaatweigering of een EAP-fout komt pas na de eerste geslaagde uitwisseling, daarom zeggen een ping naar UDP 500 en een groen clientpictogram zo weinig.

IKE_SA_INIT: spreek parameters af, geen identiteit

De eerste uitwisseling draagt de voorstellen voor de IKE-beveiligingsassociatie: versleutelings- en integriteitsalgoritmen, een pseudorandomfunctie en een Diffie-Hellmangroep. De peers wisselen ook nonces uit, en elke kant leidt sleutelmateriaal voor de IKE SA af uit het gedeelde geheim dat die waarden opleveren. Niets in deze uitwisseling stelt vast wie de andere partij is. Het stelt vast dat beide kanten dezelfde sleutels kunnen berekenen en dat ze het over één voorstel eens zijn. Een responder die geen enkel voorstel bevalt, weigert de uitwisseling hier, daarom lijkt een versie- of algoritmeverschil op een server die plat ligt.

De IKE SA die hier ontstaat, beschermt alle latere beheeruitwisselingen. Dat is zijn taak, en het is een andere taak dan je pakketten beschermen.

IKE_AUTH: bewijs identiteit en bouw dan de eerste CHILD SA

De tweede uitwisseling draagt identiteit. Met certificaten ondertekent elke peer met zijn privésleutel en legt een keten voor die de andere moet valideren; met EAP daagt de responder de initiator uit via de gekozen methode. Hier komen eindelijk een verkeerde servernaam, een verlopen certificaat of een geweigerd wachtwoord boven.

Normaal onderhandelt IKE_AUTH ook de eerste CHILD SA, zodat de databescherming in dezelfde retourtrip wordt afgesproken. De initiator stelt verkeersselectoren voor, de responder vernauwt of weigert ze, en de sleutels voor het datapad worden van de IKE SA afgeleid. Dat betekent dat één uitwisseling op twee heel verschillende plekken kan falen: identiteit of beleid. Lees de notificatielading of de fout in plaats van de generieke handshakefout, want de oplossing voor het ene is een certificaat en voor het andere een subnetverschil.

Twee SA's, twee taken

Ze gescheiden houden verklaart twee gedragingen die op bugs lijken. Een tunnel kan als opgezet verschijnen terwijl op de achtergrond sleutelvernieuwing mislukt, en een CHILD SA kan worden vervangen zonder dat de client de verbinding verliest.

Op strongSwan tonen de IKEv2-configuratiereferentie en swanctl --list-sas beide niveaus, en ip xfrm state plus ip xfrm policy tonen wat de kernel werkelijk heeft geïnstalleerd. Die twee weergaven vergelijken is de snelste manier om te zien of de onderhandeling klaar was of alleen klaar leek. Als de daemon een CHILD SA noemt waarvoor de kernel geen toestand heeft, is de installatie stilletjes mislukt. Als de kernel toestand houdt die de daemon niet kent, kijk je naar een restant van een eerdere poging.

Wat daarna nog waar moet zijn, met de tunnel omhoog

Verkeersselectoren bepalen welke adressen gedekt zijn. Als de client één subnet voorstelt en de server een ander verwacht, wordt de CHILD SA geïnstalleerd maar draagt hij niets nuttigs, en de fout verschijnt als een routeringsprobleem en niet als een onderhandelingsprobleem. Dan moet de lokale stack meewerken: doorsturen aan waar de host routeert, routes naar de tunnel, firewallregels die de gedecapsuleerde pakketten toestaan, en een interne resolver als er private namen in het spel zijn. Elk daarvan faalt apart en geen ervan wordt gerepareerd door de IKE-daemon te herstarten.

Houd de log zichtbaar tijdens het diagnosticeren: de eerste uitwisseling, dan identiteitsvalidatie, dan gebruikersauthenticatie waar van toepassing, dan CHILD-installatie en ten slotte applicatieverkeer. De fase die stopt is de fase om te repareren, en een latere routeringsfout is nooit reden om de identiteitscontroles te versoepelen die al geslaagd zijn.