Két hálózatú konténer a rossz átjárót választja

Két csatlakozás, egy alapértelmezett útvonal, és a rossz hálózat mindig nyer. Rögzítse a kijáratot a Compose gw_priority beállításával, és ellenőrizze a konténer belsejéből.

A konténer továbbra is a vezérlő hídján válaszol, mégis minden kimenő csomag az irodai macvlanon keresztül távozik. Semmi sem hibázott el. Két csatlakozás ad egy-egy átjárót, és az egyetlen alapértelmezett útvonal ahhoz a hálózathoz került, amelyet nem szánt szándékkal, így a szolgáltatás tovább működik, miközben a forgalma hosszabb utat jár be. Mire valaki észreveszi, a bizonyíték egy útválasztási tábla, nem hibaüzenet.

A szokásos magyarázat, hogy a Docker véletlenül választotta ki a hálózatot. A gyakorlatban a régi döntés a csatlakoztatott hálózatok nevének ábécé-sorrendjét követte, ami az útválasztást egy címke mellékhatásává tette. A gw_priority ezt egy szándékosan választott számmal helyettesíti, és az átvétel körülbelül egy percet vesz igénybe, miután az elrendezés le van írva.

Miért a rossz hálózatra kerül az alapértelmezett útvonal

Minden hálózat, amelyhez egy szolgáltatás csatlakozik, kínálhat saját átjárót, és a konténer mégis pontosan egy alapértelmezett útvonallal végzi. A Compose 2.33.1 előtt a döntetlent a hálózatnevek rendezése oldotta fel, így egy control nevű címke, amely az office előtt jön, határozta meg, hová megy a forgalom. Semmi sem rögzíti a konténeren belül, hogy a döntés önkényes volt, ezért éli túl a kódellenőrzést, és később furcsa útvonalként bukkan fel. A szabályzat compose-fájlba írása az egyetlen módja annak, hogy a választás ellenőrizhető legyen.

Két dolog ténylegesen megváltoztatja, melyik hálózat nyer: a hozzárendelt gw_priority-értékek, és az, hogy egyáltalán mely hálózatok vannak csatlakoztatva. Adjon hozzá egy harmadik hálózatot, és a jelöltek halmaza nő; vegye ki a macvlant, és semmi sem versenyez a híddal. Egyik lépés sem jelenik meg az alkalmazás naplóiban, mert a rossz alapértelmezett útvonal ritkán szakítja meg teljesen a kapcsolatot. Csak azt éri el, hogy a válaszok olyan címről érkezzenek, amelyet a másik fél talán nem vár.

Rögzítse az átjárót a gw_priority beállításával

A Compose a 2.33.1-es verziótól minden szolgáltatás-hálózat csatlakozáson közzéteszi a gw_priorityt, és a legnagyobb szám nyer. Nincs szolgáltatásonkénti átjárókulcs, ezért az érték a szolgáltatás networks blokkjába tartozik. Az alábbi példa a controlnak adja az alapértelmezett útvonalat, miközben az office elérhető marad a közvetlenül csatlakoztatott LAN-ja számára.

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

Olvassa a blokkot két külön vezérlőként: a gw_priority dönt az alapértelmezett útvonalról, az ipam szakasz pedig a címzésről. Ha csak a subnetet módosítja, a kijárat választása érintetlen marad, és ez a leggyakoribb módja annak, hogy ez a javítás félkészen kerül alkalmazásra. Tartsa a prioritásokat az általuk irányított hálózat mellett, hogy a következő olvasónak ne kelljen keresnie a döntést.

Ne keverje össze a gw_priorityt a mellette álló egyszerű priority tulajdonsággal. Az a kapcsolatok létrehozását rendezi, és semmit sem mond az útválasztásról, ezért nem tud alapértelmezett átjárót választani, és nem javítja az interfészneveket. Ha valaki a priority emelését javasolja a forgalom tereléséhez, a javaslat hibás akkor is, ha a kapott sorrend véletlenül helyesnek látszik.

Ellenőrizze, melyik hálózat hordozza valóban az alapértelmezett útvonalat

A futó konténeren belül ellenőrizze, mert a gazdagép útválasztási táblája a gazdagépet írja le, nem azt a névteret, amelyet a szolgáltatás használ. Először futtassa a konfigurációellenőrzést, hogy egy elírás még újraindítás előtt elbukjon, majd olvassa ki az útvonalat, amelyet a konténer ténylegesen telepített.

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

A helyes eredmény a híd eszközét és a 172.30.50.1-et nevezi meg; a hibás a 192.168.120.1-et és a macvlan eszközt. Ha az image nem tartalmaz iproute2 csomagot, a /proc fájl akkor is jelenti az alapértelmezett útvonalat, 00000000 céllal és az átjáró bájtjaival megfordítva. Ha az eszköznevek nem egyértelműek, hasonlítsa össze az interfész oszlopát a docker inspectszel.

A macvlan fizikai port, nem hídklón

A macvlan második identitást ad a konténernek a vezetéken, és éppen ez teszi működőképessé a helyi eszközök elérését. Ez azt is jelenti, hogy a kapcsolóportnak és a hipervizornak el kell fogadnia egy további MAC-címet, és sok felhőhálózat ezt csendben megtagadja. Teszteljen egy konténert, mielőtt flottát tervez, mert az elutasított MAC általában olyan kapcsolatként jelenik meg, amely fent van, és semmit sem enged át.

A macvlan_mode: bridge beállítás a macvlan illesztőprogram egyik módja, nem a Docker szoftveres hídja, a passthru pedig külön, speciális mód, nem alapértelmezés. A Linux azt is megakadályozza, hogy a macvlan konténer elérje a saját gazdagépét ugyanazon a szülőn keresztül, és ez az oka annak, hogy a vezérlőhidat megtartjuk, ahelyett hogy egy csatlakozástól várnánk mindkét feladatot.

Nevezze el a VLAN szülőt, mielőtt a Compose látja

A Docker az eno1.120-hoz hasonló pontozott szülőt 802.1Q al-interfészként kezeli, és maga hozza létre a VLAN eszközt. Ennek a kényelemnek határai vannak: a származtatott név a fizikai interfész nevétől függ, és a hosszú nevek a környező eszközök elvárásain túlra tolhatják az eredményt. Egy elnevezett VLAN interfész létrehozása a gazdagép hálózati konfigurációjában, és a parent ráirányítása kiszámíthatóvá teszi mindkét végét.

Ne feledje, hogy a networks alatti kulcs Compose-név, nem Linux-eszköz. Ha a gazdagépen office nevű interfészt keres, kudarcot vall, mert a kernel csak a szülő interfészt és a konténer mögötti veth párt látja.

Csináljon helyet a VPN-nek fölötte

A VPN-kliens azután csatlakozik, hogy ezek a hálózatok léteznek, így a gw_prioritytól függetlenül adhat hozzá pontosabb útvonalakat, házirendszabályokat és szűrőket. Tervezze a távoli előtagokat mindkét helyi subnethez képest, beleértve a vezérlőútvonal által igényelt válaszokat. Amikor egy távoli előtag átfed az irodai LAN-nal, javítsa a címtervet ahelyett, hogy egy egész privát tartományt kitépne az alagútból.

Ellenőrizze újra a címeket, útvonalakat és a szolgáltatás útját a VPN indulása után, majd még egyszer az újracsatlakozása után, mert az újracsatlakozás az, ahol egy kézzel hozzáadott útvonal eltűnik. Írja fel a várt táblázatot az első teszt előtt, hogy az utána következő összehasonlítás diff legyen, ne memóriagyakorlat. Tartsa a hálózat tartós tulajdonjogát a Compose-ban, és hagyja, hogy a VPN-konfiguráció csak a saját szabályzatát birtokolja.

Kapcsolódó cikkek