DNAT ve VPN kontejneru: předávání, ne INPUT

Po DNAT se požadavek na adresu tunelu stává předávaným provozem. Zužte pravidlo předávání, přečtěte řetěz Docker a vědomě zvolte zpáteční cestu.

Požadavek přichází s adresou IP tunelu a opouští stejný kontejner s adresou sousední služby. Mezi těmito dvěma okamžiky DNAT přepsal cíl a paket přestal být vstupem pro VPN kontejner. Nyní je to předávaný provoz, posuzovaný jiným pravidlem. Tento posun vysvětluje, proč pravidlo firewallu, které vypadá správně pro adresu tunelu, nemá na přeložené spojení žádný vliv.

Sledujte paket po překladu

Vezměte fond klientů 10.90.0.0/24 a adresu tunelu 10.90.0.1. Dva kontejnery sedí na jednom bridge: 192.0.2.2 provozuje VPN a 192.0.2.3 provozuje aplikaci. Klient se připojí na 10.90.0.1:8080 a pravidlo DNAT v namespace VPN kontejneru to přepíše na skutečnou adresu a port aplikace. Trasa pak pošle paket přes bridge. Tyto adresy jsou ilustrativní, ne recept na nasazení.

Port, na kterém aplikace skutečně naslouchá, se může lišit od jakéhokoli portu publikovaného na hostiteli. Přečtěte naslouchač uvnitř kontejneru, místo abyste předpokládali, že se obě čísla shodují.

Oprávnění patří na cestu předávání

VPN kontejner potřebuje předávání IP a rozhodnutí o předávání omezené na fond klientů, adresu aplikace a zamýšlený port. Navázané odpovědi potřebují vlastní povolení. Pravidlo odpovídající původní adrese tunelu po DNAT odpovídat nebude, protože cíl se už změnil. Povolení INPUT je špatný hák pro provoz, který už není adresován tomuto hostiteli.

Držte rozsah úzký: jeden rozsah zdrojů, jeden cíl, jedna služba. Permisivní pravidlo předávání se píše snadněji a mnohem hůř se později obhajuje.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Řetězy Dockeru nejsou řetězy vašeho kontejneru

Pravidla uvnitř namespace kontejneru nejsou pravidla hostitele Dockeru. Když provoz přechází z rozhraní tunelu na bridge, firewall bridge na hostiteli může rozhodnout jinak. U backendu iptables v Dockeru jsou dokumentované řetězy předávání a místa shody po DNAT tam, kde se toto rozhodnutí objevuje.

Referenční příručka Dockeru k firewallu popisuje tyto řetězy a shodu po DNAT. Neopravujte chybějící povolení vypnutím správy firewallu Dockeru nebo zpermisivněním každého řetězu, protože tím odstraníte hranici, kterou se snažíte použít.

Udělejte ze zpáteční cesty vědomou volbu

Pokud je zdrojová adresa zachována, aplikace vidí 10.90.0.x a musí směrovat odpovědi zpět přes VPN kontejner. Jinak je její běžná brána Dockeru pošle na hostitele, který tunel nevlastní. Alternativou je úzce omezený překlad zdroje na VPN kontejneru, který zjednodušuje odpověď, ale skrývá klienta před aplikací. Vybírejte vědomě a zapište, kterou možnost jste zvolili.

Vyzkoušejte nové povolené spojení z běžného klienta a poté potvrďte, že nesouvisející porty zůstanou zavřené. Když paket zmizí, prozkoumejte namespace VPN, namespace aplikace a vlastní log aplikace. Ping na bránu bridge není akceptační test služby.

Držte pravidla v podporované startovní konfiguraci kontejneru, protože interaktivní úpravy zmizí při jeho opětovném vytvoření. Publikace portu na hostiteli je jiná cesta vystavení a není potřeba jen proto, že je služba dostupná přes tunel.

Související články