Objavljanje vrat Docker in viri VPN: dve ujemanji, ki ju zgrešite

Pravilo pravi dovolite naslov VPN strežnika do objavljene storitve, povezava pa vseeno pade. Ta izid je običajen in ni napaka Dockerja. Dve ločeni ujemanji sta napačni: vir, ki ste ga zapisali, morda ni vir, ki ga prejme gostitelj, in vrata, ki ste jih zapisali, morda niso vrata, ki jih vidi filter. Popraviti oboje zahteva pogled na pot paketa, ne na shemo storitve.

Mit: dovolite VPN strežnik in končano

Usmerjeni VPN lahko ohrani naslov tunela odjemalca vse do gostitelja Docker. Prehod, ki izvaja prevajanje vira, lahko ta naslov nadomesti s svojim. Obe zasnovi sta zakoniti in dajeta različne vire za isto dejanje uporabnika.

Torej besedna zveza IP naslov VPN strežnika opisuje predpostavko, ne opazovanja. Dokler ne veste, katera od obeh zasnov je pred vami, je pravilo ugibanje.

Vir: nabor odjemalcev ali prevedeni prehod

Preverite štiri stvari po vrsti. Prvič, nabor naslovov odjemalcev, na primer 10.90.0.0/24. Drugič, ali prehod ta nabor prevede, preden doseže gostitelja. Tretjič, kateri vir gostitelj dejansko opazuje za eno novo povezavo. Četrtič, ali preverjanje pristnosti aplikacije razlikuje posamezne uporabnike, saj skupni prevedeni naslov tega ne more.

Če se nabor ohrani, pravilo, ki se ujema samo z javnim naslovom prehoda, zgreši vsakega odjemalca. Če prehod namerno prevaja, dovoljenje prevedenega naslova spusti vsakega uporabnika za njim, kar je lahko sprejemljivo za storitev z lastno prijavo in nesprejemljivo za vse drugo.

Vrata: DNAT spremeni število, s katerim se ujemate

Pri običajnem objavljanju prek mostu Linux z iptables Dockerja se preslikava gostitelja z 8443 na vrata vsebnika 443 prevede, preden se zažene filter za posredovanje. Paket prispe do filtra s ciljnimi vrati 443. Pravilo, ki se v tistem trenutku ujema s 8443, se nikoli ne sproži, čeprav je 8443 tisto, kar je odjemalec vnesel.

Objavljena vrata še vedno obstajajo v sledenju povezav, zato je mogoče tam primerjati prvotni cilj, ko ga resnično potrebujete.

Odločite, katero število izraža namen. Ujemajte vrata vsebnika po DNAT, ko pravilo ščiti storitev znotraj vsebnika. Ujemajte prvotni cilj z možnostjo conntrack, ko mora pravilo opisati, kaj je odjemalec zahteval, in sprejmite dodatne stroške ujemanja in skrb za vrstni red pravil, ki pridejo s tem.

Veriga: DOCKER-USER, ne INPUT

Dockerjev vodnik po iptables uvršča politiko posredovanja uporabnika v verigo DOCKER-USER, ki se ovrednoti pred Dockerjevimi lastnimi pravili posredovanja. Pravilo, kopirano iz storitve gostitelja v verigo INPUT, filtrira promet, naslovljen na gostitelja, ne prometa, posredovanega v vsebnik. Ta napaka ustvari pravilo, ki je videti pravilno in nima nobenega učinka na pot vsebnika.

Držite obseg vira, dejanska ciljna vrata, protokol in vhodni vmesnik skupaj v istem pravilu. Dovoljenje samo po viru za vsak posredovani cilj je širše od dovoljenja ene objavljene storitve.

Preverite s svežimi povezavami

Preizkusite obe smeri z novimi povezavami: enega dovoljenega odjemalca VPN in en vir, ki mora ostati zavrnjen. Obstoječe stanje povezave lahko ohrani sejo živo po spremembi politike, zato staro povezavo ničesar ne dokazuje o novem pravilu. Nato preverite pot odgovora, ker mora vsebnik še vedno usmerjati nazaj na vir, ki ga vidi.

Vrstni red verig in vedenje prevajanja vrat za temi preverjanji dokumentira Dockerjev vodnik po iptables. Preberite ga, preden kopirate recept, in potrdite, kateri backend uporablja nameščeni Docker, ker backend nftables politiko vključuje drugače.