Odchozí ESP bez odpovědi neznamená, že je VPN mrtvá
ESP chrání jeden směr na asociaci a nic nepotvrzuje. Srovnejte vnitřní konverzaci a příchozí SA, než server označíte za neodpovídající.
Zachytili jste provoz na hostiteli IPsec, viděli jste odcházet pakety ESP, nic se nevrátilo a uzavřeli jste, že vzdálená strana je rozbitá. Zachycení tento závěr nepodporuje. ESP chrání jeden směr konverzace a na vrstvě IP nic nepotvrzuje, takže chybějící zpětný ESP může stejně snadno znamenat, že aplikace neměla co říct, jako že tunel je mrtvý. Přečtěte si vnitřní výměnu a stav přijímající strany, než obviníte kterýkoli konec.
Mýtus: každý chráněný paket si zaslouží odpověď
ESP není protokol požadavek-odpověď. Šifruje a autentizuje vše, co politika vybere, a příjemce tento vnitřní paket ověří, dešifruje a doručí, aniž by generoval vlastní paket. Dotaz UDP, který cíl ignoruje, nebo echo ICMP, které příchozí politika zahodí, vytvářejí ticho v obou směrech jako správný výsledek. Pokud toto ticho považujete za transportní závadu, vydáte se hledat síťovou chybu, která nikdy neexistovala.
Jednosměrné zachycení ve skutečnosti dokazuje jen to, že zásobník odesílatele v tomto místě pozorování něco zašifroval. Nic o doručení a nic o úmyslu odpovědět. Užitečná otázka není "proč žádná odpověď nepřišla", ale "co měla vnitřní konverzace vytvořit".
Dvě SA, dva SPI, jedna konverzace
Bezpečnostní asociace IPsec jsou jednosměrné, takže běžná chráněná výměna má příchozí a odchozí asociaci s oddělenými identifikátory a nezávislým stavem. Hledat zpětný provoz podle SPI odchozího paketu je proto kategorická chyba, protože každá odpověď putuje pod vlastní odchozí SA protějšku s vlastním SPI. Párujte dvojici podle selektorů provozu a adres protějšku.
Obnova klíčů komplikuje obraz na několik sekund, protože starý a náhradní stav se mohou překrývat. Pokud symptom začal kolem obnovy klíčů, sbírejte identifikátory asociací a časová razítka společně, ne jen název připojení.
Co musí příjemce udělat, než cokoli odpoví
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Každý řádek selhává nezávisle a každé selhání má jiného vlastníka, proto je jedno zachycení nedokáže rozlišit. Příchozí čítač je jediný přímý důkaz doručení, protože paket, který neprojde autentizací nebo kontrolou opakování, se zahodí bez jakékoli odpovědi. Protějšek, jehož příchozí čítač se nepohnul, vám tedy neposílá žádnou informaci o své politice.
Doručení je samostatný krok od dešifrování. Stav může být platný a paket přesto následně zahozen příchozí politikou nebo trasou, která vnitřní cíl neobsahuje, proto ověřte, zda cílový hostitel viděl otevřený text, místo abyste předpokládali, že čistý čítač znamená, že paket šel tam, kam jste chtěli.
Nativní ESP není UDP
Nativní ESP je protokol IP 50, který není ani TCP, ani UDP a nemá vůbec žádné porty. Pravidlo firewallu povolující IKE na UDP 500 proto o datové cestě nic neříká a filtr napsaný kolem portů může nechat tunel vyjednat a pak zahodit vše, co se v něm přenáší. Testujte datovou cestu samostatně, v režimu, který jste skutečně pozorovali.
Za NAT se tvar mění: chráněný užitečný náklad putuje uvnitř UDP, obvykle na portu 4500, jak definuje RFC 3948. Zaznamenejte aktivní režim, než napíšete jakékoli pravidlo, protože zařízení na cestě může nativní ESP a ESP zapouzdřené v UDP ošetřovat zcela odlišně a některé middleboxy jedno povolí a druhé zahodí.
Čtěte čítače, které patří tomuto incidentu
Na hostiteli strongSwan swanctl --list-sas hlásí čítače paketů a bajtů pro každou asociaci v obou směrech, což stačí k oddělení "nikdy nedorazilo" od "dorazilo a nebylo odpovězeno". Na Linuxu /proc/net/xfrm_stat počítá souhrnné poruchy, jako je chybějící stav, chybějící politika a chyby protokolu. Tyto součty se hromadí od spuštění a patří jednomu síťovému jmennému prostoru, takže velké číslo není přiřazení.
Vezměte dvě odečty kolem okna incidentu ve správném jmenném prostoru a porovnejte rozdíly, jinak přilepíte chyby z minulého týdne na dnešní tiket. Uveďte jmenný prostor a obě časová razítka v tiketu, aby další čtenář mohl srovnání zopakovat, místo aby věřil součtu.
Pojmenujte fázi, ne podezřelého
Užitečný závěr říká, kde se paket zastavil: nikdy nepřijat, přijat a zahozen, doručen ale bez odpovědi, nebo odpovězen a ztracen na cestě zpět. Každý z těchto bodů ukazuje na jiného vlastníka a jiný další příkaz. "Žádná odpověď od serveru VPN" slučuje čtyři různé závady do jedné věty, kterou zachycení nikdy neopodstatnilo.
Držte zachycení úzká a držte surový stav jádra mimo tikety, protože může nést klíčový materiál, který nemá co dělat mimo hostitele. Rozdíly čítačů a časová razítka jsou části, které stojí za předání dalšímu člověku.