DNAT u VPN kontejneru: prosljeđivanje, a ne INPUT

Nakon DNAT-a zahtjev za adresu tunela postaje proslijeđeni promet. Suzite 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 tih dvaju trenutaka DNAT je prepisao odredište i paket više nije ulaz za VPN kontejner. Sada je to proslijeđeni promet, kojim sudi drugo pravilo. Ta promjena objašnjava zašto pravilo vatrozida koje izgleda ispravno za adresu tunela nema učinka 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 bridgeu: 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 prostoru naziva VPN kontejnera to prepisuje na stvarnu adresu i port aplikacije. Ruta zatim šalje paket preko bridgea. Te su adrese 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 slušač unutar kontejnera umjesto da pretpostavite da se oba broja podudaraju.

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 pogrešna je kuka za promet koji više nije adresiran na ovaj host.

Držite opseg 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

Dockerovi lanci nisu lanci vašeg kontejnera

Pravila unutar prostora naziva kontejnera nisu pravila Docker hosta. Kada promet prijeđe sa sučelja tunela na bridge, vatrozid bridgea na hostu može donijeti drugu odluku. Uz Dockerov iptables backend, dokumentirani lanci prosljeđivanja i točke podudaranja nakon DNAT-a mjesto su gdje se ta odluka pojavljuje.

Docker referenca za vatrozid opisuje te lance i podudaranje nakon DNAT-a. Ne ispravljajte nedostajuće prihvaćanje isključivanjem Dockerova upravljanja vatrozidom 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 njezin 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 dopuštenu vezu s običnog klijenta, zatim potvrdite da nepovezani portovi ostaju zatvoreni. Kada paket nestane, pregledajte VPN prostor naziva, prostor naziva aplikacije i vlastiti log aplikacije. Ping na bridge gateway nije test prihvaćanja za uslugu.

Držite pravila u podržanoj početnoj konfiguraciji kontejnera, jer interaktivne izmjene nestaju kada se ponovno stvori. Objava porta na hostu drugi je put izlaganja i nije potrebna samo zato što je usluga dostupna kroz tunel.

Povezani članci