IKEv2-fragmentatie onderscheiden van een certificaatkettingprobleem

De tunnel werkte op het kantoornetwerk en blijft thuis hangen, en het log toont dat de eerste uitwisseling voltooid is voordat er iets anders gebeurt. Dat patroon wijst op de authenticatie-uitwisseling, niet op inloggegevens: een certificaatketting maakt dat bericht veel groter dan het vorige, en een pad dat niet van grote datagrammen houdt, laat het stil vallen. Er zijn twee verschillende fragmentatiemechanismen in het spel, en weten welke u bekijkt bepaalt de oplossing.

Twee fragmentatiemechanismen, één symptoom

IKEv2 heeft zijn eigen fragmentatie-uitbreiding, gedefinieerd in RFC 7383, die beveiligde IKE-berichten opsplitst in kleinere IKE-berichten. De peers onderhandelen over die mogelijkheid, en een bericht wordt door de IKE-implementatie weer samengesteld en niet door de IP-laag.

Gewone IP-fragmentatie is een ander mechanisme met een andere faalmodus. Een router tussen de peers fragmenteert een groot datagram, of laat het vallen en stuurt een ICMP-bericht terug dat de afzender misschien nooit bereikt. Sommige netwerken gooien fragmenten stil weg, en sommige tussenliggende apparaten verwerken het eerste fragment maar niet de rest. Vanuit het perspectief van de toepassing zien alle drie de gevallen er hetzelfde uit.

NAT-traversal voegt een derde variabele toe, omdat ESP dan in UDP wordt verpakt en het buitenste pakket groter wordt terwijl het op gewoon UDP-verkeer op poort 4500 lijkt. Een pad dat UDP goed doorlaat, kan alsnog falen op een datagram dat er niet meer in past.

Lees de uitwisseling die mislukte

Zoek de overgang in plaats van de fout. Een log dat de eerste uitwisseling verzonden en beantwoord toont, gevolgd door niets, vertelt u dat het volgende bericht nooit is voltooid. Verhoog tijdelijk het logniveau en vergelijk de gerapporteerde groottes aan beide kanten.

Wat u wilt vaststellen, is of de responder het verzoek überhaupt heeft gezien. Als de initiator iets heeft verzonden en de responder heeft er geen enkele registratie van, is de aflevering het probleem. Als de responder een verzoek heeft geparseerd en het heeft geweigerd, is het certificaat zelf het probleem, en fragmentatie leidt af. Dat onderscheid is meer waard dan een pagina vol time-outmeldingen.

Verander het pad, niet het certificaat

Test dezelfde client, hetzelfde certificaat en dezelfde configuratie vanaf een ander netwerk. Een mobiele hotspot is meestal het goedkoopste tweede pad, en het is echt anders dan de kantoorverbinding, niet alleen nominaal.

Als de handshake op het tweede pad voltooid wordt, is de certificaatketting in orde en is het eerste pad de variabele. Als het op beide identiek mislukt, stop dan met netwerken testen en kijk naar de berichten zelf. Die ene vergelijking verwijdert ongeveer de helft van de mogelijke verklaringen.

Meet de uitwisseling voordat u iets bewerkt

Verkrijg de grootte van de ketting en de grootte van het pad. Beide getallen beperken wat de handshake kan verzenden, en beide zijn goedkoop te meten:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

De eerste twee geven het aantal certificaten en de bestandsgrootte, wat een redelijke indicatie is voor hoe groot het authenticatiebericht wordt. De ping-test meldt of een datagram van die grootte het pad overleeft, en de interface-tellers tonen of fragmenten aan uw kant zijn weggegooid. Op Windows is de equivalente test een ping met de do-not-fragment-vlag en een expliciete payloadgrootte.

Herhaal de test neerwaarts totdat het lukt. De grootste grootte die doorkomt is het werkbudget voor dat pad, en het is nuttiger dan enige gepubliceerde standaardwaarde.

Repareer de laag die echt kapot is

Als het pad grote datagrammen laat vallen, schakel dan IKE-fragmentatie in aan beide kanten en bevestig dat de uitbreiding is onderhandeld en niet alleen aangeboden. Als het pad slecht met fragmenten omgaat op IP-niveau, hoort de correctie daar of in de MTU van de buitenste interface, niet in het certificaatarchief.

Als de ketting onnodig lang is, kort hem dan in tot de tussenliggende certificaten die een peer echt nodig heeft. Een root verwijderen die de client al vertrouwt is redelijk onderhoud; een tussenliggend certificaat verwijderen niet, en verificatie uitschakelen om een bericht te verkleinen ruilt een afleveringsprobleem in voor een beveiligingsprobleem.

Schrijf op welk mechanisme u hebt gewijzigd en hoe de handshake er daarna uitzag. De volgende keer is meestal op een ander netwerk met hetzelfde symptoom, en de notitie is wat twee uur in tien minuten verandert.