Të dallosh fragmentimin e IKEv2 nga një problem i zinxhirit të certifikatave

Tuneli funksiononte në rrjetin e zyrës dhe ngec në shtëpi, dhe regjistri tregon se shkëmbimi i parë përfundon përpara se të ndodhë diçka tjetër. Ky model tregon shkëmbimin e vërtetimit, jo kredencialet: një zinxhir certifikatash e bën atë mesazh shumë më të madh sesa ai i mëparshmi, dhe një rrugë që nuk i do datagramet e mëdha do ta hedhë atë në heshtje. Janë të përfshira dy mekanizma të ndryshëm fragmentimi, dhe të dish se cilin po shikon vendos rregullimin.

Dy mekanizma fragmentimi, një simptom

IKEv2 ka shtrirjen e vet të fragmentimit, të përcaktuar në RFC 7383, e cila i ndan mesazhet e mbrojtura IKE në mesazhe IKE më të vogla. Palët negociojnë për atë aftësi, dhe mesazhi rrimontohet nga zbatimi i IKE dhe jo nga shtresa IP.

Fragmentimi i zakonshëm IP është një mekanizëm tjetër me një mënyrë tjetër dështimi. Një ruter midis palëve fragmenton një datagram të madh, ose e hedh dhe kthen një mesazh ICMP që mund të mos arrijë kurrë te dërguesi. Disa rrjete i hedhin fragmentet në heshtje, dhe disa pajisje të ndërmjetme trajtojnë fragmentin e parë por jo pjesën tjetër. Nga këndvështrimi i aplikacionit, të tre rastet duken njësoj.

Kalimi përmes NAT shton një variabël të tretë, sepse atëherë ESP mbështillet në UDP dhe paketa e jashtme bëhet më e madhe ndërsa duket si trafik normal UDP në portën 4500. Një rrugë që e lejon UDP-në mirë mund të dështojë gjithsesi në një datagram që nuk futet më.

Lexoni shkëmbimin që dështoi

Kërkoni tranzicionin, jo gabimin. Një regjistër që tregon shkëmbimin fillestar të dërguar dhe të përgjigjur, e më pas asgjë, ju thotë se mesazhi tjetër nuk përfundoi kurrë. Ngrini përkohësisht nivelin e regjistrit dhe krahasoni madhësitë e raportuara në të dy palët.

Ajo që doni të vërtetoni është nëse përgjigjësi e pa kërkesën fare. Nëse iniciatori dërgoi diçka dhe përgjigjësi nuk ka asnjë regjistrim për të, problemi është dërgimi. Nëse përgjigjësi e analizoi një kërkesë dhe e refuzoi, problemi është vetë certifikata, dhe fragmentimi është shpërqendrim. Ky dallim vlen më shumë se një faqe mesazhe skadimi.

Ndryshoni rrugën, jo certifikatën

Provoni të njëjtin klient, të njëjtën certifikatë dhe të njëjtin konfigurim nga një rrjet tjetër. Një hotspot celular është zakonisht rruga e dytë më e lirë, dhe është vërtet i ndryshëm nga lidhja e zyrës, jo vetëm nominalisht.

Nëse shtrëngimi i duarve përfundon në rrugën e dytë, zinxhiri i certifikatave është në rregull dhe rruga e parë është variabli. Nëse dështon në mënyrë identike në të dyja, ndaloni testimin e rrjeteve dhe shikoni vetë mesazhet. Ai krahasim i vetëm heq rreth gjysmën e shpjegimeve të mundshme.

Matni shkëmbimin përpara se të redaktoni ndonjë gjë

Merrni madhësinë e zinxhirit dhe madhësinë e rrugës. Të dy numrat kufizojnë atë që mund të dërgojë shtrëngimi i duarve, dhe të dy maten lirë:

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'

Dy të parët japin numrin e certifikatave dhe madhësinë e skedarit, që është një tregues i arsyeshëm për sa e madhe do të jetë mesazhi i vërtetimit. Sonda ping raporton nëse një datagram i asaj madhësie i mbijeton rrugës, dhe numëruesit e ndërfaqes tregojnë nëse fragmentet u hodhën në anën tuaj. Në Windows, sonda ekuivalente është një ping me flamurin do-not-fragment dhe një madhësi eksplicite e ngarkesës.

Përsëriteni sondën poshtë derisa të ketë sukses. Madhësia më e madhe që kalon është buxheti i punës për atë rrugë, dhe është më i dobishëm se çdo vlerë e paracaktuar e publikuar.

Rregulloni shtresën që është vërtet e prishur

Nëse rruga i hedh datagramet e mëdha, aktivizoni fragmentimin IKE në të dy palët dhe konfirmoni që shtrirja u negociua dhe nuk u ofrua thjesht. Nëse rruga i trajton keq fragmentet në nivel IP, rregullimi i takon asaj rruge ose MTU-së së ndërfaqes së jashtme, jo magazinës së certifikatave.

Nëse zinxhiri është pa nevojë i gjatë, shkurtojeni deri te certifikatat e ndërmjetme që një palë i nevojiten vërtet. Heqja e një rrënje në të cilën klienti tashmë beson është mirëmbajtje e arsyeshme; heqja e një certifikate të ndërmjetme nuk është, dhe çaktivizimi i verifikimit për të zvogëluar një mesazh shkëmben një problem dërgimi me një problem sigurie.

Shkruani cilin mekanizëm ndryshuat dhe si dukej shtrëngimi i duarve më pas. Ndodhja tjetër është zakonisht në një rrjet tjetër me të njëjtin simptom, dhe shënimi është ai që kthen dy orë në dhjetë minuta.