DNAT VPN edukiontzi batean: birbidalketa, ez INPUT
DNAT osteko eskaera tuneleko helbidera birbidalitako trafiko bihurtzen da. Murriztu birbidalketa araua, irakurri Docker katea eta aukeratu itzulera bidea nahita.
Eskaera tuneleko IP helbidera iristen da eta edukiontzi beretik ateratzen da alboko zerbitzu baten helbidera. Bi une horien artean DNATek helburua berridatzi zuen, eta paketea VPN edukiontziarentzako sarrera izateari utzi zion. Orain birbidalitako trafikoa da, beste arau batek epaituta. Aldaketa horrek azaltzen du zergatik tuneleko helbiderako zuzena dirudien suebaki arauak ez duen eraginik itzulitako konexioan.
Jarraitu paketeari itzulpenaren ondoren
Hartu 10.90.0.0/24 bezero multzo bat eta 10.90.0.1 tuneleko helbide bat. Bi edukiontzi zubi bakarrean daude: 192.0.2.2 VPN-a exekutatzen du eta 192.0.2.3 aplikazioa exekutatzen du. Bezero bat 10.90.0.1:8080 helbidera konektatzen da, eta VPN edukiontziaren izen-espazioko DNAT arauak aplikazioaren benetako helbide eta portura berridazten du. Gero ibilbide batek paketea zubitik bidaltzen du. Helbide horiek ilustratiboak dira, ez inplementazio errezeta.
Aplikazioak benetan entzuten duen portua ostalarian argitaratutako edozein portutatik desberdina izan daiteke. Irakurri entzulea edukiontziaren barruan, bi zenbakiak bat datozela suposatu beharrean.
Baimena birbidalketa bideari dagokio
VPN edukiontziak IP birbidalketa behar du, eta bezero multzora, aplikazioaren helbidera eta aurreikusitako portura mugatutako birbidalketa erabakia. Ezarritako erantzunek beren baimena behar dute. Jatorrizko tuneleko helbidearekin bat egiten duen arauak ez du bat egingo DNAT ondoren, helburua jada aldatu delako. INPUT baimena kako okerra da ostalari honi jada zuzentzen ez zaion trafikoarentzat.
Mantendu esparrua estua: jatorri tarte bat, helburu bat, zerbitzu bat. Birbidalketa arau permisiboa errazagoa da idazten eta askoz zailagoa gero defendatzen.
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
Dockerren kateak ez dira zure edukiontziaren kateak
Edukiontziaren izen-espazioaren barruko arauak ez dira Docker ostalariaren arauak. Trafikoa tuneleko interfazetik zubira igarotzen denean, ostalariaren zubiko suebakiak beste erabaki bat har dezake. Dockerren iptables motorrarekin, dokumentatutako birbidalketa kateak eta DNAT osteko bat-etortze puntuak dira erabaki hori agertzen den tokia.
Docker suebaki erreferentzia kate horiek eta DNAT osteko bat-etortzea deskribatzen ditu. Ez konpondu falta den onarpen bat Dockerren suebaki kudeaketa desgaituta edo kate guztiak permisibo eginez, horrek erabili nahi duzun muga kentzen baitu.
Egin itzulera bidea borondatezko aukera
Jatorri helbidea mantentzen bada, aplikazioak 10.90.0.x ikusten du eta erantzunak VPN edukiontzitik itzuli behar ditu. Bestela, bere Docker atebide arruntak ostalarira bidaliko ditu, eta hark ez du tunela bere gain. Alternatiba VPN edukiontziko jatorri itzulpen estua da, erantzuna sinplifikatzen duena baina bezeroa aplikaziotik ezkutatzen duena. Aukeratu nahita eta idatzi zein aukeratu duzun.
Probatu bezero arrunt batetik baimendutako konexio berri bat, eta gero egiaztatu erlazionatutakoak ez diren portuak itxita jarraitzen dutela. Pakete bat desagertzen denean, aztertu VPN izen-espazioa, aplikazioaren izen-espazioa eta aplikazioaren beraren erregistroa. Zubiko atebidera ping egitea ez da zerbitzuaren onarpen proba.
Mantendu arauak edukiontziaren onartutako abiarazte konfigurazioan, edizio interaktiboak desagertzen baitira birsortzen denean. Ostalariaren portu argitalpena esposizio bide desberdina da eta ez da beharrezkoa zerbitzua tuneletik irisgarria delako soilik.