VPN mezi lokalitami: který směr vlastně potřebuje pravidlo?

Oba konce hlásí navázaný tunel, vzdálená pobočka odpovídá z brány a aplikace přesto uživatelům na jedné straně vyprší. Běžná rada říká přidat pravidlo firewallu v obou směrech. Někdy je to správně, někdy tím duplikujete již existující pravidlo a někdy stav rozbíjí právě druhé pravidlo. Který případ platí, závisí na tom, kde firewall paket vidí.

Stavový zpětný provoz mění počet

Stavový firewall zaznamená požadavek a propustí odpověď bez druhého pravidla, takže návrh, kterému stačí jedno pravidlo, je normální. Bezstavový přístupový seznam takovou paměť nemá a odpověď musí být povolena výslovně. Oba jsou správné na své platformě, a proto si rady odporují.

Přečtěte si dokumentaci k předávání pro platformu, kterou máte před sebou, a zkontrolujte, zda je zásada, kterou upravujete, stavová tam, kde paket vidí. Výslovné zamítnutí navázaného provozu nebo pořadí pravidel, které vyhodnocuje odpověď dříve než tabulku stavů, mění funkční návrh v záhadný. Počet pravidel je implementační detail, kdežto požadavkem je, aby se oba směry povolené konverzace mohly dokončit.

Kde firewall vidí dešifrované pakety

V tunelu založeném na zásadách může firewall vyhodnotit šifrovaný paket před dešifrováním a dešifrovaný paket poté, na různých rozhraních. Pravidlo napsané pro špatné rozhraní je přítomné, správné a nikdy se neshoduje. Tak může sada pravidel zkopírovaná z funkčního nasazení selhat na identickém hardwaru.

IPsec založený na směrování a většina moderních implementací nabízejí tunelové rozhraní, takže dešifrovaný paket dorazí tam a platí běžná pravidla rozhraní. Potvrďte, který model nasazení používá, než zkopírujete sadu pravidel z příručky psané pro ten druhý. Tunelové rozhraní je také místo, kam se podívat, když potřebujete vědět, zda byl paket vůbec dešifrován.

Asymetrické směrování boří předpoklad

Stavový firewall předpokládá, že vidí obě poloviny konverzace. Vrátí-li se odpověď přes jinou bránu, toto zařízení nemá pro požadavek stav a zahodí ji podle vlastní zásady. Symptomem je jednosměrné selhání, které žádné pravidlo na odesílající straně nenapraví. Vystopujte cestu odpovědi než cokoli upravíte.

Zkontrolujte trasu odpovědi, než na obou stranách přidáte široké povolovací pravidlo. Tolerovat vše na každém rozhraní skrývá chybu směrování a zároveň rozšiřuje přístup, což je nejhorší dostupná kombinace.

Ověřte oba směry se skutečnými zdrojovými adresami

Testujte s adresou, kterou vzdálená strana skutečně vidí, protože překlad může způsobit, že zdrojové pravidlo neodpovídá ničemu. Spusťte zachytávání na obou branách současně.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Požadavek, který se na vzdálené bráně objeví s neočekávanou zdrojovou adresou, vysvětluje pravidlo, které se nikdy neshoduje, a odpověď přicházející na špatné rozhraní vysvětluje nesoulad stavu. Potom otestujte jeden cíl uvnitř schváleného rozsahu a jeden mimo něj, aby byla hranice předvedena, ne předpokládána.

Zaznamenejte zdrojovou adresu po překladu, rozhraní, které dešifrovaný paket použil, a pravidlo, které se shodovalo. Tyto tři údaje odpovídají na další tiket bez opakování celého vyšetřování.