Skeln IKEv2-fragmentering fra et problem med certifikatkæden

Tunnelen virkede på kontornettet og går i stå derhjemme, og loggen viser, at den første udveksling fuldføres, før noget andet sker. Det mønster peger på godkendelsesudvekslingen, ikke på legitimationsoplysninger: en certifikatkæde gør den meddelelse meget større end den foregående, og en vej, der ikke kan lide store datagrammer, dropper den lydløst. Der er to forskellige fragmenteringsmekanismer involveret, og viden om, hvilken du ser på, afgør rettelsen.

To fragmenteringsmekanismer, ét symptom

IKEv2 har sin egen fragmenteringsudvidelse, defineret i RFC 7383, som deler beskyttede IKE-meddelelser op i mindre IKE-meddelelser. Parterne forhandler denne egenskab, og en meddelelse samles igen af IKE-implementeringen i stedet for af IP-laget.

Almindelig IP-fragmentering er en anden mekanisme med en anden fejltilstand. En router mellem parterne fragmenterer et stort datagram eller dropper det og returnerer en ICMP-meddelelse, som måske aldrig når afsenderen. Nogle netværk kasserer fragmenter lydløst, og nogle mellemled håndterer det første fragment, men ikke resten. Fra applikationens synspunkt ser alle tre tilfælde ens ud.

NAT-gennemføring tilføjer en tredje variabel, fordi ESP så pakkes ind i UDP, og den ydre pakke bliver større, mens den ser ud som almindelig UDP-trafik på port 4500. En vej, der sagtens tillader UDP, kan stadig fejle på et datagram, der ikke længere passer.

Læs den udveksling, der mislykkedes

Se efter overgangen i stedet for fejlen. En log, der viser den indledende udveksling sendt og besvaret, efterfulgt af intet, fortæller dig, at den næste meddelelse aldrig blev færdig. Hæv logniveauet midlertidigt, og sammenlign de rapporterede størrelser på begge parter.

Det, du vil fastslå, er, om svareren overhovedet så anmodningen. Hvis initiativtageren sendte noget, og svareren ikke har nogen registrering af det, er problemet levering. Hvis svareren parsede en anmodning og afviste den, er certifikatet selv problemet, og fragmentering er en afledning. Den forskel er mere værd end en side med timeout-meddelelser.

Skift vejen, ikke certifikatet

Test den samme klient, det samme certifikat og den samme konfiguration fra et andet netværk. Et mobilt hotspot er normalt den billigste anden vej, og det er virkelig anderledes end kontorforbindelsen, ikke kun nominelt.

Hvis håndtrykket fuldføres på den anden vej, er certifikatkæden i orden, og den første vej er variablen. Hvis det fejler identisk på begge, stop med at teste netværk og se på selve meddelelserne. Den ene sammenligning fjerner omkring halvdelen af de mulige forklaringer.

Mål udvekslingen, før du redigerer noget

Find størrelsen på kæden og størrelsen på vejen. Begge tal begrænser, hvad håndtrykket kan sende, og begge er billige at 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'

De første to giver antallet af certifikater og filstørrelsen, hvilket er en rimelig indikator for, hvor stor godkendelsesmeddelelsen bliver. Ping-proben rapporterer, om et datagram af den størrelse overlever vejen, og grænsefladetællerne viser, om fragmenter blev droppet i din ende. På Windows er den tilsvarende probe en ping med do-not-fragment-flaget og en eksplicit nyttelaststørrelse.

Gentag proben nedad, indtil den lykkes. Den største størrelse, der passerer, er arbejdsbudgettet for den vej og er mere nyttig end nogen offentliggjort standardværdi.

Ret det lag, der faktisk er brudt

Hvis vejen dropper store datagrammer, skal du aktivere IKE-fragmentering på begge parter og bekræfte, at udvidelsen blev forhandlet, ikke blot tilbudt. Hvis vejen håndterer fragmenter dårligt på IP-niveau, hører rettelsen der eller i MTU’en på den ydre grænseflade, ikke i certifikatlageret.

Hvis kæden er unødvendigt lang, skær den ned til de mellemliggende certifikater, som en part faktisk har brug for. At fjerne en rod, som klienten allerede stoler på, er rimelig vedligeholdelse; at fjerne et mellemliggende er det ikke, og at deaktivere validering for at krympe en meddelelse bytter et leveringsproblem for et sikkerhedsproblem.

Skriv ned, hvilken mekanisme du ændrede, og hvordan håndtrykket så ud bagefter. Den næste forekomst er normalt på et andet netværk med det samme symptom, og noten er det, der gør to timer til ti minutter.