Docker-Portpublikatioun a VPN-Quellen: zwou Iwwereneestëmmungen, déi Dir verpasst

D’Reegel seet, erlaabt d’Adress vum VPN-Server zum publizéierte Service, an d’Verbindung fält trotzdem. Dëst Resultat ass heefeg, an et ass kee Fehler vun Docker. Zwou getrennt Iwwereneestëmmunge sinn falsch: d’Quell, déi Dir geschriwwen hutt, ass vläicht net déi Quell, déi den Host kritt, an de Port, deen Dir geschriwwen hutt, ass vläicht net dee Port, deen de Filter gesäit. Béides ze flécken erfuerdert ee Bléck op de Paketwee amplaz vum Serviceschema.

De Mythos: erlaabt de VPN-Server an Dir sidd fäerdeg

E geroutete VPN kann d’Tunneladress vum Client bis zum Docker-Host halen. En Gateway, dee Quellübersetzung mécht, kann déi Adress duerch seng ersetzt. Béid Konzepter si legitim, a si produzéieren ënnerschiddlech Quelle fir déiselwecht Benotzeraktioun.

Also beschreift den Ausdrock IP vum VPN-Server eng Unhuel, keng Observatioun. Bis Dir wësst, ween vun den zwou Konzepter virun Iech steet, ass d’Reegel eng Vermutung.

Quell: Clientpool oder iwwersate Gateway

Préift véier Saachen an der Rei. Éischtens de Clientadresspool, zum Beispill 10.90.0.0/24. Zweetens, ob de Gateway dee Pool iwwersetzt, ier en den Host erreecht. Drëttens d’Quell, déi den Host tatsächlech fir eng nei Verbindung observéiert. Véiertens, ob d’Authentifikatioun vun der Applikatioun eenzel Benotzer ënnerscheet, well eng gedeelt iwwersat Adress dat net kann.

Wann de Pool erhalen bleift, verpasst eng Reegel, déi nëmmen op d’ëffentlech Adress vum Gateway passt, all Client. Wann de Gateway bewosst iwwersetzt, léisst d’Erlabnes vun der iwwersater Adress all Benotzer dohannert eraus, wat akzeptabel ka sinn fir e Service mat sengem eegene Login an onakzeptabel fir alles anescht.

Port: DNAT ännert d’Zuel, déi Dir vergläicht

Bei der gewéinlecher Linux-Bréckpublikatioun mat Docker iptables gëtt eng Hostzouuerdnung vun 8443 op de Containerport 443 iwwersat, ier de Weiderleitungsfilter leeft. De Paket kënnt beim Filter u mam Zilport 443. Eng Reegel, déi op deem Punkt op 8443 passt, mécht ni op, och wann 8443 dat ass, wat de Client getippt huet.

De publizéierten Port existéiert nach ëmmer an der Verbindungsverfolgung, dofir kann dat ursprénglecht Zil do verglach ginn, wann Dir et wierklech braucht.

Entscheet, wéi eng Zuel d’Absicht ausdréckt. Passt op de Containerport no DNAT, wann d’Reegel de Service am Container schützt. Passt op dat ursprénglecht Zil mat der conntrack-Optioun, wann d’Reegel beschreiwe muss, wat de Client gefrot huet, an akzeptéiert déi zousätzlech Vergläichkäschten an d’Suergfalt bei der Reegeluerdnung, déi domat kommen.

Ketten: DOCKER-USER, net INPUT

Dem Docker seng iptables-Guide setzt d’Weiderleitungspolitik fir Benotzer an d’Kette DOCKER-USER, déi virun den eegene Weiderleitungsreegele vum Docker evaluéiert gëtt. Eng Reegel, déi aus engem Hostservice an d’Kette INPUT kopéiert gouf, filtert Traffic, deen un den Host adresséiert ass, net Traffic, deen an e Container weidergeleet gëtt. Dee Feeler produzéiert eng Reegel, déi richteg ausgesäit an keen Effekt op de Containerwee huet.

Halt de Quellberäich, den effektiven Zilport, de Protokoll an d’Ingangsschnëttstell zesummen an der selwechter Reegel. Eng Erlabnes nëmmen op Basis vun der Quell fir all weidergeleet Zil ass méi breet wéi eng eenzeg publizéiert Erlabnes.

Verifizéiert mat frësche Verbindungen

Test béid Richtungen mat neie Verbindungen: ee erlaabte VPN-Client an eng Quell, déi refuséiert bleiwe soll. Den existéierende Verbindungszoustand kann eng Sitzung lieweg halen, nodeems d’Politik geännert gouf, dofir beweist eng al Verbindung näischt iwwer déi nei Reegel. Préift duerno de Äntwertwee, well de Container nach ëmmer missen zréck op d’Quell route muss, déi en gesäit.

D’Ketteuerdnung an d’Portiwwersetzungsverhalen hannert dësen Iwwerpréiwungen dokumentéiert dem Docker seng iptables-Guide. Liest se, ier Dir en Rezept kopéiert, a bestätegt, wéi ee Backend déi installéiert Docker benotzt, well den nftables-Backend d’Politik anescht integréiert.