Kontajner s dvoma sieťami volí nesprávnu bránu

Váš kontajner stále odpovedá na svojom riadiacom moste, ale každý odchádzajúci paket odchádza cez kancelársky macvlan. Nič nezlyhalo. Dve pripojenia dodávajú každé vlastnú bránu a jediná predvolená trasa išla do siete, ktorú ste nemali v úmysle, takže služba ďalej funguje, kým jej premávka ide dlhšou cestou. Keď si to niekto všimne, dôkazom je smerovacia tabuľka a nie chybová správa.

Zvyčajné vysvetlenie je, že Docker vybral sieť omylom. V praxi sa staré rozhodnutie riadilo abecedným poradím názvov pripojených sietí, čo zo smerovania urobilo vedľajší efekt menovky. gw_priority to nahrádza číslom, ktoré si vyberáte zámerne, a prechod naň zaberie asi minútu, keď je rozloženie zapísané.

Prečo predvolená trasa skončí v nesprávnej sieti

Každá sieť, ku ktorej sa služba pripojí, môže ponúknuť vlastnú bránu, a kontajner aj tak skončí s presne jednou predvolenou trasou. Pred Compose 2.33.1 sa nerozhodný stav riešil triedením názvov sietí, takže označenie ako control, ktoré prichádza pred office, určovalo, kam premávka pôjde. Nič vnútri kontajnera nezaznamenáva, že rozhodnutie bolo ľubovoľné, a preto prejde revíziou kódu a neskôr sa vynorí ako zvláštna cesta. Uloženie politiky do súboru compose je jediný spôsob, ako urobiť voľbu preskúmateľnou.

Ktorá sieť vyhrá, skutočne menia dve veci: hodnoty gw_priority, ktoré priradíte, a to, ktoré siete sú vôbec pripojené. Pridajte tretiu sieť a množina kandidátov rastie; odstráňte macvlan a nezostane nič, čo by mostu konkurovalo. Ani jeden z krokov sa neobjaví v protokoloch aplikácie, pretože nesprávna predvolená trasa málokedy preruší spojenie úplne. Len spôsobí, že odpovede prichádzajú z adresy, ktorú druhá strana možno nečaká.

Pripnite bránu pomocou gw_priority

Compose sprístupňuje gw_priority na každom pripojení služby k sieti od verzie 2.33.1 a vyhráva najvyššie číslo. Kľúč brány pre službu neexistuje, takže hodnota patrí do bloku networks danej služby. Nižšie uvedený príklad odovzdáva predvolenú trasu sieti control, pričom office zostáva dostupná pre svoju priamo pripojenú 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

Čítajte blok ako dve oddelené ovládania: gw_priority určuje predvolenú trasu a časť ipam určuje adresovanie. Zmena iba subnetu ponechá voľbu východu nedotknutú, a to je najčastejší spôsob, akým sa táto oprava aplikuje na polovicu. Držte priority vedľa siete, ktorú riadia, aby ich ďalší čitateľ nemusel hľadať.

Nezamieňajte gw_priority s obyčajnou vlastnosťou priority vedľa. Tá zoraďuje vytváranie spojení a o smerovaní nehovorí nič, takže nemôže vybrať predvolenú bránu a neopravuje názvy rozhraní. Ak niekto odporúča zvýšiť priority, aby nasmeroval premávku, odporúčanie je nesprávne, aj keď výsledné poradie náhodou vyzerá správne.

Overte, ktorá sieť skutočne nesie predvolenú trasu

Kontrolujte vnútri bežiaceho kontajnera, pretože smerovacia tabuľka hostiteľa opisuje hostiteľa a nie menný priestor, ktorý služba používa. Najprv spustite kontrolu konfigurácie, aby preklep zlyhal pred reštartom, a potom prečítajte trasu, ktorú kontajner naozaj nainštaloval.

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

Správny výsledok uvádza mostové zariadenie a 172.30.50.1; nesprávny uvádza 192.168.120.1 a zariadenie macvlan. Ak obraz neobsahuje balík iproute2, súbor /proc aj tak hlási predvolenú trasu, s cieľom 00000000 a bajtmi brány obrátene. Keď sú názvy zariadení nejasné, porovnajte stĺpec rozhrania s docker inspect.

Macvlan je fyzický port, nie klon mosta

Macvlan dáva kontajneru druhú identitu na kábli a práve to umožňuje prístup k miestnym zariadeniam. Znamená to tiež, že port prepínača a hypervizor musia prijať ďalšiu MAC adresu, a mnohé cloudové siete to ticho odmietajú. Otestujte jeden kontajner, kým naplánujete flotilu, pretože odmietnutá MAC sa zvyčajne prejaví ako spoj, ktorý je hore a nič neprepúšťa.

Nastavenie macvlan_mode: bridge je režim ovládača macvlan, nie softvérový most Dockeru, a passthru je samostatný špecializovaný režim a nie predvolená hodnota. Linux tiež bráni kontajneru macvlan dosiahnuť vlastného hostiteľa cez toho istého rodiča, a to je dôvod ponechať riadiaci most namiesto očakávania, že jedno pripojenie zvládne obe úlohy.

Pomenujte rodiča VLAN skôr, než ho Compose uvidí

Docker považuje rodiča s bodkou ako eno1.120 za podrozhranie 802.1Q a zariadenie VLAN vytvorí sám. Táto výhoda má hranice: odvodený názov závisí od názvu fyzického rozhrania a dlhé názvy môžu výsledok vytlačiť za to, čo okolité nástroje očakávajú. Vytvorenie pomenovaného rozhrania VLAN v konfigurácii siete hostiteľa a nasmerovanie parent naň udrží oba konce predvídateľné.

Pamätajte, že kľúč pod networks je názov Compose, nie linuxové zariadenie. Hľadanie rozhrania s názvom office na hostiteľovi zlyhá, pretože jadro vidí iba rodičovské rozhranie a pár veth za kontajnerom.

Urobte miesto pre VPN navrchu

Klient VPN sa pripojí po tom, čo tieto siete existujú, takže môže pridať konkrétnejšie trasy, pravidlá politiky a filtre bez ohľadu na gw_priority. Plánujte vzdialené prefixy voči obom miestnym subnetom, vrátane odpovedí, ktoré riadiaca cesta potrebuje. Keď sa vzdialený prefix prekrýva s kancelárskou LAN, opravte plán adries namiesto vytrhnutia celého privátneho rozsahu z tunela.

Znova skontrolujte adresy, trasy a cestu služby po štarte VPN a ešte raz po jej opätovnom pripojení, pretože práve pri opätovnom pripojení zmizne ručne pridaná trasa. Zapíšte očakávanú tabuľku pred prvým testom, aby následné porovnanie bolo diffom a nie cvičením pamäti. Držte trvalé vlastníctvo siete v Compose a nechajte konfiguráciu VPN vlastniť len jej vlastnú politiku.