Objavljivanje Docker portova i VPN izvori: dva podudaranja koja propuštate

Pravilo kaže: dopustite adresu VPN servera prema objavljenoj usluzi, a veza se ipak prekida. Takav ishod je uobičajen i nije greška u Dockeru. Dva odvojena podudaranja su pogrešna: izvor koji ste napisali možda nije izvor koji host prima, a port koji ste napisali možda nije port koji filter vidi. Ispravljanje oba zahtijeva gledanje u putanju paketa, a ne u dijagram usluge.

Mit: dopustite VPN server i gotovi ste

Usmjereni VPN može sačuvati adresu klijentskog tunela sve do Docker hosta. Pristupnik koji obavlja prevođenje izvora može tu adresu zamijeniti svojom. Oba su rješenja legitimna i daju različite izvore za istu radnju korisnika.

Dakle, fraza IP adresa VPN servera opisuje pretpostavku, a ne opažanje. Dok ne znate koje je od dva rješenja pred vama, pravilo je nagađanje.

Izvor: klijentski bazen ili prevedeni pristupnik

Provjerite četiri stvari po redu. Prvo, bazen klijentskih adresa, na primjer 10.90.0.0/24. Drugo, prevodi li pristupnik taj bazen prije nego što stigne do hosta. Treće, koji izvor host stvarno vidi za jednu novu vezu. Četvrto, razlikuje li autentifikacija aplikacije pojedinačne korisnike, jer zajednička prevedena adresa to ne može.

Ako se bazen čuva, pravilo koje odgovara samo javnoj adresi pristupnika promašuje svakog klijenta. Ako pristupnik namjerno prevodi, dopuštanje prevedene adrese propušta svakog korisnika iza nje, što može biti prihvatljivo za uslugu s vlastitom prijavom, a neprihvatljivo za sve ostalo.

Port: DNAT mijenja broj koji upoređujete

Kod običnog objavljivanja preko Linux mosta uz Docker iptables, preslikavanje hosta s 8443 na port kontejnera 443 prevodi se prije nego što se pokrene filter za prosljeđivanje. Paket stiže do filtera s odredišnim portom 443. Pravilo koje u tom trenutku odgovara 8443 nikada se ne aktivira, iako je 8443 ono što je klijent upisao.

Objavljeni port i dalje postoji u praćenju veza, zato se izvorno odredište tamo može uporediti kada vam to zaista treba.

Odlučite koji broj izražava namjeru. Uporedite port kontejnera nakon DNAT-a kada pravilo štiti uslugu unutar kontejnera. Uporedite izvorno odredište s opcijom conntrack kada pravilo mora opisati šta je klijent zatražio, i prihvatite dodatni trošak upoređivanja i pažnju na redoslijed pravila koja s tim dolaze.

Lanac: DOCKER-USER, a ne INPUT

Dockerov vodič za iptables smješta korisničku politiku prosljeđivanja u lanac DOCKER-USER, koji se ocjenjuje prije Dockerovih vlastitih pravila prosljeđivanja. Pravilo kopirano iz usluge na hostu u lanac INPUT filtrira promet upućen hostu, a ne promet proslijeđen u kontejner. Ta greška daje pravilo koje izgleda ispravno i nema učinka na putanju kontejnera.

Držite raspon izvora, efektivni odredišni port, protokol i ulazno sučelje zajedno u istom pravilu. Dopuštanje samo po izvoru za svako proslijeđeno odredište šire je od dopuštanja jedne objavljene usluge.

Provjerite novim vezama

Testirajte oba smjera novim vezama: jedan dopušteni VPN klijent i jedan izvor koji treba ostati odbijen. Postojeće stanje veze može održati sesiju živom nakon promjene politike, pa stara veza ne dokazuje ništa o novom pravilu. Zatim provjerite putanju odgovora, jer kontejner se ipak mora usmjeriti natrag na izvor koji vidi.

Redoslijed lanaca i ponašanje prevođenja portova iza ovih provjera dokumentuje Dockerov vodič za iptables. Pročitajte ga prije kopiranja recepta i potvrdite koji pozadinski mehanizam koristi instalirani Docker, jer nftables pozadina drugačije integriše politiku.