DNAT VPN konteineryje: persiuntimas, o ne INPUT

Po DNAT užklausa į tunelio adresą tampa persiunčiamu srautu. Susiaurinkite persiuntimo taisyklę, perskaitykite Docker grandinę ir sąmoningai pasirinkite grįžimo kelią.

Užklausa atvyksta adresuota tunelio IP ir išvyksta iš to paties konteinerio adresuota gretimo serviso adresu. Tarp šių dviejų akimirkų DNAT perrašė paskirties vietą, ir paketas nustojo būti VPN konteinerio įvestimi. Dabar tai persiunčiamas srautas, kurį vertina kita taisyklė. Šis pokytis paaiškina, kodėl ugniasienės taisyklė, kuri atrodo tinkama tunelio adresui, neturi jokio poveikio išverstam ryšiui.

Sekite paketą po vertimo

Paimkite klientų telkinį 10.90.0.0/24 ir tunelio adresą 10.90.0.1. Du konteineriai stovi ant vieno tilto: 192.0.2.2 paleidžia VPN, o 192.0.2.3 paleidžia programą. Klientas jungiasi prie 10.90.0.1:8080, o DNAT taisyklė VPN konteinerio vardų erdvėje perrašo tai į tikrąjį programos adresą ir prievadą. Tada maršrutas siunčia paketą per tiltą. Šie adresai yra iliustraciniai, ne diegimo receptas.

Prievadas, kuriame programa iš tikrųjų klausosi, gali skirtis nuo bet kurio prievado, paskelbto hoste. Skaitykite klausytoją konteinerio viduje, o ne manykite, kad abu skaičiai sutampa.

Leidimas priklauso persiuntimo keliui

VPN konteineriui reikia IP persiuntimo ir persiuntimo sprendimo, apriboto klientų telkiniu, programos adresu ir numatytu prievadu. Nustatyti atsakymai turi turėti savo leidimą. Taisyklė, atitinkanti pradinį tunelio adresą, nebeatitiks po DNAT, nes paskirties vieta jau pasikeitė. INPUT leidimas yra netinkamas kablys srautui, kuris nebėra adresuotas šiam hostui.

Laikykite apimtį siaurą: vienas šaltinio diapazonas, viena paskirties vieta, viena paslauga. Leidžianti persiuntimo taisyklė yra lengviau parašoma ir daug sunkiau vėliau apginama.

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

Docker grandinės nėra jūsų konteinerio grandinės

Taisyklės konteinerio vardų erdvėje nėra Docker hosto taisyklės. Kai srautas pereina iš tunelio sąsajos į tiltą, hosto tilto ugniasienė gali priimti kitą sprendimą. Su Docker iptables backend dokumentuotos persiuntimo grandinės ir atitikimo taškai po DNAT yra vieta, kur tas sprendimas pasirodo.

Docker ugniasienės žinynas aprašo tas grandines ir atitikimą po DNAT. Netaisykite trūkstamo priėmimo išjungdami Docker ugniasienės valdymą arba padarydami kiekvieną grandinę leidžiančią, nes tai pašalina ribą, kurią bandote naudoti.

Padarykite grįžimo kelią sąmoningu pasirinkimu

Jei šaltinio adresas išsaugomas, programa mato 10.90.0.x ir turi nukreipti atsakymus atgal per VPN konteinerį. Priešingu atveju jos įprastas Docker šliuzas nusiųs juos hostui, kuris nevaldo tunelio. Alternatyva yra siaurai apribotas šaltinio vertimas VPN konteineryje, kuris supaprastina atsakymą, bet paslepia klientą nuo programos. Rinkitės sąmoningai ir užsirašykite, ką pasirinkote.

Išbandykite naują leidžiamą ryšį iš paprasto kliento, tada patvirtinkite, kad nesusiję prievadai lieka uždaryti. Kai paketas dingsta, patikrinkite VPN vardų erdvę, programos vardų erdvę ir pačios programos žurnalą. Ping į tilto šliuzą nėra paslaugos priėmimo testas.

Laikykite taisykles palaikomoje konteinerio paleidimo konfigūracijoje, nes interaktyvūs pakeitimai dingsta jį sukūrus iš naujo. Host prievado paskelbimas yra kitas poveikio kelias ir nereikalingas vien todėl, kad paslauga pasiekiama per tunelį.

Susiję straipsniai