Vaš vsebnik se še vedno odziva na svojem nadzornem mostu, a vsak odhodni paket zapusti omrežje skozi pisarniški macvlan. Nič ni odpovedalo. Dve priključitvi ponujata vsaka svoja vrata, edina privzeta pot pa je šla v omrežje, ki ga niste nameravali, zato storitev deluje naprej, medtem ko njena komunikacija ubira daljšo pot. Ko to kdo opazi, je dokaz usmerjevalna tabela in ne sporočilo o napaki.

Običajna razlaga je, da je Docker omrežje izbral po naključju. V praksi je stara odločitev sledila abecednemu vrstnemu redu imen priključenih omrežij, kar je usmerjanje spremenilo v stranski učinek oznake. gw_priority to nadomesti s številom, ki ga izberete namerno, in prevzem traja približno minuto, ko je postavitev zapisana.

Zakaj privzeta pot pristane v napačnem omrežju

Vsako omrežje, ki se mu storitev pridruži, lahko ponudi svoja vrata, vsebnik pa ima na koncu natanko eno privzeto pot. Pred Compose 2.33.1 se je neodločeno reševalo z razvrščanjem imen omrežij, zato je oznaka, kot je control, ki pride pred office, določala, kam bo šla komunikacija. Nič znotraj vsebnika ne zabeleži, da je bila odločitev samovoljna, zato prestane pregled kode in se pozneje pojavi kot nenavadna pot. Zapis politike v datoteko compose je edini način, da postane izbira preverljiva.

Katero omrežje zmaga, resnično spreminjata dve stvari: vrednosti gw_priority, ki jih dodelite, in katera omrežja so sploh priključena. Dodajte tretje omrežje in nabor kandidatov se poveča; odstranite macvlan in mostu ne ostane ničesar za konkurenco. Nobena poteza se ne pokaže v dnevnikih aplikacije, ker napačna privzeta pot le redko popolnoma prekine povezavo. Le poskrbi, da odgovori prihajajo z naslova, ki ga druga stran morda ne pričakuje.

Pritrdite vrata z gw_priority

Compose izpostavi gw_priority na vsaki priključitvi storitve na omrežje od različice 2.33.1 in zmaga najvišje število. Ključa vrat za posamezno storitev ni, zato vrednost spada v blok networks te storitve. Spodnji primer preda privzeto pot controlu, office pa ostane dosegljiv za svoj neposredno povezani LAN.

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

Blok berite kot dva ločena nadzora: gw_priority odloči o privzeti poti, odsek ipam pa o naslavljanju. Če spremenite samo subnet, izbira izhoda ostane nedotaknjena, in to je najpogostejši način, da se ta popravek uporabi na pol. Prioritetnosti hranite ob omrežju, ki ga upravljajo, da naslednjemu bralcu ne bo treba iskati odločitve.

Ne zamenjujte gw_priority z navadno lastnostjo priority ob njej. Ta razvršča ustvarjanje povezav in ne pove ničesar o usmerjanju, zato ne more izbrati privzetih vrat in ne popravi imen vmesnikov. Če kdo priporoča dvig priority za usmerjanje prometa, je priporočilo napačno, tudi ko je dobljeni vrstni red po naključju videti pravilen.

Preverite, katero omrežje v resnici nosi privzeto pot

Preverite znotraj delujočega vsebnika, ker usmerjevalna tabela gostitelja opisuje gostitelja in ne imenskega prostora, ki ga uporablja storitev. Najprej zaženite preverjanje konfiguracije, da tipkarska napaka odpove pred ponovnim zagonom, nato preberite pot, ki jo je vsebnik dejansko namestil.

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

Pravilen rezultat navaja mostno napravo in 172.30.50.1; napačen navaja 192.168.120.1 in napravo macvlan. Če slika ne vsebuje paketa iproute2, datoteka /proc še vedno poroča privzeto pot, s ciljem 00000000 in bajti vrat obrnjenimi. Primerjajte stolpec vmesnika z docker inspect, ko imena naprav niso jasna.

Macvlan je fizična vrata, ne klon mostu

Macvlan da vsebniku drugo identiteto na kablu in prav to omogoči dostop do lokalnih naprav. Pomeni tudi, da morata vrata stikala in hipervizor sprejeti dodatni naslov MAC, in mnoga omrežja v oblaku to tiho zavrnejo. Preizkusite en vsebnik, preden načrtujete floto, ker se zavrnjen MAC običajno pokaže kot povezava, ki je gor in ne spusti ničesar skozi.

Nastavitev macvlan_mode: bridge je način gonilnika macvlan, ne Dockerjev programski most, passthru pa je ločen specializiran način in ne privzeta vrednost. Linux tudi prepreči, da bi vsebnik macvlan dosegel svojega gostitelja prek istega nadrejenega vmesnika, zato nadzorni most ostane, namesto da bi pričakovali, da bo ena priključitev opravila obe nalogi.

Poimenujte nadrejeni VLAN, preden ga Compose vidi

Docker obravnava nadrejenega s piko, kot je eno1.120, kot podvmesnik 802.1Q in napravo VLAN ustvari sam. Ta priročnost ima meje: izpeljano ime je odvisno od imena fizičnega vmesnika, dolga imena pa lahko potisnejo rezultat onkraj tega, kar pričakujejo okoliška orodja. Če v omrežni konfiguraciji gostitelja ustvarite poimenovan vmesnik VLAN in parent usmerite nanj, ostaneta oba konca predvidljiva.

Ne pozabite, da je ključ pod networks ime Compose in ne naprava Linux. Iskanje vmesnika z imenom office na gostitelju bo spodletelo, ker jedro vidi le nadrejeni vmesnik in par veth za vsebnikom.

Naredite prostor za VPN na vrhu

Odjemalec VPN se priključi po tem, ko ta omrežja obstajajo, zato lahko doda natančnejše poti, pravila politike in filtre ne glede na gw_priority. Načrtujte oddaljene predpone glede na oba lokalna subneta, vključno z odgovori, ki jih potrebuje nadzorna pot. Ko se oddaljena predpona prekriva s pisarniškim LAN, popravite načrt naslovov, namesto da bi iz tunela iztrgali celoten zasebni razpon.

Ponovno preverite naslove, poti in pot storitve po zagonu VPN in še enkrat po ponovni povezavi, ker prav pri ponovni povezavi izgine ročno dodana pot. Zapišite pričakovano tabelo pred prvim preizkusom, da bo primerjava pozneje diff in ne vaja spomina. Ohranite trajno lastništvo omrežja v Compose in pustite, da ima konfiguracija VPN le svojo politiko.

Sorodni članki