Die tonnel het op die kantoornetwerk gewerk en staak by die huis, en die log wys die eerste uitruiling voltooi voordat enigiets anders gebeur. Daardie patroon dui op die verifikasie-uitruiling, nie op geloofsbriewe nie: 'n sertifikaatketting maak daardie boodskap baie groter as die vorige een, en 'n pad wat nie van groot datagramme hou nie, sal dit stilweg laat val. Twee verskillende fragmenteringsmeganismes is betrokke, en om te weet na watter een jy kyk, bepaal die oplossing.

Twee fragmenteringsmeganismes, een simptoom

IKEv2 het sy eie fragmenteringsuitbreiding, gedefinieer in RFC 7383, wat beskermde IKE-boodskappe in kleiner IKE-boodskappe verdeel. Die eweknieë onderhandel daardie vermoë, en 'n boodskap word deur die IKE-implementering herbou eerder as deur die IP-laag.

Gewone IP-fragmentering is 'n ander meganisme met 'n ander falmodus. 'n Roeteerder tussen die eweknieë fragmenteer 'n groot datagram, of laat dit val en stuur 'n ICMP-boodskap terug wat die sender miskien nooit bereik nie. Sommige netwerke verwerp fragmente stilweg, en sommige middelbokse hanteer die eerste fragment maar nie die res nie. Vanuit die toepassing se oogpunt lyk al drie gevalle identies.

NAT-deurgang voeg 'n derde veranderlike by, want ESP word dan in UDP toegedraai en die buitenste pakket word groter terwyl dit soos gewone UDP-verkeer op poort 4500 lyk. 'n Pad wat UDP goed deurlaat, kan steeds misluk op 'n datagram wat nie meer pas nie.

Lees die uitruiling wat misluk het

Soek die oorgang eerder as die fout. 'n Log wat wys die aanvanklike uitruiling is gestuur en beantwoord, gevolg deur niks, vertel jou dat die volgende boodskap nooit voltooi is nie. Verhoog die logvlak tydelik en vergelyk die gerapporteerde groottes op beide eweknieë.

Wat jy wil vasstel, is of die ontvanger die versoek hoegenaamd gesien het. As die inisieerder iets gestuur het en die ontvanger het geen rekord daarvan nie, is aflewering die probleem. As die ontvanger 'n versoek ontleed en verwerp het, is die sertifikaat self die probleem, en fragmentering is 'n afleiding. Daardie onderskeid is meer werd as 'n bladsy vol tydsverstreke boodskappe.

Verander die pad, nie die sertifikaat nie

Toets dieselfde kliënt, dieselfde sertifikaat en dieselfde konfigurasie vanaf 'n ander netwerk. 'n Mobiele hotspot is gewoonlik die goedkoopste tweede pad, en dit is werklik anders as die kantoorverbinding, nie net nominaal nie.

As die handskud op die tweede pad voltooi, is die sertifikaatketting reg en is die eerste pad die veranderlike. As dit identies op albei misluk, stop om netwerke te toets en kyk na die boodskappe self. Daardie enkele vergelyking verwyder omtrent die helfte van die moontlike verklarings.

Meet die uitruiling voordat jy enigiets wysig

Kry die grootte van die ketting en die grootte van die pad. Beide getalle beperk wat die handskud kan stuur, en albei is goedkoop om te meet:

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'

Die eerste twee gee die aantal sertifikate en die lêergrootte, wat 'n redelike aanduiding is van hoe groot die verifikasieboodskap sal wees. Die ping-toets rapporteer of 'n datagram van daardie grootte die pad oorleef, en die koppelvlak-tellers wys of fragmente aan jou kant laat val is. Op Windows is die ekwivalent 'n ping met die do-not-fragment-vlag en 'n eksplisiete loonvragrootte.

Herhaal die toets afwaarts totdat dit slaag. Die grootste grootte wat deurkom, is die werkbare begroting vir daardie pad, en dit is nuttiger as enige gepubliseerde verstekwaarde.

Herstel die laag wat werklik stukkend is

As die pad groot datagramme laat val, aktiveer IKE-fragmentering op beide eweknieë en bevestig dat die uitbreiding onderhandel is, nie bloot aangebied nie. As die pad fragmente sleg op IP-vlak hanteer, hoort die oplossing daar of in die MTU van die buitenste koppelvlak, nie in die sertifikaatstoordery nie.

As die ketting onnodig lank is, sny dit tot die intermediêre sertifikate wat 'n eweknie werklik nodig het. Om 'n wortel te verwyder wat die kliënt reeds vertrou, is redelike huiswerk; om 'n intermediêre een te verwyder is nie, en om verifikasie af te skakel om 'n boodskap te verklein, ruil 'n afleweringsprobleem vir 'n sekuriteitsprobleem.

Skryf neer watter meganisme jy verander het en hoe die handskud daarna gelyk het. Die volgende voorkoms is gewoonlik op 'n ander netwerk met dieselfde simptoom, en die nota is wat twee uur in tien minute verander.

Verwante artikels