Po dešifrování: která politika uvidí váš VPN provoz první

VPN tok může být dokonale šifrovaný a dokonale autentizovaný a přesto skončit tam, kde to nikdo neplánoval. Kabel, který zapojíte, neurčuje, které pravidlo zpracuje vnitřní paket; určuje to háček politiky a trasa. Proto dva návrhy, které na schématu racku vypadají stejně, mohou mít zcela odlišné vynucení. Volba mezi nimi začíná pojmenováním kontroly, která vidí dešifrovaný tok první.

Rozhodujte podle háčku politiky, ne podle portu, do kterého zapojujete

Každá platforma VPN vyhodnocuje dešifrovaný provoz v nějakém bodě předtím, než ho přepošle, a ten bod má v konfiguraci jméno. Na jedné platformě je to filtr skupinové politiky, na jiné politika rozhraní nebo dvojice zón a na směrovači to může být prostě řetězec forward. Háček vynucuje pravidlo, zatímco port přepínače je jen místo, kde končí kabel. Nalézt háček je první rozhodnutí, protože vše ostatní je umístění vůči němu.

Než se podíváte na hardware, zapište tok: kdo je zdroj, kam jde, který protokol ho nese a která služba je povolena. Pak najděte kontrolu, která vynucuje každý z těchto čtyř faktů.

Dvě cesty, dva různé příběhy vynucení

Dva tvary jsou běžné a každý může být správný pro jiný požadavek.

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

První tvar může vynutit vše potřebné na bráně, pokud je politika brány napsaná pro tento cíl a server nemá cestu, jak ji obejít. Druhý tvar přidává hranici, ale jen když trasy a politika skutečně nutí provoz projít skrz. Server na stejném segmentu jako koncový bod nemusí nikdy následovat zamýšlený meziskok. Diagram ukazuje záměr a routovací tabulka ukazuje, co se děje.

Ověřujte vyhledáním trasy, ne kresbou. Rozhraní, kterým paket vychází, a další skok, který zvolí, rozhodují, zda se druhý tvar chová podle návrhu.

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

Oddělte topologii od izolace

Sdílená podsíť nedělá místo nedůvěryhodným a vyhrazený tranzit ho nedělá chráněným. Rozhoduje skutečně uplatněné omezení, skutečné přeposílání a to, kdo spravuje každou část. Počítání přepínačů neřekne nic o žádné z těch tří věcí. Rozhodujte podle politiky a trasy a topologie ať následuje rozhodnutí.

Berte populace provozu také odděleně. Puly vzdáleného přístupu, prefixy lokalita-lokalita a sítě vyhrazených linek mohou sdílet jedno zařízení a přesto potřebovat jiná pravidla, protože jejich identity a riziko se liší. Pravidlo napsané pro jednu populaci tiše pokrývá ostatní, když sdílejí adresní plán.

Kontrolujte selhání a správu pro každé umístění

Každé umístění má režim selhání a užitečná otázka je, co ještě funguje, když komponenta přestane. Několik logických rozhraní na jednom mrtvém zařízení vám nedá nezávislé obnovení a navazující firewall se stejným napájením nebo stejným správcem není druhá hranice. Ptejte se, kudy vede cesta správy, protože konzole dostupná jen tunelem není vůbec cesta obnovy; ssh [email protected] true zvenku tunelu je nejlevnější způsob, jak dokázat, že konzole na něm nezávisí. Dokumentace skupinové politiky jedné platformy klade svůj filtr na provoz po dešifrování a před šifrováním, což je přesně ten pojmenovaný háček, který je třeba hledat v každém produktu.

Napište příběh selhání každého kandidáta vedle příběhu vynucení. Umístění, které vyhraje při kontrole a prohraje při obnově, je obchod a má být zaznamenáno jako takový, místo aby bylo objeveno během incidentu.

Přijměte s povoleným a zakázaným tokem

S schváleným testovacím plánem zkontrolujte tři věci ze skutečného zdroje VPN: aplikaci, která má fungovat, zdroj, který nemá, a směr, kterým se odpověď vrací. Odepření je důkazem, že politika je zapojena, zatímco povolený tok jen dokazuje, že cesta existuje.

Uchovávejte zvolenou trasu a výsledek politiky společně, protože výsledek bez trasy nelze reprodukovat a trasu bez výsledku nelze obhájit. Tato dvojice je pro volbu připojného bodu mnohem užitečnější než jakékoli tvrzení o tom, která vrstva přepínání je sama o sobě bezpečnější.