Docker edukiontzien trafikoak hostaren VPN-a saihesten du: nola egiaztatu
Hostaren VPN-ak hostaren izen-espazioa baino ez du estaltzen. Egiaztapen hauekin jakingo duzu zubiko edukiontzien trafikoak tunelera sartzen den edo zuzenean irteten den.
Hostaren nabigatzaileak VPN-aren irteera helbidea erakusten du, edukiontziak zure etxeko konexioa jakinarazten du, eta norbaitek ihesa deitzen dio. Ez da ezer ihes egin. Hostaren tunela hostaren sare-izen-espazioari dagozkion interfaze, ibilbide eta arauen multzoa da, eta zubiko edukiontzia beste izen-espazio bat da, bere ibilbide lehenetsiarekin. Compose pila batean egon naiz, non VPN bezeroa asteak konektatuta egon zen eta edukiontziko pakete bakar bat ere ez zen inoiz sartu.
Egiaztatu izen-espazioa erretiluaren ikonoa baino lehen
Izen-espazioak dira argudio osoa. Dockerrek zubi-sare batean edukiontzi bat abiarazten duenean, sare-izen-espazio bat sortzen du, veth pare baten mutur bat bertan konektatzen du, eta izen-espazio horri helbide bat eta ibilbide lehenetsi bat ematen dizkio. Tunelaren interfazea, edozein izena izanik ere, hostaren izen-espazioan bizi da. Edukiontziaren barneko trafikoak ezin du ikusi, eta bezeroaren ezarpen batek ere ez du hori kanpotik aldatzen.
Bi mugimendu onartuk ateratzen zaituzte isolamendutik. --network host edukiontzia hostaren izen-espazioaren barruan jartzen du, beraz hostaren ibilbideak eta, ondorioz, tunela heredatzen ditu. --network container:vpn beste edukiontzi baten izen-espazioa partekatzen du, eta horrela bidaltzen dute sidecar diseinu gehienek karga-lan bat VPN edukiontzi batetik. Biak dira aukera esplizituak; normalean horietako bat baino ez da inplementatzen ari den pertsonak nahi zuena.
Host modua ez da doako hobekuntza. Edukiontziak bere helbidea izateari uzten dio, portuen argitalpena ez da aplikatzen, eta bertan NET_ADMIN duen prozesu batek hostaren bideratzea berridatz dezake. Hori onartzea erabaki zuzena izan daiteke. Dagoeneko aktibatuta dagoela suposatzea da jendeak arratsalde bat tunel bat arazten igarotzeko modua, inoiz bidean egon ez zena.
Jarraitu paketeari zubitik kanpo
Zubiko edukiontzi batek bere paketea bere ate lehenetsira bidaltzen du, hau da, hostaren zubi-interfazea. Gero hostak paketea birbidaltzen du eta, konfigurazio lehenetsian, iturburu-helbidea bere helbidera itzultzen du paketea irten aurretik. Itzulpen-urrats hori da politika isilki gainditzen duena.
Paketea tunelaren amaierako puntura iristen denerako, hostaren helbidea darama. Edukiontziaren jatorrizko helbidean oinarritutako edozein arau, politika-ibilbide edo tunel zatituaren erabakik bat egiteari uzten dio, eta irteera ezberdinetatik irtetea zuten bi edukiontzi ezin dira soilik iturriaren arabera bereizi. Edukiontzi bakoitzeko bideratzea behar baduzu, erabakia itzulpenaren aurretik edo kontrolatzen duzun izen-espazio baten barruan hartu behar da.
Dockerrek berak mantentzen ditu arau hauek, daemona konfiguratu zen suebaki-backend edozein dela ere. Eskuz idatzitako arauak birbidalitako trafikoarentzako onartutako kakoaren kanpoan, DOCKER-USER, berrantolatu edo baztertu daitezke daemona berrabiarazten denean edo hosta eguneratzen denean. Dockerren pakete-iragazpenari buruzko dokumentazioak kateen ordena erakusten du; puntu praktikoa da arau bakoitzak jabe bat eta benetan probatu duzun birkarga-bide bat behar dituela.
Probatu bi sistemak bereizita
Izen-espazio bateko frogek ez dute besteaz ezer esaten. VPN edukiontziaren barruan exekutatutako eskaera batek frogatzen du tunela edukiontzi horretarako funtzionatzen duela. Ez da hostaren froga, eta --network host edukiontzi batetik exekutatutako komando bera ez da zubiaren froga.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Ondoren errepikatu proba aplikazioaren benetako edukiontzian, antzeko irudi batean beharrean. Aplikazioak ibilbide gehigarri bat, proxy ingurune-aldagai bat edo beste ebazpen-motor bat eraman dezake, eta horietako bakoitzak erantzuna aldatzen du. Egiaztatu izenen ebazpena eta bigarren helbide-familia aldi bakoitzean: erabiltzaileak definitutako zubietako edukiontziak Dockerren barneko ebazpen-motorraren bidez ebazten dira 127.0.0.11 helbidean, eta zubiko IPv6 ibilbide lehenetsi batek trafikoa kanpora atera dezake IPv4 soilik den tunel bat probatzen ari zaren bitartean.
Irakurri eredua kredentzialak ukitu aurretik
Hosta funtzionatzen duenean eta edukiontziak ez, kausa egiturazkoa izaten da ia beti, eta gakoak biratzeak edo bezeroa berrinstalatzeak arratsalde bat galtzen du. Sailkatu lehenik sintoma, eta konponbideak normalean bere burua izendatzen du.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
Gainjartze-errenkadak bere esaldi propioa merezi du. 172.17.0.0/16rako ibilbide bat bultzatzen duen VPN profil batek, edo zure zubi-prefixoa kasualitatez biltzen duen 10.0.0.0/8 baterakoa, tunelak edukiontziaren azpisarea aldarrikatzea eragiten du, eta itzulitako helbideetara joango diren erantzunek norabide okerra hartuko dute edo desagertu egingo dira. Docker sarea berriz zenbakitzea errazagoa izaten da salbuespenak pilatzea baino.
Egin estaldura esplizitua, eta gero hautsi nahita
Bi diseinuk gainditzen dute berrikuspena. Partekatu VPN edukiontziaren izen-espazioa eta estalitako karga-lan bakoitzak tunel bakarra erabiltzen du berrabiarazte-muga bakarrarekin, eta hori erraza da zerbitzu batek beste irteera bat edo bere DNS bidea behar duen arte. Edo bideratu edukiontzien sarea hostaren VPN ate batera: birbidaltzea gaituta, zubi-prefixoa tunelera zuzenduta, itzulerako trafikoa modu esplizituan kudeatuta. Horrek sare bakoitzeko kontrola erosten du eta daemon eta bezero eguneraketen zehar mantendu beharreko arau-multzo bat kostatzen dizu.
Edozein modutan, garrantzitsua den proba hutsegite-kasua da. Gelditu tunela edukiontzi eskaera bat hegan dagoela eta begiratu norantz doan paketea. Bide zuzenera itzultzen bada, estaldura ez zen inoiz aplikatu, bezeroaren kill switch batek bezeroaren beraren trafikoa gobernatzen duelako, eta ez zubi batetik birbidalitako paketeak. Berrabiarazi gero daemona eta hosta eta berretsi emaitza bigarren aldiz; orduan desagertzen dira eskuz idatzitako arauak.
Amaitutzat eman aurretik, berretsi lau gauza: tunelaren interfazea trafikoaren izen-espazio berean dago, edukiontziaren proba benetako edukiontziaren barruan exekutatu zen, izenen ebazpena eta bi helbide-familiak egiaztatu ziren, eta tunelaren hutsegite-probak itxita huts egiten du oraindik. Gero idatzi suebaki-backenda, bezeroaren bertsioa eta arau bakoitzaren jabea. Erregistro hori da hurrengo eguneraketak suposizio zaharren nahasketa dokumentatu gabe ez uzteko arrazoia.