Skilja IKEv2-fragmentering från ett problem med certifikatkedjan

Tunneln fungerade i kontorsnätet och fastnar hemma, och loggen visar att det första utbytet slutförs innan något annat händer. Mönstret pekar på autentiseringsutbytet, inte på inloggningsuppgifter: en certifikatkedja gör det meddelandet mycket större än det föregående, och en väg som inte gillar stora datagram släpper det tyst. Två olika fragmenteringsmekanismer är inblandade, och att veta vilken du tittar på avgör åtgärden.

Två fragmenteringsmekanismer, ett symptom

IKEv2 har sin egen fragmenteringsutökning, definierad i RFC 7383, som delar skyddade IKE-meddelanden i mindre IKE-meddelanden. Parterna förhandlar om den förmågan, och ett meddelande sätts ihop igen av IKE-implementationen i stället för av IP-lagret.

Vanlig IP-fragmentering är en annan mekanism med ett annat felbeteende. En router mellan parterna fragmenterar ett stort datagram, eller släpper det och skickar tillbaka ett ICMP-meddelande som kanske aldrig når avsändaren. Vissa nätverk kastar fragment tyst, och vissa mellanliggande enheter hanterar det första fragmentet men inte resten. Från applikationens perspektiv ser alla tre fallen likadana ut.

NAT-traversering lägger till en tredje variabel, eftersom ESP då packas in i UDP och det yttre paketet blir större samtidigt som det ser ut som vanlig UDP-trafik på port 4500. En väg som släpper igenom UDP bra kan ändå misslyckas med ett datagram som inte längre får plats.

Läs utbytet som misslyckades

Leta efter övergången i stället för felet. En logg som visar att det första utbytet skickades och besvarades, följt av ingenting, säger att nästa meddelande aldrig slutfördes. Höj loggnivån tillfälligt och jämför de rapporterade storlekarna på båda parter.

Det du vill fastställa är om svararen såg begäran överhuvudtaget. Om initiativtagaren skickade något och svararen inte har någon registrering av det, är problemet leveransen. Om svararen analyserade en begäran och avvisade den, är själva certifikatet problemet, och fragmentering är en avledning. Den skillnaden är värd mer än en sida tidsgränsmeddelanden.

Ändra vägen, inte certifikatet

Testa samma klient, samma certifikat och samma konfiguration från ett annat nätverk. En mobil hotspot är vanligtvis den billigaste andra vägen, och den är verkligen annorlunda än kontorslänken, inte bara nominellt.

Om handskakningen slutförs på den andra vägen är certifikatkedjan i ordning och den första vägen är variabeln. Om den misslyckas identiskt på båda, sluta testa nätverk och titta på meddelandena själva. Den enda jämförelsen tar bort ungefär hälften av de möjliga förklaringarna.

Mät utbytet innan du ändrar något

Hämta storleken på kedjan och storleken på vägen. Båda talen begränsar vad handskakningen kan skicka, och båda är billiga att mäta:

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 två första ger antalet certifikat och filstorleken, vilket är en rimlig indikator på hur stort autentiseringsmeddelandet blir. Ping-provet rapporterar om ett datagram av den storleken överlever vägen, och gränssnittsräknarna visar om fragment kastades på din sida. I Windows är motsvarande prov en ping med do-not-fragment-flaggan och en explicit nyttolaststorlek.

Upprepa provet nedåt tills det lyckas. Den största storleken som passerar är arbetsbudgeten för den vägen, och den är användbarare än något publicerat standardvärde.

Reparera lagret som faktiskt är trasigt

Om vägen kastar stora datagram, aktivera IKE-fragmentering på båda parter och bekräfta att utökningen förhandlades och inte bara erbjöds. Om vägen hanterar fragment dåligt på IP-nivå hör rättelsen dit eller till MTU:n för det yttre gränssnittet, inte till certifikatarkivet.

Om kedjan är onödigt lång, korta den till de mellanliggande certifikat som en part faktiskt behöver. Att ta bort en rot som klienten redan litar på är rimligt underhåll; att ta bort ett mellanliggande är det inte, och att stänga av verifiering för att krympa ett meddelande byter ett leveransproblem mot ett säkerhetsproblem.

Skriv ner vilken mekanism du ändrade och hur handskakningen såg ut efteråt. Nästa förekomst är vanligtvis i ett annat nätverk med samma symptom, och anteckningen är det som gör två timmar till tio minuter.