Ping z brány IPsec používá jinou zdrojovou adresu

Odešlete ping z brány IPsec na vzdálenou stranu, nedostanete odpověď a usoudíte, že tunel je rozbitý, přitom každá úloha za bránou normálně prochází. Tyto dva výsledky si neodporují. Ping spuštěný na bráně je paket s místním zdrojem a brána volí zdrojovou adresu ze své vlastní směrovací tabulky. Tato volba se může lišit od adres, které používá skutečný provoz lokality, což mění, která politika odpovídá a která zpáteční trasa platí. Rozhodněte, co má test dokázat, než z jeho výsledku cokoli vyvodíte.

Tři různé otázky, na které ping může odpovědět

První otázka je, zda je vzdálená strana z tohoto hostitele vůbec dosažitelná. Druhá je, zda selektory tunelu nebo politika založená na trasách propouštějí provoz z určitého zdroje. Třetí je, zda přesměrovaný provoz z úlohy za bránou funguje od konce ke konci. Jeden příkaz nemůže odpovědět na všechny tři a zdrojová adresa je to, co je odděluje.

Nejprve zvolte otázku. Jinak se neúspěšný ping stane důkazem pro teorii, kterou jste už měli.

Proč brána volí adresu, kterou jste nečekali

Když pingujete cíl, místní stack zvolí zdroj z trasy, která k němu odpovídá. Na tunelu založeném na trasách to může být adresa spoje rozhraní tunelu, což je v mnoha návrzích lokality dvojice 169.254.x.x zvolená pro přeskok bod-bod. Tyto adresy existují, aby spoj fungoval; na vzdálené straně se neinzerují jako sítě zdroje aplikací.

Vzdálená strana tak může dostat požadavek na echo z adresy, na kterou nemá zpáteční trasu, nebo z takové, které neodpovídá žádný selektor. Tunel může být zdravý a ping přesto selže, a to je přesně ten falešně negativní výsledek, o kterém je tento článek.

Zvolte zdroj záměrně

Na řízené bráně Linux zvolte zdroj, který je už místně přiřazen: ping -c 4 -I 10.30.0.1 10.40.0.20. Adresy jsou zde ilustrativní, proto dosaďte skutečnou vnitřní adresu brány a skutečný vzdálený cíl a ověřte, že zvolený zdroj patří tomuto zařízení a že ho politika lokality propouští.

Nepůjčujte si pro test adresu úlohy. Vydávání se za hostitele, který není bráně přiřazen, vytváří výsledek, který nikdo nedokáže zopakovat, a na některých stackech selhává tak, že to vypadá jako porucha tunelu.

Čtěte zpáteční cestu, ne jen požadavek

Zkontrolujte, který zdroj skutečně dorazí na vzdálený cíl, včetně případného záměrného překladu na cestě. Poté zkontrolujte zpáteční trasu vzdálené strany k tomuto zdroji a selektory nebo politiku, které ho propouštějí. Požadavek, který dorazí s neočekávaným zdrojem, je otázka směrování a politiky, ne kryptografie.

Právě zde pomůže zachytávání paketů víc než další ping: ukáže zdroj, který vzdálená strana viděla, a to je adresa, které musí její odpověď dosáhnout.

Potom otestujte úlohu

Rozhodující test je ping z běžného hostitele za bránou na běžného hostitele za vzdálenou bránou. Procvičí roli brány při předávání, skutečný zdroj aplikace a skutečnou zpáteční cestu, což je tok, na kterém uživatelům záleží.

Vedte výsledky v poznámkách odděleně: dostupnost z brány, propuštění politiky pro zvolený zdroj a předávaný provoz. Úspěšný připnutý ping je užitečný důkaz, že tunel něco přenáší; není důkazem, že funguje každý předávaný tok. A automaticky zvolený zdroj brány, který není dosažitelný, není důkazem, že je tunel lokality mimo provoz.

Nepřidávejte obecnou trasu pro 169.254.0.0/16 jen proto, abyste dostali jednu diagnostickou odpověď. Vyměníte tím zavádějící test za trvalé rozhodnutí o směrování a další člověk ho zdědí bez kontextu.