Bi sare dituen edukiontziak pasabide okerra aukeratzen du

Bi konexio, bide lehenetsi bat eta sare okerra da beti irabazten duena. Finkatu irteera Compose gw_priority erabiliz eta egiaztatu edukiontziaren barrutik.

Zure edukiontziak kontrol-zubiaren bidez erantzuten jarraitzen du, baina irteten duen pakete bakoitza bulegoko macvlan-etik ateratzen da. Ez da ezer hutsegiten ari. Bi konexioek bakoitzak bere pasabidea ematen dute, eta bide lehenetsi bakarra ez zenukeen sarera joan zen, beraz zerbitzuak lanean jarraitzen du bere trafikoak bide luzeagoa hartzen duen bitartean. Norbaitek ohartzen denean, froga bideratze-taula bat da, ez errore-mezu bat.

Ohiko azalpena Dockerrek sareko hautua ustekabean egin zuela da. Praktikan, erabaki zaharrak konektatutako sareen izenen ordena alfabetikoari jarraitzen zion, eta horrek bideratzea etiketa baten alboko efektu bihurtzen zuen. gw_priority-k zuk nahita aukeratutako zenbaki batekin ordezkatzen du, eta hura hartzeak minutu bat inguru eskatzen du diseinua idatzita dagoenean.

Zergatik geratzen den bide lehenetsia sare okerrean

Zerbitzu bat sartzen den sare bakoitzak bere pasabidea eskain dezake, eta edukiontziak bide lehenetsi bakarra izaten du oraindik ere. Compose 2.33.1 baino lehen berdinketa sareen izenak ordenatzean erabakitzen zen, beraz control bezalako etiketa bat office baino lehenago etorri ezkero hark erabakitzen zuen trafikoa norengana joango zen. Edukiontziaren barruan ordeak ez du erregistratzen erabakia arbitrarioa denik, eta horregatik pasatzen da kodea gainbegiratzeaz eta geroago agertzen da bide arraro gisa. Hori ikusgai jartzeko modu bakarra politika compose fitxategian jartzea da.

Bi gauzak aldatzen dute benetan zein sare irabazten duen: esleitzen dituzun gw_priority balioek eta, oro har, zein sare dauden konektatuta. Gehitu hirugarren sare bat eta hautagai-multzoa hazten da; kendu macvlan-a eta ez da ezer geratzen zubiarekin lehiatzeko. Ez bi mugimenduetako batek ere ez du agerpenik aplikazioaren erregistroetan, bide lehenetsi okerra oso gutxitan hausten baitu konexioa erabat. Beste aldeak agian espero ez duen helbide batetik etor daitezen egiten du soilik.

Finkatu pasabidea gw_priority erabiliz

Compose-k gw_priority erakusten du zerbitzu-sare konexio bakoitzean 2.33.1 bertsiotik, eta zenbaki handienak irabazten du. Ez dago zerbitzu bakoitzeko pasabide-gakorik, beraz balioa zerbitzuaren networks blokean doa. Beheko adibideak bide lehenetsia control-i ematen dio, office bere LAN zuzenean konektatuan eskuragarri utziz.

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

Irakurri blokea bi kontrol bereizitzat: gw_priority-k bide lehenetsia erabakitzen du eta ipam atalak helbideratzea. Subnet-a soilik aldatzeak irteerako hautua ukitu gabe uzten du, eta hori da konponketa hau erdizka aplikatzeko modurik ohikoena. Eutsi lehentasunei gobernatzen duten sarearen ondoan, hurrengo irakurleak erabakiaren bila ibili behar ez dezan.

Ez nahastu gw_priority alboan duen priority propietate soilarekin. Hark konexioen sorrera ordenatzen du eta ez du ezer esaten bideratzeaz, beraz ezin du pasabide lehenetsirik aukeratu eta ez ditu interfazeen izenak konpontzen. Norbaitek trafikoa zuzentzeko priority igotzea gomendatzen badu, gomendioa okerra da, ondoriozko ordena kasualitatez zuzena dirudien arren.

Egiaztatu zein sarek daraman benetan bide lehenetsia

Egiaztatu exekuzioan dagoen edukiontziaren barruan, ostalariaren bideratze-taulak ostalaria deskribatzen baitu, eta ez zerbitzuak erabiltzen duen izen-espazioa. Exekutatu lehenago konfigurazioaren egiaztapena, tipografia-errore batek berrabiarazi aurretik huts egin dezan, eta gero irakurri edukiontziak benetan instalatutako bidea.

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

Emaitza zuzenak zubi-gailua eta 172.30.50.1 aipatzen ditu; okerrak 192.168.120.1 eta macvlan gailua. Irudiak iproute2 paketerik ez badu, /proc fitxategiak bide lehenetsia jakinarazten du oraindik, helmuga 00000000 eta pasabidearen byteak alderantziz jarrita. Konparatu interfazearen zutabea docker inspect-ekin gailuen izenak argiak ez direnean.

Macvlan ataka fisikoa da, ez zubiaren klon bat

Macvlan-ek edukiontziari kablean bigarren identitatea ematen dio, eta horrexek egiten du posible tokiko gailuetarako sarbidea. Baita esan nahi du kommutadorearen atakak eta hiperbisoreak MAC helbide gehigarri bat onartu behar dutela, eta hodeiko sare askok isil-isilik ukatzen dute. Probatu edukiontzi bat flota planifikatu aurretik, ukatuako MAC bat normalean gorago dagoen eta ezer pasatzen ez duen esteka gisa agertzen baita.

macvlan_mode: bridge ezarpena macvlan kontrolatzailearen modu bat da, ez Dockerren software-zubia, eta passthru modu espezializatu bereizia da, ez lehenetsia. Linux-ek macvlan edukiontziari bere ostalarira iristea ere eragozten dio guraso beraren bidez, eta horregatik manten da kontrol-zubia, konexio bakar batek bi zereginak egingo dituela espero ordez.

Izena eman VLAN gurasoari Compose-k ikusi aurretik

Docker-ek eno1.120 bezalako puntua duen gurasoa 802.1Q azpi-interfaze gisa tratatzen du eta VLAN gailua bera sortzen du. Erosotasun horrek mugak ditu: eratorritako izena interfaze fisikoaren izenaren mende dago, eta izen luzeek emaitza inguruko tresnek espero dutenetik haratago bulta dezakete. Ostalariaren sare-konfigurazioan izena duen VLAN interfazea sortzeak eta parent hara bideratzeak bi muturrak aurreikusteko moduan uzten ditu.

Gogoratu networks azpiko gakoa Compose izena dela, ez Linux gailua. Ostalarian office izeneko interfazea bilatzeak huts egingo du, kermenak guraso-interfazea eta edukiontziaren atzeko veth bikotea baino ez baititu ikusten.

Egin leku VPN-arentzat gainean

VPN bezero bat sare hauek existitzen diren ondoren konektatzen da, beraz bide zehatzagoak, politika-arauak eta iragazkiak gehi ditzake gw_priority-ren arabera izan gabe. Planifikatu urruneko aurrizkiak bi subnet lokalekin alderatuta, kontrol-bideak behar dituen erantzunak barne. Urruneko aurrizki bat bulegoko LAN-arekin gainjartzen denean, zuzendu helbide-plana tunelatik barruti pribatu oso bat erauzi beharrean.

Berrikusi helbideak, bideak eta zerbitzuaren bidea VPN-a abiarazi ondoren eta berriro konektatu ondoren, berriro konektatzean desagertzen baita eskuz gehitutako bidea. Idatzi espero den taula lehen probaren aurretik, ondorengo konparazioa diff bat izan dadin eta ez memoria-ariketa bat. Eutsi sarearen jabego iraunkorrari Compose-n eta utzi VPN konfigurazioari bere politika propioa soilik edukitzen.

Erlazionatutako artikuluak