Provoz klienta VPN a stav firewallu: vnější a vnitřní tok

Handshake VPN se dokončí, klient dostane adresu a služba za bránou přesto spojení odmítá. Firewall často dělá přesně to, co mu bylo řečeno. Povolil vnější tok tunelu, což je jiný paket než dekapsulované spojení aplikace. Z toho plynou dvě rozhodnutí: který tok povolujete a zda hranice vůbec sleduje stav.

Dokud ty dvě věci neoddělíte, každá změna pravidla je odhad.

Firewall vidí dva různé pakety

Před dekapsulací firewall vidí provoz adresovaný koncovému bodu VPN: vnější tok UDP k naslouchači. Po dekapsulaci přeposílaný paket nese vnitřní adresu klienta a cíl služby.

Povolení vnějšího toku neopravňuje přeposílané spojení TCP. Mohou se vyhodnocovat v různých řetězcích, proti různým rozhraním a s různými adresami po překladu.

Porovnejte zachytávání z rovnocenných pozic na obou stranách. Zachytávání na okraji tunelu a zachytávání na serveru ukazují různé tuply pro stejnou relaci.

První rozhodnutí: povolit tunel, nebo službu

Pokud klient potřebuje jen koncový bod VPN, vnější povolení může stačit. Pokud potřebuje službu za bránou, potřebujete povolení přeposílání pro daný cíl a port. Pravidlo tunelu, které povoluje i službu, je návrhové rozhodnutí, které je třeba pojmenovat, ne náhoda.

Udržujte rozsah klienta a rozsah služby úzké. Povolení z podsítě tunelu do celé místní sítě je rozhodnutí věřit každému hostiteli, ne zkratka pro jednu aplikaci.

Zapište obě pravidla zvlášť. Pravidlo tunelu a pravidlo služby selhávají různě a ladí se různými důkazy. Když jedno selže, víte, kterou vrstvu prozkoumat první.

Druhé rozhodnutí: se stavem, nebo bez stavu na každé hranici

Pravidlo navázaného toku může propustit odpovědi pro povolenou výměnu, ale jeho chování závisí na produktu. Cloudová bezpečnostní skupina obvykle stav sleduje; seznam pro řízení přístupu k podsíti často stav nesleduje a vyžaduje explicitní obsluhu v obou směrech. Nepředpokládejte, že každá hranice na cestě přistupuje ke stavu stejně. Vyjmenujte každou hranici a označte ji se stavem, nebo bez stavu, než pravidla navrhnete.

Pokud se pravidlo změní, existující sledované toky mohou dál fungovat, zatímco nové selhávají, nebo naopak. Ten rozdíl je užitečná stopa, ne důvod vyprázdnit veškerý stav spojení na živé bráně.

Testujte novým řízeným požadavkem a prohlédněte příslušné čítače. Čistý test je lepší než rušivý reset. Zapište název čítače do záznamu o změně, aby další test použil stejné důkazy.

Ověřte zpáteční cestu za stejné politiky

Pošlete nový požadavek z klienta na službu a pak zkontrolujte čítače přeposílání a návratu na každé hranici. Potvrďte, že odpověď používá cestu, kterou očekáváte, zvlášť pokud je zapojen překlad.

Udržujte zamýšlený rozsah klienta a rozsah služby úzké a ověřte zpáteční cestu za stejné sady pravidel, která požadavek povolila. Pravidlo, které funguje jen proto, že starý tok je stále otevřený, není funkční pravidlo.