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

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

Mit: dopustite VPN poslužitelj i gotovi ste

Usmjereni VPN može sačuvati adresu klijentskog tunela sve do Docker poslužitelja. 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, izraz IP adresa VPN poslužitelja opisuje pretpostavku, a ne opažanje. Dok ne znate koje je od dvaju rješenja pred vama, pravilo je nagađanje.

Izvor: klijentski skup ili prevedeni pristupnik

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

Ako se skup č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 uspoređujete

Kod običnog objavljivanja preko Linux mosta uz Docker iptables, preslikavanje poslužitelja s 8443 na port kontejnera 443 prevodi se prije nego što se pokrene filtar za prosljeđivanje. Paket stiže do filtra 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 usporediti kada vam to doista treba.

Odlučite koji broj izražava namjeru. Usporedite port kontejnera nakon DNAT-a kada pravilo štiti uslugu unutar kontejnera. Usporedite izvorno odredište s opcijom conntrack kada pravilo mora opisati što je klijent zatražio, i prihvatite dodatni trošak uspoređivanja i pažnju na redoslijed pravila koji 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 poslužitelju u lanac INPUT filtrira promet upućen poslužitelju, a ne promet proslijeđen u kontejner. Ta pogreš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 dokumentira Dockerov vodič za iptables. Pročitajte ga prije kopiranja recepta i potvrdite koji pozadinski mehanizam rabi instalirani Docker, jer nftables pozadina drukčije integrira politiku.