Container met twee netwerken kiest de verkeerde gateway

Twee aansluitingen, één standaardroute, en het verkeerde netwerk wint steeds. Zet de uitgang vast met Compose gw_priority en controleer het van binnenuit de container.

Uw container antwoordt nog steeds op zijn controlebrig, maar elk uitgaand pakket verlaat het netwerk via de kantoor-macvlan. Niets is uitgevallen. Twee aansluitingen leveren elk een gateway, en de enige standaardroute ging naar het netwerk dat u niet bedoelde, dus de dienst blijft werken terwijl het verkeer een langere weg neemt. Tegen de tijd dat iemand het merkt, is het bewijs een routetabel en geen foutmelding.

De gebruikelijke verklaring is dat Docker het netwerk per ongeluk koos. In de praktijk volgde de oude beslissing de alfabetische volgorde van de aangesloten netwerknamen, waardoor routering een neveneffect van een label werd. gw_priority vervangt dat door een getal dat u bewust kiest, en overstappen kost ongeveer een minuut zodra de indeling opgeschreven is.

Waarom de standaardroute op het verkeerde netwerk belandt

Elk netwerk waar een dienst lid van wordt kan zijn eigen gateway bieden, en de container houdt toch precies één standaardroute. Vóór Compose 2.33.1 werd de gelijkstand beslecht door de netwerknamen te sorteren, dus een label als control dat vóór office komt bepaalde waar het verkeer heen ging. Niets in de container legt vast dat de beslissing willekeurig was, en daarom overleeft ze de codereview en duikt later op als een vreemde route. Een beleid in het compose-bestand zetten is de enige manier om de keuze controleerbaar te maken.

Twee dingen veranderen echt welk netwerk wint: de gw_priority-waarden die u toekent, en welke netwerken überhaupt zijn aangesloten. Voeg een derde netwerk toe en de kandidatenverzameling groeit; haal de macvlan weg en er is niets meer dat met de brug concurreert. Geen van beide ingrepen verschijnt in applicatielogs, omdat een verkeerde standaardroute een verbinding zelden helemaal breekt. Ze zorgt er alleen voor dat antwoorden aankomen vanaf een adres dat de andere kant misschien niet verwacht.

Zet de gateway vast met gw_priority

Compose biedt gw_priority sinds versie 2.33.1 aan op elke dienst-naar-netwerk-aansluiting, en het hoogste getal wint. Er is geen gateway-sleutel per dienst, dus de waarde hoort onder het networks-blok van de dienst. Het voorbeeld hieronder geeft de standaardroute aan control terwijl office bereikbaar blijft voor zijn direct aangesloten 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

Lees het blok als twee afzonderlijke regelaars: gw_priority bepaalt de standaardroute en het ipam-deel bepaalt de adressering. Alleen het subnet wijzigen laat de uitgangskeuze ongemoeid, en dat is de meest voorkomende manier waarop deze correctie half wordt toegepast. Houd de prioriteiten naast het netwerk dat ze besturen, zodat de volgende lezer de beslissing niet hoeft te zoeken.

Verwar gw_priority niet met de gewone priority-eigenschap ernaast. Die ordent het aanmaken van verbindingen en zegt niets over routering, dus ze kan geen standaardgateway kiezen en lost geen interfacenamen op. Als iemand aanraadt priority te verhogen om verkeer te sturen, is dat advies onjuist, zelfs wanneer de resulterende volgorde toevallig correct lijkt.

Controleer welk netwerk de standaardroute werkelijk draagt

Controleer in de draaiende container, want de routetabel van de host beschrijft de host en niet de naamruimte die de dienst gebruikt. Voer eerst de configuratiecontrole uit zodat een typefout vóór een herstart faalt, en lees daarna de route die de container werkelijk installeerde.

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

Een correct resultaat noemt het brugapparaat en 172.30.50.1; een verkeerd resultaat noemt 192.168.120.1 en het macvlan-apparaat. Als de image geen iproute2-pakket bevat, meldt het /proc-bestand toch de standaardroute, met bestemming 00000000 en de gateway-bytes omgekeerd. Vergelijk de interfacekolom met docker inspect wanneer de apparaatnamen onduidelijk zijn.

Macvlan is een fysieke poort, geen kloon van de brug

Macvlan geeft de container een tweede identiteit op de kabel, en dat is precies wat toegang tot lokale apparaten laat werken. Het betekent ook dat de switchpoort en de hypervisor een extra MAC-adres moeten accepteren, en veel cloudnetwerken weigeren dat stilzwijgend. Test één container voordat u een vloot plant, want een geweigerd MAC-adres verschijnt meestal als een link die omhoog staat en niets doorlaat.

De instelling macvlan_mode: bridge is een modus van het macvlan-stuurprogramma, niet de softwarebrug van Docker, en passthru is een aparte gespecialiseerde modus en geen standaard. Linux houdt een macvlan-container er ook van af zijn eigen host te bereiken via dezelfde ouder, en dat is de reden om de controlebrig te behouden in plaats van te verwachten dat één aansluiting beide taken doet.

Noem de VLAN-ouder voordat Compose hem ziet

Docker behandelt een ouder met een punt zoals eno1.120 als een 802.1Q-subinterface en maakt het VLAN-apparaat zelf aan. Dat gemak heeft grenzen: de afgeleide naam hangt af van de naam van de fysieke interface, en lange namen kunnen het resultaat voorbij de verwachtingen van de omringende gereedschappen duwen. Een benoemde VLAN-interface in de netwerkconfiguratie van de host aanmaken en parent daarheen wijzen houdt beide uiteinden voorspelbaar.

Bedenk dat de sleutel onder networks een Compose-naam is, geen Linux-apparaat. Op de host zoeken naar een interface met de naam office zal mislukken, omdat de kernel alleen de ouder-interface en het veth-paar achter de container ziet.

Maak ruimte voor de VPN erbovenop

Een VPN-client sluit aan nadat deze netwerken bestaan, dus kan hij specifiekere routes, beleidsregels en filters toevoegen ongeacht gw_priority. Plan de externe prefixen tegen beide lokale subnetten, inclusief de antwoorden die het controlepad nodig heeft. Wanneer een extern prefix overlapt met het kantoor-LAN, herstel dan het adresplan in plaats van een hele private reeks uit de tunnel te rukken.

Controleer adressen, routes en het dienstpad opnieuw nadat de VPN start en nog eens nadat hij opnieuw verbindt, want bij een herverbinding verdwijnt een met de hand toegevoegde route. Schrijf de verwachte tabel op vóór de eerste test, zodat de vergelijking daarna een diff is en geen geheugenoefening. Houd het blijvende netwerkeigendom in Compose en laat de VPN-configuratie alleen haar eigen beleid bezitten.

Gerelateerde artikelen