ESP deshifron mirë dhe paketa e brendshme prapë nuk shkon askund
Numëruesit ESP rriten ndërsa aplikacioni nuk sheh asgjë. Header-i tjetër në trailer duhet të përputhet me paketën e brendshme, një defekt tjetër nga një selektor i humbur.
Numëruesi i marrjes ESP rritet, tuneli mbetet lart, dhe aplikacioni nuk e sheh kurrë paketën. Deshifrimi u ekzekutua, verifikimi i integritetit kaloi, dhe pastaj marrësi duhej të vendoste çfarë është në të vërtetë ngarkesa e mbrojtur. Pikërisht në atë hap të fundit shfaqet një mospërputhje formati, dhe nga jashtë nuk duket aspak si problem i firewall-it.
Çfarë shihni kur etiketa gënjen
Asgjë në regjistrin e klientit nuk e dallon këtë nga një vrimë e zezë rrugëtimi. Të dyja prodhojnë një skadim kohe të aplikacionit pranë një tuneli të shëndoshë, prandaj numëruesit fajësohen të parët.
Një numërues marrjeje në rritje është vërtet lajm i mirë: paketat mbërrijnë dhe autentifikohen. Nuk është provë që paketa e brendshme kishte kuptim për diçka mbi shtresën kriptografike.
Tipi banon në trailer
Në modalitetin e zakonshëm të tunelit IPsec, ngarkesa e mbrojtur nga ESP përmban një paketë të plotë IP të brendshme. Fusha e header-it tjetër në trailer përcakton çfarë është ajo ngarkesë, dhe ajo nuk është një portë TCP, nuk është numër protokolli në header-in e jashtëm dhe nuk është pjesë e fushës fillestare SPI dhe numrit të sekuencës. RFC 4303 seksioni 2.6 e përcakton si fushë e tipit të ngarkesës, që është emër i saktë për një punë të saktë.
Vlerat që do të takoni janë të vogla dhe ia vlen t'i mbani mend: IPv4 është 4 (0x04) dhe IPv6 është 41 (0x29).
Ato numra vijnë nga caktimet e numrave të protokollit të IANA dhe jo nga konventa vendore. Një dërgues që deklaron IPv4 ndërsa mbështjell një paketë IPv6 ka krijuar një mospërputhje formati, dhe asnjë rregull firewall nuk i rregullon bajtët që kundërshtojnë etiketën e tyre.
Si ta dalloni nga të dyshuarit e zakonshëm
Shumica e paketave që mungojnë nuk janë defekte kodimi. Kontrolloni fillimisht selektorët, sepse një selektor trafiku që përjashton prefiksin IPv6 hedh poshtë trafikun para se çdo gjë të inkapsulohet. Pastaj kontrolloni rrugëtimin, dhe më pas filtrimin vendor në hostin marrës. Vetëm pasi këto përjashtohen, mospërputhja e formatit të ngarkesës bëhet shpjegim i besueshëm.
Një kapje e kriptuar nuk do ta zgjidhë, sepse header-i tjetër i mbrojtur ndodhet brenda ngarkesës së kriptuar. Ju nevojitet diagnostikim i implementimit ose një pikë vëzhgimi e deshifruar e mbështetur, dhe të dyja kërkojnë autorizim para përdorimit.
Nëse askush nuk mund ta japë atë provë, nuk keni defekt formati. Keni një teori, dhe selektorët mbeten basti më i mirë.
Çfarë nuk është riparimi
Mos i çaktivizoni kontrollet e integritetit që trafiku të kalojë. Mos i rishkruani paketat e kriptuara në një router të ndërmjetëm, sepse kjo nuk mund të funksionojë dhe do të prishë rrjedhën ndërsa në një kapje duket e dobishme. Mos hapni një rregull firewall aplikacioni më të gjerë mbi teorinë se një port po bllokohet. Asnjëra prej tyre nuk prek mospërputhjen e etiketës.
Nëse një mospërputhje e konfirmuar vjen nga një implementim homolog, mbani një riprodhim minimal të pastruar dhe çojeni në kanalin e mbështetur të atij implementimi.
Verifikoni rrjedhën, jo numëruesin
Pas korrigjimit, provoni rrjedhën reale IPv6 nga fillimi në fund: një kërkesë aplikacioni përmes tunelit, përgjigja e saj, dhe çifti i adresave që vëzhgon secila anë. Një numërues ESP në rritje provon vetëm se paketat po merren dhe autentifikohen. Nuk thotë asgjë për atë nëse paketa e brendshme ishte e përdorshme.
Regjistroni të dyja rezultatet në tiketë. Lëvizja e numëruesit plus një rrjedhë që funksionon është riparim; lëvizja e numëruesit vetëm është pikërisht ajo që kishit para se të fillonit.