Docker edukiontzia VPNn irisgaitza? Konparatu azpisareak

Edukiontziek bulegoko LANean erantzuten dute, eta enpresako VPN konektatzen den unean uzten dute erantzuten. Edukiontzian ez da ezer aldatu: ez berrabiarazterik, ez irudi-eguneratzerik, ez konfigurazio-aldaketarik. Aldatu dena hostaren bideratze-taula da, non tunelak gehitutako ibilbide batek Dockerrek emandako helbidea estaltzen duen orain. Azpisare bat editatu edo VPN salbuespen bat eskatu aurretik, jarri bi helbide-planak elkarren ondoan, konponbideek oso denbora desberdinak balio baitituzte.

Irakurri ibilbidea konfigurazioa aldatu aurretik

Hasi Dockerrek benetan eraiki zuen sarearekin. IPAM blokea helbide-plana da, eta azpisarea garrantzia duen lerroa da:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Composek /16 bat esleitzen dio proiektu bakoitzari lehenespenez, beraz bi zerbitzu 65,536 helbideko barruti batean egon daitezke. Zabalera hori da gainjartzeak ohikoak izateko arrazoia: ausaz aukeratutako /16 bat nahikoa da tunelaren bidez iristen zaren gune bat irentsiz, eta inork ez du nabaritzen tunela altxatu arte.

Ondoren, konparatu edukiontzi-helbide baterako ibilbide-hautaketa, behin tunela jaitsita eta behin igota:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Erantzun-forma bik leku desberdinetara eramaten dute. Irteerak tun0, wg0 edo beste tunel-gailu bat aipatzen badu, VPN aurrizki bat zubiaren ibilbidea bezain zehatza da gutxienez, eta paketea ez da inoiz edukiontzira iristen. Oraindik zubia aipatzen badu, hosta edukiontzira irits daiteke, eta zure akatsa iragazketa, DNS edo norabide bakarrean huts egiten duen itzulera-ibilbide bat da.

Zergatik da erraza /16 talka bat jotzea

Dockerrek zubi-sareak igerileku pribatuetatik ateratzen ditu, eta lehenespenezko igerilekua 172.16.0.0/12 bloketik ateratzen da /16 xafletan. Enpresa-sareek sarritan espazio pribatu bera erabiltzen dute, eta urrutiko sarbideko VPN batek aurrizki horiek konektatzen den bezero bakoitzera bultzatzen ditu. Bi aldeek 172.18.0.0/16 dutela uste dutenean, bideratze-taula batek bi aldarrikapen kontrajarri ditu.

Aurrizkiaren luzerak erabakitzen du irabazlea, ez ibilbideak agertzen diren ordenak. 10.0.0.0/8 bultzatzen duen tunel batek 172.18.0.0/16, /8 ez delako hain zehatza, ez dio zubi-ibilbideari irabazten. Beste tunel batek 172.18.0.0/16, edo 172.18.5.0/24 barruan bultzatzen badu, bai. Horregatik gailu eramangarri batek bulegoko sarean funtzionatzen du eta hoteleko Wi-Fi sarean huts egiten du VPN berarekin: bezeroak aurrizki desberdinak jasotzen ditu.

Taula berak gobernatzen du beste norabidea. Barneko host bat behar duen edukiontziak 10.8.4.20 helbidean, paketea bere zubi-atarira bidaltzen du, eta hostak tunelera bideratzen du gero. Bide hori normalean funtzionatzen du hostak NAT egiten duelako, baina huts egiten du alde korporatiboak gailu eramangarriaren VPN helbidea bakarrik onartzen duenean, edo atzeraeran iragazketak erantzun asimetrikoa botatzen duenean.

Konparatu hiru konponbideak

Irteteko hiru bide baino ez daude, eta desberdinak dira norberak nori onarpena eskatu behar dion eta bat aplikatzen ari zaren bitartean zer hausten den.

Berrzenbakitzea da txartelik gabe amai dezakezun konponbide bakarra, eta horregatik idazki gehienak hor gelditzen dira. Merkea da proiektu gazte batean eta garestia migrazio-tresna batek edo gordetako konexio-kate batek helbide literal bat seinalatzen duenean. Zenbatu erreferentzia horiek YAML editatu aurretik, ez ondoren.

Tuneletik salbuestea da erantzunik garbiena gainjartzea zure enpresak benetan daukan barruti batean dagoenean. Geldoena ere bada, eta alferrikakoa da bezeroaren profila aldatu ezin duen kontratista batentzat. Argitaratutako portu batek edo proxy alderantzizko txiki batek eztabaida saihesten du: bezeroak tunelak jada behar bezala bideratzen duen helbide batekin hitz egiten du, eta portu hori baino ez da irisgarria izan behar.

Finkatu barruti bat nahita

Proiektu bakar baterako, deklaratu azpisarea compose fitxategian proiektuak igerileku partekatutik hartzeari uzteko:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Hartu barruti hori zure taldeak daraman erregistro batetik, ez bilatzean aurkitutako adibide batetik. Egiaztatu VPNak bultzatzen dituen aurrizkien, jendeak lan egiten duen etxeko LANen eta host bereko beste edukiontzi-sareen aurka. Gero planifikatu birsorketa, lehendik dagoen sare batek bere azpisare zaharra mantentzen baitu: docker compose down, gero up -d. docker network rm ukatzen du amaiera-puntuak erantsita dauden bitartean, eta fitxategiko edozein ipv4_address sarrerek barruti berriaren barruan egon behar du.

Dockerrek berak sortzen dituen sareetarako, ezarri deabruaren igerileku bat /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

Igerilekua deabrua berrabiarazi ondoren sortutako sareei aplikatzen zaie, eta lehendik dauden zubiek beren helbideak mantentzen dituzte. Hori erosoa eta ahazteko erraza da, beraz tratatu proiektu zahar bat oraindik gainjartzen ari dena norbait bere sarea birsortu arte. Dockerren motorraren sare-dokumentazioa esleipen-arauak deskribatzen ditu, igerilekua berrikuspenean defendatu behar baduzu.

Linux zubiak eta Docker Desktopek desberdin huts egiten dute

Linux host batean, edukiontziak hostaren izen-espazioko zubietan esertzen dira. Taula batek erabakitzen du dena, beraz goiko alderaketa da istorio osoa: irakurri zubiaren ibilbidea, irakurri tunelaren ibilbidea, eta ikusi zein nagusitzen den benetako edukiontzi-helbide baterako.

Docker Desktopek edukiontziak NAT propioa duen VM baten atzean jartzen ditu. Hostak ez du batere ibilbiderik edukiontziaren helbidera; zerbitzura argitaratutako portu baten bidez iristen da, normalean 127.0.0.1 helbidera lotuta. Beraz, VPN bezero batek zerbitzua apurtu dezake azpisareen gainjartzerik gabe, bai VMaren barneko barrutirako ibilbide bat instalatuz, bai loopback trafikoa blokeatuz tunela konektatuta dagoen bitartean. Hostoan ip route get tresnak edukiontziaren helbiderako ibilbiderik ez duela jakinarazten badu, hori espero da, ez da akatsa.

Ondorio praktikoa lehenengo non bilatzen duzun da. Linuxen, hasi bideratze-taulatik. Desktopen, hasi argitaratutako portutik eta VPN bezeroaren suebaki-arauetatik, eta gero egiaztatu VMaren barneko azpisarea tunelak bultzatzen duen zerbaiten kontra egiten duen.

Egiaztatu tunela igota

Berriz konektatu VPN bi aldiz konpondutzat eman aurretik, konektatzean ibilbideak bultzatzen eta deskonektatzean kentzen dituen profil batek behar bezala eman baitu lehen saiakera ondoren. Gero exekutatu bezeroak benetan exekutatzen dituen egiaztapenak:

1. ip route get hostetik, edukiontziaren benetako helbidea erabiliz.
2. Beste edukiontzi batetik egindako eskaera, zerbitzua bera osasuntsu dagoela frogatzeko.
3. curl -sv http://127.0.0.1:8080/ bezerotik tunela igota, gero traceroute -n edukiontziaren helbidera LANeko makinatik.
4. sysctl net.ipv4.conf.all.rp_filter eskaera hostera iristen bada baina erantzuna desagertzen bada.

Azkenik, idatzi hautatutako barrutia hura hautatzeko erabili zenuen erregistro berean, data eta hura daukan proiektuarekin. Hurrengo gainjartzea inork dokumentatu gabeko proiektutik etorriko da, eta defentsa bakarra barrutia nahita erreserbatu zela da, ez ausaz atera zela.