ESP entschlësselt gutt an de bannenzege Paket kënnt trotzdeem néierens un
D'ESP-Zähler klammen, während d'App näischt gesäit. Den nächsten Header am Trailer muss zum bannenzege Paket passen, en anere Feeler wéi en verfeelte Selektoren.
Den ESP-Empfangszähler klëmmt, den Tunnel bleift uewen, an d'Applikatioun gesäit de Paket ni. D'Entschlësselung ass gelaf, d'Integritéitspréiwung huet duerchgaang, an duerno huet de Empfänger misse decidéieren, wat de geschützte Payload eigentlech ass. Genau an deem leschte Schrëtt erschéngt eng Format-Onstëmmegkeet, a vun dobaussen gesäit dat guer net wéi e Firewallproblem aus.
Wat Dir gesitt, wann d'Etikett lügt
Näischt am Client-Log ënnerscheet dat vun engem Routing-Schwaarze Lach. Béid produzéieren en Applikatiouns-Timeout nieft engem gesonden Tunnel, dofir kréien d'Zähler als éischt d'Schold.
En klammenden Empfangszähler ass wierklech eng gutt Noriicht: d'Pakete kommen un a ginn authentifizéiert. Et ass awer kee Beweis, datt de bannenzege Paket fir eppes iwwer der Kryptoschicht Sënn gemaach huet.
Den Typ wunnt am Trailer
Am gewéinlechen IPsec-Tunnelmodus enthält de vum ESP geschützte Payload e komplett bannenent IP-Paket. D'Feld vum nächsten Header am Trailer bestëmmt, wat dëse Payload ass, an et ass keen TCP-Port, keng Protokollnummer am baussenzege Header an och keen Deel vum ufängleche SPI- a Sequenznummerfeld. RFC 4303 Sektioun 2.6 definéiert en als Payload-Typ-Feld, wat en prezisen Numm fir eng precis Aufgab ass.
D'Vale, déi Dir begéint, si kleng an et lount sech, se ze merken: IPv4 ass 4 (0x04) an IPv6 ass 41 (0x29).
Dës Zuelen kommen aus den IANA-Protokollnummer-Zoudeelungen an net aus enger lokaler Konventioun. En Absender, deen IPv4 deklaréiert a gläichzäiteg en IPv6-Paket ëmschléisst, huet eng Format-Onstëmmegkeet produzéiert, a keng Firewallregel reparéiert Byten, déi hirem eegenen Etikett widerspriechen.
Wéi een et vun de gewéinleche Verdächtegen ënnerscheet
Déi meescht fehlend Pakete sinn keng Kodéierungsfeeler. Préift als éischt d'Selektoren, well en Trafikselektor, deen de IPv6-Prefix ausschléisst, de Trafik verwërft, ier eppes encapsuléiert gëtt. Préift dann Routing, duerno lokal Filterung um empfangenden Host. Erscht nodeem dat ausgeschloss ass, gëtt eng Payload-Format-Onstëmmegkeet eng plausibel Erklärung.
En verschlësselte Mitschnëtt entscheet dat net, well den geschützten nächsten Header bannen am verschlësselte Payload sëtzt. Dir braucht Implementéierungsdiagnostik oder en ënnerstëtzten entschlësselten Observatiounspunkt, an allebéid brauche virum Gebrauch eng Autorisatioun.
Wann keen dëse Beweis liwwere kann, hutt Dir kee Formatbug. Dir hutt eng Theorie, an d'Selektoren bleiwen déi besser Wett.
Wat d'Reparatur net ass
Deaktivéiert keng Integritéitspréiwungen, fir den Trafik duerchzekréien. Schreift verschlësselt Paketen net op engem Tëschenrouter ëm, well dat net ka funktionéieren an de Floss beschiedegt, wärend et am Mitschnëtt hëlleft ausgesäit. Maacht keng méi breet Applikatiouns-Firewallregel op mat der Theorie, datt en Port blockéiert ass. Naischt vun deem beréiert d'Etikett-Onstëmmegkeet.
Wann eng bestätegt Onstëmmegkeet vun enger Peer-Implementéierung kënnt, behält eng minimal sanéiert Reproduktioun a bréngt se op den ënnerstëtzten Kanal vun där Implementéierung.
Verifizéiert de Floss, net den Zähler
Test nom Korrektioun de richtegen IPv6-Floss vun Ufank bis Enn: eng Applikatiounsufro duerch den Tunnel, hir Äntwert, an d'Adresspaar, dat all Säit observéiert. En klammenden ESP-Zähler beweist just, datt Pakete empfaange an authentifizéiert ginn. Hie seet näischt doriwwer, ob de bannenzege Paket brauchbar war.
Schreift béid Resultater an den Ticket. Zählerbeweegung plus en funktionéierende Floss ass eng Reparatur; Zählerbeweegung eleng ass genee dat, wat Dir virum Ufank hat.