Teie konteiner vastab endiselt oma juhtimissillal, kuid iga väljuv pakett lahkub kontori macvlani kaudu. Miski ei ole nurjunud. Kaks ühendust annavad kumbki oma lüüsi ja ainus vaikimisi marsruut läks võrku, mida te ei kavatsenud, nii et teenus töötab edasi, samal ajal kui selle liiklus läbib pikema tee. Kui keegi seda märkab, on tõendiks marsruutimistabel, mitte veateade.

Tavaline seletus on, et Docker valis võrgu kogemata. Praktikas järgis vana otsus ühendatud võrkude nimede tähestikulist järjekorda, mis muutis marsruutimise sildi kõrvalmõjuks. gw_priority asendab selle numbriga, mille valite meelega, ja sellele üleminek võtab umbes minuti, kui paigutus on kirja pandud.

Miks vaikimisi marsruut maandub valesse võrku

Iga võrk, millega teenus liitub, võib pakkuda oma lüüsi, ja konteineril on ikkagi täpselt üks vaikimisi marsruut. Enne Compose'i versiooni 2.33.1 otsustati viik sorteerides võrkude nimesid, nii et silt nagu control, mis tuleb enne office'i, määras, kuhu liiklus läheb. Miski konteineri sees ei registreeri, et otsus oli meelevaldne, ja seetõttu läbib see koodiülevaatuse ning ilmub hiljem kummalise teena. Poliitika panemine compose-faili on ainus viis muuta valik kontrollitavaks.

Milline võrk võidab, muudavad tõesti kaks asja: gw_priority väärtused, mille määrate, ja see, millised võrgud on üldse ühendatud. Lisage kolmas võrk ja kandidaatide hulk kasvab; eemaldage macvlan ja sillaga pole enam midagi võistelda. Kumbki käik ei ilmu rakenduse logides, sest vale vaikimisi marsruut katkestab ühenduse harva täielikult. See ainult paneb vastused saabuma aadressilt, mida teine pool võib-olla ei oota.

Kinnitage lüüs gw_priority abil

Compose pakub gw_priority igal teenuse-võrgu ühendusel alates versioonist 2.33.1 ja võidab suurem number. Teenusepõhist lüüsi võtit ei ole, seega kuulub väärtus teenuse networks-ploki alla. Allolev näide annab vaikimisi marsruudi controlile, jättes office'i kättesaadavaks selle otse ühendatud LAN-i jaoks.

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

Lugege plokki kahe eraldi juhtimisena: gw_priority otsustab vaikimisi marsruudi ja ipam-osa otsustab adresseerimise. Ainult subneti muutmine jätab väljapääsu valiku puutumata ja see on kõige tavalisem viis, kuidas see parandus pooleldi rakendub. Hoidke prioriteedid selle võrgu kõrval, mida nad juhivad, et järgmine lugeja ei peaks otsust taga ajama.

Ärge ajage gw_priority segi kõrval oleva tavalise priority omadusega. See järjestab ühenduste loomist ega ütle marsruutimise kohta midagi, seega ei saa see valida vaikimisi lüüsi ega paranda liidese nimesid. Kui keegi soovitab liikluse juhtimiseks priority't tõsta, on soovitus vale ka siis, kui tulemuseks olev järjekord juhtub õige välja nägema.

Kontrollige, milline võrk tegelikult vaikimisi marsruuti kannab

Kontrollige jooksva konteineri sees, sest peremeesmasina marsruutimistabel kirjeldab peremeest, mitte nimeruumi, mida teenus kasutab. Käivitage esmalt konfiguratsioonikontroll, et trükiviga nurjuks enne taaskäivitust, ja lugege seejärel marsruut, mille konteiner tegelikult paigaldas.

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

Õige tulemus nimetab sillaseadme ja 172.30.50.1; vale nimetab 192.168.120.1 ja macvlani seadme. Kui kujutis ei sisalda iproute2 paketti, teatab /proc fail ikkagi vaikimisi marsruudi, sihtkohaga 00000000 ja lüüsi baidid pööratud. Kui seadmenimed on ebaselged, võrrelge liidese veergu käsuga docker inspect.

Macvlan on füüsiline port, mitte silla kloon

Macvlan annab konteinerile juhtmel teise identiteedi ja just see teeb kohalike seadmete juurdepääsu toimivaks. See tähendab ka, et kommutaatori port ja hüpervisor peavad nõustuma täiendava MAC-aadressiga ning paljud pilvevõrgud keelduvad sellest vaikselt. Testige ühte konteinerit enne parve planeerimist, sest keeldutud MAC paistab tavaliselt lingina, mis on üleval ja ei lase midagi läbi.

Säte macvlan_mode: bridge on macvlani draiveri režiim, mitte Dockeri tarkvarasild, ja passthru on eraldi spetsialiseeritud režiim, mitte vaikeväärtus. Linux hoiab ka macvlani konteinerit oma peremehele ligi pääsemast sama parent'i kaudu, ja see on põhjus, miks juhtimissild alles jäetakse, selle asemel et oodata, et üks ühendus teeb mõlemad tööd.

Nimetage VLAN-i parent enne, kui Compose seda näeb

Docker käsitleb punktiga parent'i nagu eno1.120 802.1Q alamliidesena ja loob VLAN-seadme ise. Sellel mugavusel on piirid: tuletatud nimi sõltub füüsilise liidese nimest ja pikad nimed võivad lükata tulemuse kaugemale sellest, mida ümbritsevad tööriistad ootavad. Nimega VLAN-liidese loomine peremehe võrgukonfiguratsioonis ja parent'i sinna suunamine hoiab mõlemad otsad etteaimatavana.

Pidage meeles, et networks'i all olev võti on Compose'i nimi, mitte Linuxi seade. Peremehelt office'i nimelise liidese otsimine nurjub, sest kernel näeb ainult parent-liidest ja konteineri taga olevat veth-paari.

Tehke ruumi VPN-ile peal

VPN-klient ühendub pärast seda, kui need võrgud on olemas, seega saab see lisada täpsemaid marsruute, poliitikareegleid ja filtreid sõltumata gw_priority'st. Planeerige kaugprefiksid mõlema kohaliku subneti suhtes, sealhulgas vastused, mida juhtimistee vajab. Kui kaugprefiks kattub kontori LAN-iga, parandage aadressiplaani, selle asemel et tõmmata tunnelist välja terve privaatne vahemik.

Kontrollige aadresse, marsruute ja teenuse teed uuesti pärast VPN-i käivitumist ja veel kord pärast selle taasühendumist, sest just taasühendumisel kaob käsitsi lisatud marsruut. Kirjutage oodatav tabel enne esimest katset üles, et võrdlus pärast seda oleks diff, mitte mäluharjutus. Hoidke püsiv võrguomandiõigus Compose'is ja laske VPN-i konfiguratsioonil omada ainult oma poliitikat.

Seotud artiklid