DNAT v kontajneri VPN: preposielanie, nie INPUT

Po DNAT sa požiadavka na adresu tunela stáva preposielanou premávkou. Zúžte pravidlo preposielania, prečítajte reťaz Docker a vedome zvoľte spiatočnú cestu.

Požiadavka prichádza adresovaná na IP adresu tunela a opúšťa ten istý kontajner adresovaná na susednú službu. Medzi týmito dvoma okamihmi DNAT prepísal cieľ a paket prestal byť vstupom pre kontajner VPN. Teraz je to preposielaná premávka, posudzovaná iným pravidlom. Tento posun vysvetľuje, prečo pravidlo firewallu, ktoré vyzerá správne pre adresu tunela, nemá na preložené spojenie žiadny vplyv.

Sledujte paket po preklade

Vezmite fond klientov 10.90.0.0/24 a adresu tunela 10.90.0.1. Dva kontajnery sedia na jednom bridge: 192.0.2.2 prevádzkuje VPN a 192.0.2.3 prevádzkuje aplikáciu. Klient sa pripojí na 10.90.0.1:8080 a pravidlo DNAT v namespace kontajnera VPN to prepíše na skutočnú adresu a port aplikácie. Potom trasa pošle paket cez bridge. Tieto adresy sú ilustratívne, nie sú receptom na nasadenie.

Port, na ktorom aplikácia skutočne počúva, sa môže líšiť od akéhokoľvek portu publikovaného na hostiteľovi. Prečítajte poslucháča vo vnútri kontajnera namiesto predpokladu, že sa obe čísla zhodujú.

Povolenie patrí ceste preposielania

Kontajner VPN potrebuje preposielanie IP a rozhodnutie o preposielaní obmedzené na fond klientov, adresu aplikácie a zamýšľaný port. Nadviazané odpovede potrebujú vlastné povolenie. Pravidlo, ktoré zodpovedá pôvodnej adrese tunela, po DNAT už nebude zodpovedať, pretože cieľ sa už zmenil. Povolenie INPUT je nesprávny hák pre premávku, ktorá už nie je adresovaná tomuto hostiteľovi.

Držte rozsah úzky: jeden rozsah zdrojov, jeden cieľ, jedna služba. Permisívne pravidlo preposielania sa píše ľahšie a oveľa ťažšie sa neskôr 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

Reťaze Dockeru nie sú reťazami vášho kontajnera

Pravidlá v namespace kontajnera nie sú pravidlami hostiteľa Dockeru. Keď premávka prechádza z rozhrania tunela na bridge, firewall bridgea na hostiteľovi môže rozhodnúť inak. Pri backende iptables v Dockeri sú dokumentované reťaze preposielania a miesta zhody po DNAT tým miestom, kde sa toto rozhodnutie objavuje.

Referenčná príručka Dockeru k firewallu opisuje tieto reťaze a zhodu po DNAT. Neopravujte chýbajúce povolenie vypnutím správy firewallu Dockeru alebo zpermisívnením každej reťaze, pretože tým odstránite hranicu, ktorú sa snažíte použiť.

Urobte zo spätnej cesty vedomú voľbu

Ak sa zdrojová adresa zachová, aplikácia vidí 10.90.0.x a musí smerovať odpovede späť cez kontajner VPN. Inak ich jej bežná brána Dockeru pošle na hostiteľa, ktorý tunel nevlastní. Alternatívou je úzko obmedzený preklad zdroja v kontajneri VPN, ktorý zjednodušuje odpoveď, ale skrýva klienta pred aplikáciou. Vyberajte vedome a zapíšte, ktorú možnosť ste zvolili.

Vyskúšajte nové povolené spojenie z bežného klienta a potom potvrďte, že nesúvisiace porty zostanú zatvorené. Keď paket zmizne, preskúmajte namespace VPN, namespace aplikácie a vlastný log aplikácie. Ping na bránu bridgea nie je akceptačný test služby.

Držte pravidlá v podporovanej štartovacej konfigurácii kontajnera, pretože interaktívne úpravy zmiznú pri jeho opätovnom vytvorení. Publikovanie portu na hostiteľovi je iná cesta vystavenia a nie je potrebné len preto, že služba je dostupná cez tunel.

Súvisiace články