Jak omezit přístup mezi dvěma pobočkami propojenými VPN

Tunel mezi lokalitami odpovídá na jednu otázku, zda si obě pobočky mohou vyměňovat pakety, a tu důležitou nechává otevřenou: které zařízení pobočky smí dosáhnout které centrální služby. Považovat tunel za vzájemnou důvěru je způsob, jak se hostující notebook ocitne na stejné cestě jako finanční server. Řešením není lepší tunel, ale výslovný seznam povolení uplatněný po dešifrování. Tato příručka vede tento seznam od definice k prokázanému odmítnutí.

Pracujte v tomto pořadí a nerozšiřujte trasu tunelu, dokud níže uvedené kroky zásad neprojdou.

Napište matici, než se dotknete brány

Užitečný řádek pojmenovává tři věci: skupinu zdroje, cílový hostitel nebo servisní síť a protokol a port, které aplikace skutečně používá. Pobočka a datové centrum nejsou položky. Privátní DNS a autentizační služby si zaslouží vlastní řádky jen tehdy, když aplikace bez nich nemůže fungovat.

Seskupujte zdroje podle role, ne podle pohodlí podsítě: zaměstnanci, hosté, správa. Když všechny tři sdílejí jednu plochou LAN, brána je na síťové vrstvě nerozliší, takže řízení identity nebo segmentace musí přijít první. Potom matici sepište s vlastníkem a datem revize u každého řádku.

Uplatněte to tam, kde se pakety dešifrují

Pravidla, která povolují IKE a ESP, stavějí jen vnější tunel. Vnitřní provoz přichází otevřeně na rozhraní tunelu a právě tam patří seznam povolení: řetězec předávání na dešifrujícím zařízení, výchozí zahazování, jedno pravidlo na řádek matice. Na linuxových branách to znamená zapnuté předávání a filtrační pravidla na zařízení tunelu, ne na fyzickém uplinku, jak vysvětluje průvodce předáváním strongSwan.

Selektory provozu jsou rozhodnutí směrování, ne autorizace. Široký selektor pokrývající obě podsítě může být správný pro směrování, zatímco firewall stále povoluje jen TCP 443 k jednomu hostiteli. Selektor se vyjednává pro tunel a popisuje, co do něj smí vstoupit, ne co smí používat které zařízení. Nikdy nerozšiřujte pravidlo firewallu proto, že selektor je široký.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT a překrývající se podsítě mění pravidla

Když brána pobočky přeloží každého hostitele na jednu adresu před tunelem, každý řádek založený na zdroji se slije do této jedné adresy. Buď přestaňte překládat provoz tunelu, nebo přijměte, že pravidla musí stát na něčem jiném, například na původní zdrojové adrese zaznamenané před překladem. Vzdálený konec má stejný problém, protože cílový hostitel vidí adresu po NAT, ne původní.

Překrývající se rozsahy jsou druhá past. Dvě pobočky, které obě používají 192.168.1.0/24, nelze popsat v jedné tabulce zásad bez mapování jedné strany, a mapování nenahrazuje adresování, které se nesráží. Opravte plán, než napíšete pravidla, která budete muset později rozmotat.

Dokažte odmítnutí, ne jen úspěch

Testování jen povolené aplikace dokazuje velmi málo, protože povolující pravidlo někde výše dává stejný výsledek.

Z běžného zařízení pobočky dosáhněte zamýšlené služby a potvrďte, že celá relace funguje. Pak zkuste cíl, který musí zůstat zavřený, například administrativní port na serveru, k němuž pobočka nemá co dělat, a přečtěte počítadlo nebo záznam v logu, který ho zahodil. Vypnutí sady pravidel pro kontrolu, zda funguje, zneplatní test a nechá bránu otevřenou, dokud se díváte.

Udržujte seznam živý

Aplikace se stěhují a pravidlo, které přežije svou aplikaci, se stane děrou, kterou nikdo nevlastní. Připojte datum revize k řádku a při změně adresy služby změňte rozsah selektoru i pravidlo firewallu ve stejném údržbovém kroku.

Omezení na úrovni hostitele jsou za tunelem stále důležitá: vlastní firewall serveru má přijímat rozsah pobočky jen pro službu, kterou publikuje. Dvě vrstvy, které si odpovídají, se auditují snáz než jedna vrstva, které se plně věří.