DNAT v vsebniku VPN: posredovanje, ne INPUT

Po DNAT zahteva na naslov tunela postane posredovani promet. Zožite pravilo posredovanja, preberite verigo Docker in zavestno izberite povratno pot.

Zahteva prispe naslovljena na IP tunela in zapusti isti vsebnik naslovljena na sosednjo storitev. Med tema dvema trenutkoma je DNAT prepisal cilj in paket ni bil več vhod za vsebnik VPN. Zdaj je to posredovani promet, ki ga presoja drugo pravilo. Ta premik pojasnjuje, zakaj pravilo požarnega zidu, ki se zdi pravilno za naslov tunela, nima nobenega učinka na prevedeno povezavo.

Sledite paketu po prevodu

Vzemite nabor odjemalcev 10.90.0.0/24 in naslov tunela 10.90.0.1. Dva vsebnika stojita na enem mostu: 192.0.2.2 izvaja VPN, 192.0.2.3 pa izvaja aplikacijo. Odjemalec se poveže na 10.90.0.1:8080, pravilo DNAT v imenskem prostoru vsebnika VPN pa to prepiše na dejanski naslov in vrata aplikacije. Nato pot pošlje paket čez most. Ti naslovi so ponazoritveni, ne recept za uvajanje.

Vrata, na katerih aplikacija dejansko posluša, se lahko razlikujejo od katerih koli vrat, objavljenih na gostitelju. Preberite poslušalca znotraj vsebnika, namesto da predpostavite, da se obe številki ujemata.

Dovoljenje pripada poti posredovanja

Vsebnik VPN potrebuje posredovanje IP in odločitev o posredovanju, omejeno na nabor odjemalcev, naslov aplikacije in predvidena vrata. Vzpostavljeni odgovori potrebujejo svoje dovoljenje. Pravilo, ki se ujema s prvotnim naslovom tunela, se po DNAT ne bo več ujemalo, ker se je cilj že spremenil. Dovoljenje INPUT je napačen kavelj za promet, ki ni več naslovljen na tega gostitelja.

Obseg naj bo ozek: eno območje virov, en cilj, ena storitev. Popustljivo pravilo posredovanja je lažje napisati in veliko težje pozneje 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

Dockerjeve verige niso verige vašega vsebnika

Pravila znotraj imenskega prostora vsebnika niso pravila gostitelja Docker. Ko promet preide z vmesnika tunela na most, lahko požarni zid mostu na gostitelju sprejme drugačno odločitev. Pri backendu iptables v Dockerju so dokumentirane verige posredovanja in točke ujemanja po DNAT mesto, kjer se ta odločitev pojavi.

Dockerjeva referenca za požarni zid opisuje te verige in ujemanje po DNAT. Ne popravljajte manjkajoče odobritve z izklopom Dockerjevega upravljanja požarnega zidu ali s popustljivostjo vsake verige, ker to odstrani mejo, ki jo poskušate uporabiti.

Naredite povratno pot zavestno izbiro

Če se izvorni naslov ohrani, aplikacija vidi 10.90.0.x in mora usmerjati odgovore nazaj skozi vsebnik VPN. Sicer jih bo njegova običajna Dockerjeva prehodna točka poslala na gostitelja, ki tunela ne poseduje. Druga možnost je ozko omejen prevod vira v vsebniku VPN, ki poenostavi odgovor, a skrije odjemalca pred aplikacijo. Izberite zavestno in zapišite, katero ste izbrali.

Preizkusite novo dovoljeno povezavo z običajnega odjemalca in nato potrdite, da nepovezana vrata ostanejo zaprta. Ko paket izgine, preglejte imenski prostor VPN, imenski prostor aplikacije in aplikacijin lastni dnevnik. Ping na prehodna vrata mostu ni sprejemni preizkus storitve.

Pravila hranite v podprti zagonski konfiguraciji vsebnika, ker interaktivne spremembe izginejo, ko je ta znova ustvarjen. Objava vrat na gostitelju je druga pot izpostavljenosti in ni potrebna le zato, ker je storitev dosegljiva skozi tunel.

Sorodni članki