ESP dešifruje v pořádku a vnitřní paket přesto nikam nedojde
Počítadla ESP rostou, ale aplikace nic nevidí. Následující hlavička v traileru musí odpovídat vnitřnímu paketu, což je jiná závada než minulý selektor.
Počítadlo příjmu ESP roste, tunel zůstává nahoru a aplikace paket nikdy neuvidí. Dešifrování proběhlo, ověření integrity prošlo a pak musel příjemce rozhodnout, co chráněný obsah vlastně je. Právě v tomto posledním kroku se objeví nesoulad formátu a zvenčí to vůbec nevypadá jako problém firewallu.
Co uvidíte, když štítek lže
Nic v protokolu klienta to neodliší od černé díry ve směrování. Obojí vytvoří časový limit aplikace vedle zdravého tunelu, a proto jsou první na vině počítadla.
Rostoucí počítadlo příjmu je opravdu dobrá zpráva: pakety přicházejí a procházejí autentizací. Není to důkaz, že vnitřní paket dával smysl něčemu nad kryptografickou vrstvou.
Typ bydlí v traileru
V běžném tunelovém režimu IPsec obsahuje obsah chráněný protokolem ESP úplný vnitřní IP paket. Pole následující hlavičky v traileru určuje, co tento obsah je, a není to port TCP, není to číslo protokolu ve vnější hlavičce a není to součást počátečního pole SPI a čísla sekvence. RFC 4303 oddíl 2.6 jej definuje jako pole typu obsahu, což je přesné jméno pro přesnou práci.
Hodnoty, se kterými se setkáte, jsou malé a stojí za zapamatování: IPv4 je 4 (0x04) a IPv6 je 41 (0x29).
Tato čísla pocházejí z přiřazení čísel protokolů IANA, nikoli z místní konvence. Odesílatel, který deklaruje IPv4, a přitom obaluje paket IPv6, vytvořil nesoulad formátu, a žádné pravidlo firewallu neopraví bajty, které odporují vlastnímu štítku.
Jak to odlišit od obvyklých podezřelých
Většina chybějících paketů nejsou vady kódování. Nejprve zkontrolujte selektory, protože selektor provozu, který vylučuje prefix IPv6, zahodí provoz dřív, než se cokoli zapouzdří. Potom zkontrolujte směrování a poté místní filtrování na přijímajícím hostiteli. Teprve když jsou tyto možnosti vyloučeny, stává se nesoulad formátu obsahu věrohodným vysvětlením.
Šifrovaný odchyt to nerozhodne, protože chráněná následující hlavička je uvnitř šifrovaného obsahu. Potřebujete diagnostiku implementace nebo podporovaný pozorovací bod po dešifrování a obojí vyžaduje před použitím oprávnění.
Pokud nikdo takový důkaz nepředloží, nemáte chybu formátu. Máte teorii a selektory zůstávají lepší sázkou.
Čím oprava není
Nevypínejte kontroly integrity, aby provoz prošel. Nepřepisujte šifrované pakety na mezilehlém routeru, protože to nemůže fungovat a poškodí tok, přičemž v odchytu to vypadá užitečně. Neotvírejte širší pravidlo firewallu pro aplikaci na základě teorie, že je blokován port. Nic z toho se nesouladu štítku netýká.
Pokud potvrzený nesoulad pochází z implementace protějšku, uchovejte minimální vyčištěnou reprodukci a přineste ji do podporovaného kanálu této implementace.
Ověřte tok, ne počítadlo
Po opravě otestujte skutečný tok IPv6 od začátku do konce: požadavek aplikace tunelem, jeho odpověď a dvojici adres, kterou pozoruje každá strana. Rostoucí počítadlo ESP dokazuje jen to, že pakety jsou přijímány a autentizovány. Nic neříká o tom, zda byl vnitřní paket použitelný.
Zapište do tiketu oba výsledky. Pohyb počítadla plus fungující tok je oprava; samotný pohyb počítadla je přesně to, co jste měli před začátkem.