Docker: bideratu edukiontzi bat VPN bidez eta utzi beste bat zuzenean

Eman tunelari bere edukiontzia, utzi behar duten zerbitzuei soilik espazio-izen hori partekatzen, eta gero kontuan hartu jabearen atzetik datorrena: portuak, localhost, DNS.

Ostalari bat, bi karga-lan eta horiek bereizten dituen baldintza bat: VPN komertzial batetik atera behar duen deskarga bezero bat eta ostalariaren konexioa erabiltzen jarraitu behar duen kudeaketa interfaze bat. VPN bezeroa ostalarian instalatzeak baldintza berehala hausten du, orduan bi karga-lanek irteera bakarra partekatzen dutelako. Benetan funtzionatzen duen eredua tunela bere edukiontzira eramatea da eta behar duten karga-lanei soilik edukiontzi horren sareko espazio-izenarekin bat egitea. Gainerako guztiak Docker-en ohiko bidea mantentzen du, eta ondoren datozen xehetasunak espazio-izena norena denaren ondorioak dira.

Zergatik aldatzen ditu arauak partekatutako espazio-izen batek

Beste baten espazio-izenarekin bat egiten duen edukiontziak ez du bere sare-pila lortzen. Bat egin duen edukiontziaren interfaze berak, bideratze-taula bera eta loopback bera ikusten ditu, eta horrexegatik da erabilgarria eredua: karga-lanak normaltasunez ebazten eta konektatzen du, eta azpiko tunelak trafikoa harrapatzen du aplikazioak jakin gabe. Kostua da sare-ezarpen bakoitzak jabe bakarra duela orain, eta bat egiten duen edukiontzia ez dela hura.

Jabetza-arau horrek konfigurazio-galdera gehienei erantzuten die planteatu aurretik. Ezarpena sare-pilan bizi bada, alboko edukiontziarena da. Prozesua deskribatzen badu, karga-lanarekin geratzen da.

Loopback da jendea harritzen duen zatia. Bat egiten duen edukiontziaren barruan, localhost alboko edukiontziaren loopback-era ebazten da, ez bere propio pribatu batera, beraz 127.0.0.1-ra lotzen den zerbitzu batek isolamendua espero bazuen orain helbide hori tunelaren edukiontziarekin partekatzen du.

Argitaratu portuak espazio-izena duen edukiontzian

Portuen mapaketa espazio-izenaren jabearena da, entzuten ari den prozesua beste edukiontzian exekutatzen denean ere. Adierazi mapaketa alboko edukiontzian, eta utzi karga-lanari bere prozesu-konfigurazioa ukitu gabe. Bat egiten duen zerbitzuko mapaketa batek ezin du indarrean sartu, motorrak baztertu edo isilpean alde batera uzten duen edukiontzia nola abiarazten den arabera, eta horregatik une bat lehenago irisgarria zen interfaze bat desagertzen da eredua aplikatu bezain laster.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Irakurri bloke hori hiru erabaki gisa, hiru zerbitzu gisa baino. Alboko edukiontziak tunela eta argitaratutako portua dauzka; bat egiten duen bezeroak ez du sareik adierazten; zuzeneko bezeroak bere mapaketa propioa gordetzen du sare lehenetsian. Gaitasunak NET_ADMIN uzten dio alboko edukiontziari interfazeak sortzen eta bideak aldatzen, eta hori da edukiontzi honek zerbitzatzen dituen karga-lanek baino pribilegio gehiago behar izatearen arrazoia.

Zuzenean geratzen den zerbitzuak bere sare propioa mantentzen du

Tunelatik pasa behar ez duen karga-lanak zubi lehenetsia edo erabiltzaileak definitutako bere sare propioa mantentzen du, bere argitaratutako portuarekin eta bere irteerarekin. Tentagarria da alboko edukiontziaren sarera konektatzea bi edukiontziek izenez hitz egin ahal izateko, baina pauso bakar horrek isilpean eramaten du bere trafikoa tunelera. Elkarrengana iritsi behar badute, eraiki erabiltzaileak definitutako sare bereizi bat, konektatu biak hara, eta utzi alboko edukiontzia kanporako bide bakarra bezala.

Mantendu bi galderak bereizita: zein edukiontzi irits daitezkeen elkarrengana, eta zeinek nondik irteten duen. Hauek batzea da diseinu hau berriro ostalari osoko VPN bihurtzeko modurik ohikoena.

Hutsegite-matrize bat lehen ordurako

Lehen saiakera gehienek lau moduetako batean huts egiten dute, eta bakoitzak kausa desberdina du. Egiaztatu itzazu ordena honetan, lehen biek ia txosten guztiak azaltzen baitituzte.

SymptomLikely cause
Web UI unreachable after the changePort mapping declared on the joining container instead of the sidecar
Both containers show the provider's exit addressThe direct service was attached to the sidecar network
Internal names stop resolvingResolver settings live on the host, not in the shared namespace
Health check fails but the app worksThe check probes localhost, which now means the sidecar

Laugarren errenkada da jendeak aplikazioaren akats gisa gaizki diagnostikatzen duena. Karga-lanaren bere loopback-aren aurka idatzitako zunda bat tunelaren edukiontzia probatzen ari da orain, beraz edo huts egiten du edo guztiz okerreko zerbitzuaren berri ematen du.

Ostalari-izen bakar batek tunela behar duenean

Batzuetan tunel osoa gehiegizkoa da: barne-izen batek VPN korporatiboa zeharkatu behar du, tokiko socket edo pantaila-konexioak lanean jarraitzen duen bitartean. Edukiontziaren barruko tunel osoak bide hori eta ostalariari zuzendutako guztia hausten du, beraz bideratu behar duen aurrizkia soilik. Klientsaren inguruko bideratze zatituaren bilgarri batek egiten du hori, izendatutako ostalaria tunelatik bidaliz eta aurreko bidea ukitu gabe utziz gainerako guztiarentzat.

Aukeratu hau zerbitzu bakarrera iritsi behar duzunean eta edukiontziaren trafiko guztia mugitzen saiatzen ez zarenean. Alboko edukiontziaren tresna desberdina da eta galdera desberdin bati erantzuten dio.

Egiaztatu, eta gero egin berrabiarazteari aurre egiteko modukoa

Galdetu edukiontzi bakoitzari zein helbidetatik datorrela dirudien. Tunelarena denak hornitzailearen helbidea inprimatu beharko luke eta zuzenekoak ostalariaren irteera. Erantzun berdinak esan nahi du zuzeneko zerbitzuak okerreko espazio-izena heredatu duela edo ostalari mailako VPN batek oraindik dena harrapatzen duela, eta bi konponketa horiek desberdinak dira. Exekutatu egiaztapena berriro compose aldaketa bakoitzaren ondoren, zerbitzu-bloke kopiatu bat nahikoa baita arazoa berriro ekartzeko.

Hiru gauza hautsi ohi dira geroago. DNS espazio-izenaren jabearen atzetik doa, beraz ebazlearen eta bilaketa-domeinuaren ezarpenak alboko edukiontziarenak dira, ez ostalariarenak. Portuak birbidaltzen dituen VPN batek entzute-portua aldatzen du berriro konektatzean, beraz hornitzailearen birbidalitako portua eta edukiontzi aldeko entzute-portua berriro idatzi behar dira bezeroaren konfigurazioan edo portu-mapaketan, normalean hornitzailearen API-a irakurtzen duen eguneratzaile txiki baten bidez. Eta localhost aurka idatzitako edozein zundak tunelaren edukiontziari galdetzen dio orain, ez karga-lanari.

Idatzi eredua, zein edukiontzik duen espazio-izena eta zein portu dagozkion barne. Hurrengo pertsonak zerbitzu bat gehituko du, bloke okerra kopiatuko du eta artikulu honetako lehen hutsegitea errepikatuko du.

Erlazionatutako artikuluak