Skille IKEv2-fragmentering fra et problem med sertifikatkjeden

Tunnelen fungerte på kontornettet og stopper hjemme, og loggen viser at den første utvekslingen fullføres før noe annet skjer. Dette mønsteret peker på autentiseringsutvekslingen, ikke på påloggingsinformasjon: en sertifikatkjede gjør den meldingen mye større enn den forrige, og en vei som ikke liker store datagrammer, slipper den stille. To ulike fragmenteringsmekanismer er involvert, og å vite hvilken du ser på avgjør rettelsen.

To fragmenteringsmekanismer, ett symptom

IKEv2 har sin egen fragmenteringsutvidelse, definert i RFC 7383, som deler beskyttede IKE-meldinger i mindre IKE-meldinger. Partene forhandler om denne egenskapen, og en melding settes sammen igjen av IKE-implementasjonen i stedet for av IP-laget.

Vanlig IP-fragmentering er en annen mekanisme med en annen feilmodus. En ruter mellom partene fragmenterer et stort datagram, eller slipper det og returnerer en ICMP-melding som kanskje aldri når avsenderen. Noen nettverk forkaster fragmenter stille, og noen mellomledd håndterer det første fragmentet, men ikke resten. Fra applikasjonens synspunkt ser alle tre tilfellene like ut.

NAT-gjennomtrengning legger til en tredje variabel, fordi ESP da pakkes inn i UDP og den ytre pakken blir større mens den ser ut som vanlig UDP-trafikk på port 4500. En vei som slipper UDP godt gjennom, kan likevel feile på et datagram som ikke lenger passer.

Les utvekslingen som feilet

Se etter overgangen i stedet for feilen. En logg som viser at den første utvekslingen ble sendt og besvart, og deretter ingenting, forteller deg at den neste meldingen aldri ble fullført. Øk loggnivået midlertidig og sammenlign de rapporterte størrelsene på begge parter.

Det du vil fastslå, er om svareren så forespørselen i det hele tatt. Hvis initiativtakeren sendte noe og svareren ikke har noen registrering av det, er problemet levering. Hvis svareren analyserte en forespørsel og avviste den, er sertifikatet selv problemet, og fragmentering er en avledning. Den forskjellen er verdt mer enn en side med tidsavbruddsmeldinger.

Endre veien, ikke sertifikatet

Test den samme klienten, det samme sertifikatet og den samme konfigurasjonen fra et annet nettverk. Et mobilt hotspot er vanligvis den billigste andre veien, og det er virkelig forskjellig fra kontorforbindelsen, ikke bare nominelt.

Hvis håndtrykket fullføres på den andre veien, er sertifikatkjeden i orden og den første veien er variabelen. Hvis det feiler identisk på begge, slutt å teste nettverk og se på meldingene selv. Den ene sammenligningen fjerner omtrent halvparten av de mulige forklaringene.

Mål utvekslingen før du endrer noe

Skaff størrelsen på kjeden og størrelsen på veien. Begge tallene begrenser hva håndtrykket kan sende, og begge er billige å 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 to første gir antall sertifikater og filstørrelsen, som er en rimelig indikator på hvor stor autentiseringsmeldingen blir. Ping-proben rapporterer om et datagram av den størrelsen overlever veien, og grensesnittstellerne viser om fragmenter ble forkastet på din side. På Windows er den tilsvarende proben en ping med do-not-fragment-flagget og en eksplisitt nyttelaststørrelse.

Gjenta proben nedover til den lykkes. Den største størrelsen som passerer, er arbeidsbudsjettet for den veien, og det er nyttigere enn noen publisert standardverdi.

Reparer laget som faktisk er ødelagt

Hvis veien forkaster store datagrammer, aktiver IKE-fragmentering på begge parter og bekreft at utvidelsen ble forhandlet, ikke bare tilbudt. Hvis veien håndterer fragmenter dårlig på IP-nivå, hører rettelsen hjemme der eller i MTU-en til det ytre grensesnittet, ikke i sertifikatlageret.

Hvis kjeden er unødvendig lang, kutt den ned til mellomliggende sertifikater som en part faktisk trenger. Å fjerne en rot som klienten allerede stoler på, er rimelig vedlikehold; å fjerne et mellomliggende er det ikke, og å slå av verifisering for å krympe en melding bytter et leveringsproblem mot et sikkerhetsproblem.

Skriv ned hvilken mekanisme du endret og hvordan håndtrykket så ut etterpå. Neste forekomst er vanligvis på et annet nettverk med det samme symptomet, og notatet er det som gjør to timer til ti minutter.