DNAT en VPN-kontenero: plusendo, ne INPUT
Post DNAT, peto al la tunela adreso fariĝas plusendita trafiko. Limigu la plusendan regulon, legu la Docker-ĉenon kaj elektu revenan vojon konscie.
La peto alvenas adresita al la tunela IP kaj forlasas la saman konteneron adresita al najbara servo. Inter tiuj du momentoj DNAT reskribis la celon, kaj la paketo ĉesis esti enigo por la VPN-kontenero. Nun ĝi estas plusendita trafiko, juĝata de alia regulo. Tiu ŝanĝo klarigas, kial fajroŝirma regulo, kiu ŝajnas ĝusta por la tunela adreso, havas neniun efikon al la tradukita konekto.
Sekvu la paketon post la traduko
Prenu klientaron 10.90.0.0/24 kaj tunelan adreson 10.90.0.1. Du konteneroj staras sur unu ponto: 192.0.2.2 funkciigas la VPN kaj 192.0.2.3 funkciigas la aplikaĵon. Kliento konektiĝas al 10.90.0.1:8080, kaj la DNAT-regulo en la nomspaco de la VPN-kontenero reskribas tion al la reala adreso kaj pordo de la aplikaĵo. Poste itinero sendas la paketon trans la ponto. Tiuj adresoj estas ilustraj, ne reagordo por deplojo.
La pordo, sur kiu la aplikaĵo efektive aŭskultas, povas malsami de iu ajn pordo publikigita sur la gastiganto. Legu la aŭskultanton ene de la kontenero anstataŭ supozi, ke ambaŭ nombroj kongruas.
La permeso apartenas al la plusenda vojo
La VPN-kontenero bezonas IP-plusendon kaj plusendan decidon limigitan al la klientaro, la aplikaĵa adreso kaj la celata pordo. Firmigitaj respondoj bezonas sian propran permeson. Regulo kongrua kun la origina tunela adreso ne kongruos post DNAT, ĉar la celo jam ŝanĝiĝis. INPUT-permeso estas la malĝusta hoko por trafiko, kiu jam ne estas adresita al ĉi tiu gastiganto.
Tenu la amplekson mallarĝa: unu fonta gamo, unu celo, unu servo. Permesa plusenda regulo estas pli facile skribi kaj multe pli malfacile defendi poste.
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 FORWARDLa ĉenoj de Docker ne estas la ĉenoj de via kontenero
Reguloj ene de la nomspaco de la kontenero ne estas la reguloj de la Docker-gastiganto. Kiam trafiko transiras de la tunela interfaco al la ponto, la ponta fajroŝirmilo de la gastiganto povas fari alian decidon. Ĉe la iptables-motoro de Docker, la dokumentitaj plusendaj ĉenoj kaj la kongruaj punktoj post DNAT estas kie tiu decido aperas.
La Docker-fajroŝirma referenco priskribas tiujn ĉenojn kaj la kongruon post DNAT. Ne riparu mankan akcepton per malŝalto de la fajroŝirma administrado de Docker aŭ per permisigo de ĉiu ĉeno, ĉar tio forigas la limon, kiun vi provas uzi.
Faru la revenan vojon konscia elekto
Se la fonta adreso konserviĝas, la aplikaĵo vidas 10.90.0.x kaj devas itinigi respondojn reen tra la VPN-kontenero. Alie ĝia ordinara Docker-pordego sendos ilin al la gastiganto, kiu ne posedas la tunelon. La alternativo estas mallarĝe limigita fonta traduko ĉe la VPN-kontenero, kiu simpligas la respondon sed kaŝas la klienton de la aplikaĵo. Elektu konscie kaj skribu, kiun vi elektis.
Testu freŝan permesitan konekton de ordinara kliento, poste konfirmu, ke nerilataj pordoj restas fermitaj. Kiam paketo malaperas, ekzamenu la VPN-nomspacon, la aplikaĵan nomspacon kaj la propran protokolon de la aplikaĵo. Ping al la ponta pordego ne estas akcepta testo por la servo.
Tenu la regulojn en la subtenata starta agordo de la kontenero, ĉar interagaj redaktoj malaperas kiam ĝi estas rekreata. Publikigo de gastiganta pordo estas alia elmetvojo kaj ne necesas nur ĉar la servo atingeblas tra la tunelo.