Skilje IKEv2-fragmentering frå eit problem med sertifikatkjeda

Tunnelen fungerte på kontornettet og stoppar heime, og loggen viser at den første utvekslinga blir fullført før noko anna skjer. Dette mønsteret peikar på autentiseringsutvekslinga, ikkje på påloggingsinformasjon: ei sertifikatkjede gjer den meldinga mykje større enn den førre, og ein veg som ikkje likar store datagram, slepp henne stille. To ulike fragmenteringsmekanismar er med, og å vite kva for ein du ser på avgjer rettinga.

To fragmenteringsmekanismar, eitt symptom

IKEv2 har si eiga fragmenteringsutviding, definert i RFC 7383, som deler verna IKE-meldingar i mindre IKE-meldingar. Partane forhandlar om denne eigenskapen, og ei melding blir sett saman igjen av IKE-implementasjonen i staden for av IP-laget.

Vanleg IP-fragmentering er ein annan mekanisme med ein annan feilmodus. Ein ruter mellom partane fragmenterer eit stort datagram, eller slepp det og returnerer ei ICMP-melding som kanskje aldri når avsendarane. Nokre nettverk kastar fragment stille, og nokre mellomledd handterer det første fragmentet, men ikkje resten. Frå applikasjonen sitt synspunkt ser alle tre tilfella like ut.

NAT-gjennomtrenging legg til ein tredje variabel, fordi ESP då blir pakka inn i UDP og den ytre pakken blir større medan han ser ut som vanleg UDP-trafikk på port 4500. Ein veg som slepper UDP godt gjennom, kan likevel feile på eit datagram som ikkje lenger passar.

Les utvekslinga som feila

Sjå etter overgangen i staden for feilen. Ein logg som viser at den første utvekslinga vart send og svara, og deretter ingenting, fortel deg at den neste meldinga aldri vart fullført. Auk loggnivået mellombels og samanlikn dei rapporterte storleikane på begge partane.

Det du vil fastslå, er om svararen såg førespurnaden i det heile. Viss initiativtakaren sende noko og svararen ikkje har noka registering av det, er problemet levering. Viss svararen analyserte ein førespurnad og avviste han, er sertifikatet sjølv problemet, og fragmentering er ei avleiing. Den skilnaden er verdt meir enn ei side med tidsavbrotmeldingar.

Endre vegen, ikkje sertifikatet

Test den same klienten, det same sertifikatet og den same konfigurasjonen frå eit anna nettverk. Eit mobilt hotspot er vanlegvis den billegaste andre vegen, og det er verkeleg annleis enn kontorforbindinga, ikkje berre nominelt.

Viss handtrykket blir fullført på den andre vegen, er sertifikatkjeda i orden og den første vegen er variabelen. Viss det feilar identisk på begge, slutt å teste nettverk og sjå på meldingane sjølve. Den eine samanlikninga fjernar om lag halvparten av dei moglege forklaringane.

Mål utvekslinga før du endrar noko

Skaff storleiken på kjeda og storleiken på vegen. Båe tala avgrensar kva handtrykket kan sende, og båe er billege å måle:

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'

Dei to første gir talet på sertifikat og filstorleiken, som er ein rimeleg indikator på kor stor autentiseringsmeldinga blir. Ping-prova rapporterer om eit datagram av den storleiken overlever vegen, og grensesnittteljarane viser om fragment vart kasta på di side. På Windows er den tilsvarande prova ein ping med do-not-fragment-flagg og ein eksplisitt nyttelaststorleik.

Gjenta prova nedover til ho lykkast. Den største storleiken som passerer, er arbeidsbudsjettet for den vegen, og det er nyttigare enn nokon publisert standardverdi.

Reparer laget som faktisk er øydelagt

Viss vegen kastar store datagram, slå på IKE-fragmentering på båe partar og stadfest at utvidinga vart forhandla, ikkje berre tilboden. Viss vegen handterer fragment dårleg på IP-nivå, høyrer rettinga heime der eller i MTU-en til det ytre grensesnittet, ikkje i sertifikatlagret.

Viss kjeda er unødvendig lang, kutt ho ned til mellomliggjande sertifikat som ein part faktisk treng. Å fjerne ei rot som klienten allereie stolar på, er rimeleg vedlikehald; å fjerne eit mellomliggjande er det ikkje, og å slå av verifisering for å krympe ei melding byter eit leveringsproblem mot eit tryggleiksproblem.

Skriv ned kva mekanisme du endra og korleis handtrykket såg ut etterpå. Neste førekomst er vanlegvis på eit anna nettverk med det same symptomet, og notatet er det som gjer to timar til ti minutt.