Container med to netværk vælger den forkerte gateway

To tilslutninger, én standardrute og det forkerte netværk vinder hver gang. Fastlås udgangen med Compose gw_priority og bekræft det inde fra containeren.

Din container svarer stadig på sin kontrolbro, men hver udgående pakke forlader via kontorets macvlan. Intet er fejlet. To tilslutninger leverer hver deres gateway, og den eneste standardrute gik til det netværk, du ikke havde tænkt på, så tjenesten kører videre, mens dens trafik tager en længere vej. Når nogen opdager det, er beviset en routingtabel og ikke en fejlmeddelelse.

Den sædvanlige forklaring er, at Docker valgte netværket ved et uheld. I praksis fulgte den gamle beslutning den alfabetiske rækkefølge af de tilsluttede netværksnavne, hvilket gjorde routing til en bivirkning af en etiket. gw_priority erstatter det med et tal, du vælger med vilje, og at tage det i brug tager omkring et minut, når layoutet er skrevet ned.

Hvorfor standardruten ender på det forkerte netværk

Hvert netværk, en tjeneste tilslutter sig, kan tilbyde sin egen gateway, og containeren ender alligevel med præcis én standardrute. Før Compose 2.33.1 blev uafgjort afgjort ved at sortere netværksnavnene, så en etiket som control, der kommer før office, bestemte, hvor trafikken gik hen. Intet inde i containeren registrerer, at beslutningen var vilkårlig, og derfor overlever den kodegennemgang og dukker senere op som en mærkelig vej. At lægge en politik i compose-filen er den eneste måde at gøre valget muligt at inspicere.

To ting ændrer reelt, hvilket netværk der vinder: de gw_priority-værdier, du tildeler, og hvilke netværk der overhovedet er tilsluttet. Tilføj et tredje netværk, og kandidatsættet vokser; fjern macvlan, og der er intet tilbage at konkurrere med broen. Ingen af ændringerne ses i applikationsloggen, fordi en forkert standardrute sjældent bryder forbindelsen helt. Den får blot svar til at ankomme fra en adresse, den anden side måske ikke forventer.

Fastlås gatewayen med gw_priority

Compose eksponerer gw_priority på hver tjeneste-til-netværk-tilslutning fra version 2.33.1, og det højeste tal vinder. Der findes ingen gateway-nøgle pr. tjeneste, så værdien hører under tjenestens networks-blok. Eksemplet nedenfor giver standardruten til control, mens office forbliver tilgængeligt for sit direkte tilsluttede 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

Læs blokken som to separate kontroller: gw_priority afgør standardruten, og ipam-afsnittet afgør adresseringen. Ændrer du kun subnet, forbliver udgangsvalget urørt, og det er den mest almindelige måde, denne løsning bliver anvendt halvt. Hold prioriteterne ved siden af det netværk, de styrer, så den næste læser ikke skal lede efter beslutningen.

Forveksl ikke gw_priority med den almindelige priority-egenskab ved siden af. Den ordner oprettelse af forbindelser og siger intet om routing, så den kan ikke vælge en standardgateway og retter ikke interface-navne. Hvis nogen anbefaler at hæve priority for at styre trafikken, er anbefalingen forkert, selv når den resulterende rækkefølge tilfældigvis ser rigtig ud.

Kontroller, hvilket netværk der faktisk bærer standardruten

Kontroller inde i den kørende container, fordi værtens routingtabel beskriver værten og ikke det namespace, tjenesten bruger. Kør først konfigurationskontrollen, så en tastefejl fejler før en genstart, og læs derefter den rute, containeren faktisk installerede.

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

Et korrekt resultat nævner broenheden og 172.30.50.1; et forkert nævner 192.168.120.1 og macvlan-enheden. Hvis imaget ikke indeholder iproute2-pakken, rapporterer /proc-filen stadig standardruten, med destination 00000000 og gateway-bytes omvendt. Sammenlign interface-kolonnen med docker inspect, når enhedsnavnene er uklare.

Macvlan er en fysisk port, ikke en klon af broen

Macvlan giver containeren en anden identitet på kablet, og det er præcis det, der får adgang til lokale enheder til at virke. Det betyder også, at switchporten og hypervisoren skal acceptere en ekstra MAC-adresse, og mange cloud-netværk afviser det stille. Test én container, før du planlægger en flåde, fordi en afvist MAC normalt viser sig som et link, der er oppe og ikke sender noget videre.

Indstillingen macvlan_mode: bridge er en tilstand i macvlan-driveren, ikke Dockers softwarebro, og passthru er en separat specialiseret tilstand og ikke en standard. Linux holder også en macvlan-container fra at nå sin egen vært gennem den samme forælder, og det er grunden til at beholde kontrolbroen i stedet for at forvente, at én tilslutning klarer begge opgaver.

Navngiv VLAN-forælderen, før Compose ser den

Docker behandler en forælder med punktum som eno1.120 som et 802.1Q-underinterface og opretter selv VLAN-enheden. Den bekvemmelighed har grænser: det afledte navn afhænger af det fysiske interface-navn, og lange navne kan skubbe resultatet ud over, hvad værktøjerne omkring forventer. At oprette et navngivet VLAN-interface i værtens netværkskonfiguration og pege parent på det holder begge ender forudsigelige.

Husk, at nøglen under networks er et Compose-navn, ikke en Linux-enhed. At søge efter et interface ved navn office på værten vil fejle, fordi kernen kun ser forældre-interfacet og veth-parret bag containeren.

Gør plads til VPN ovenpå

En VPN-klient tilsluttes, efter at disse netværk findes, så den kan tilføje mere specifikke ruter, politikregler og filtre uanset gw_priority. Planlæg fjernpræfikserne mod begge lokale subnet, inklusive de svar, kontrolvejen har brug for. Når et fjernpræfiks overlapper kontorets LAN, skal adresseplanen rettes i stedet for at rive et helt privat område ud af tunnelen.

Kontroller adresser, ruter og tjenestens vej igen, efter VPN starter, og igen efter det genopretter forbindelsen, fordi en genoprettet forbindelse er der, hvor en håndtilføjet rute forsvinder. Skriv den forventede tabel ned før den første test, så sammenligningen bagefter er en diff og ikke en hukommelsesøvelse. Behold den vedvarende netværksejerskab i Compose, og lad VPN-konfigurationen kun eje sin egen politik.

Relaterede artikler