DNAT u VPN kontejneru: prosljeđivanje, ne INPUT

Nakon DNAT-a zahtjev za adresu tunela postaje proslijeđeni saobraćaj. Suzte pravilo prosljeđivanja, pročitajte Docker lanac i svjesno odaberite povratni put.

Zahtjev stiže s adresom IP tunela i napušta isti kontejner s adresom susjedne usluge. Između ta dva trenutka DNAT je prepisao odredište, pa paket više nije ulaz za VPN kontejner. Sada je to proslijeđeni saobraćaj, kojim sudi drugo pravilo. Ta promjena objašnjava zašto pravilo firewall-a koje izgleda ispravno za adresu tunela nema efekta na prevedenu vezu.

Pratite paket nakon prevođenja

Uzmite skup klijenata 10.90.0.0/24 i adresu tunela 10.90.0.1. Dva kontejnera stoje na jednom bridge-u: 192.0.2.2 pokreće VPN, a 192.0.2.3 pokreće aplikaciju. Klijent se povezuje na 10.90.0.1:8080, a DNAT pravilo u namespace-u VPN kontejnera to prepisuje na stvarnu adresu i port aplikacije. Ruta zatim šalje paket preko bridge-a. Te adrese su ilustrativne, nisu recept za postavljanje.

Port na kojem aplikacija zaista sluša može se razlikovati od bilo kojeg porta objavljenog na hostu. Pročitajte listener unutar kontejnera umjesto da pretpostavite da se oba broja poklapaju.

Dozvola pripada putu prosljeđivanja

VPN kontejneru treba IP prosljeđivanje i odluka o prosljeđivanju ograničena na skup klijenata, adresu aplikacije i predviđeni port. Uspostavljeni odgovori trebaju vlastitu dozvolu. Pravilo koje odgovara izvornoj adresi tunela neće odgovarati nakon DNAT-a, jer se odredište već promijenilo. Dozvola INPUT je pogrešna kuka za saobraćaj koji više nije adresiran na ovaj host.

Držite obim uskim: jedan raspon izvora, jedno odredište, jedna usluga. Popustljivo pravilo prosljeđivanja lakše je napisati i mnogo teže kasnije braniti.

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

Docker lanci nisu lanci vašeg kontejnera

Pravila unutar namespace-a kontejnera nisu pravila Docker hosta. Kada saobraćaj pređe s interfejsa tunela na bridge, firewall bridge-a na hostu može donijeti drugu odluku. Uz Docker-ov iptables backend, dokumentovani lanci prosljeđivanja i tačke podudaranja nakon DNAT-a mjesto su gdje se ta odluka pojavljuje.

Docker referenca za firewall opisuje te lance i podudaranje nakon DNAT-a. Ne ispravljajte nedostajuće prihvatanje isključivanjem Docker-ovog upravljanja firewall-om ili čineći svaki lanac popustljivim, jer to uklanja granicu koju pokušavate koristiti.

Učinite povratni put svjesnim izborom

Ako je izvorna adresa sačuvana, aplikacija vidi 10.90.0.x i mora usmjeriti odgovore natrag kroz VPN kontejner. Inače će ih njen uobičajeni Docker gateway poslati na host, koji ne posjeduje tunel. Alternativa je usko ograničeno prevođenje izvora na VPN kontejneru, koje pojednostavljuje odgovor ali skriva klijenta od aplikacije. Odaberite svjesno i zapišite koju ste opciju odabrali.

Testirajte novu dozvoljenu vezu s običnog klijenta, zatim potvrdite da nepovezani portovi ostaju zatvoreni. Kada paket nestane, pregledajte VPN namespace, namespace aplikacije i vlastiti log aplikacije. Ping na bridge gateway nije test prihvatanja za uslugu.

Držite pravila u podržanoj startnoj konfiguraciji kontejnera, jer interaktivne izmjene nestaju kada se ponovo kreira. Objavljivanje porta na hostu drugi je put izlaganja i nije potrebno samo zato što je usluga dostupna kroz tunel.

Povezani članci