Container med två nätverk väljer fel gateway

Två anslutningar, en standardväg, och fel nätverk vinner varje gång. Lås utgången med Compose gw_priority och bekräfta den inifrån containern.

Din container svarar fortfarande på sin kontrollbrygga, men varje utgående paket lämnar nätverket via kontorets macvlan. Inget har gått sönder. Två anslutningar ger varsin gateway, och den enda standardvägen gick till nätverket du inte menade, så tjänsten fortsätter att fungera medan dess trafik tar en längre väg. När någon upptäcker det är beviset en routingtabell och inte ett felmeddelande.

Den vanliga förklaringen är att Docker valde nätverket av misstag. I praktiken följde det gamla beslutet den alfabetiska ordningen på de anslutna nätverksnamnen, vilket gjorde routing till en bieffekt av en etikett. gw_priority ersätter det med ett tal du väljer med avsikt, och att ta det i bruk tar ungefär en minut när upplägget är nedskrivet.

Varför standardvägen hamnar på fel nätverk

Varje nätverk som en tjänst ansluter till kan erbjuda sin egen gateway, och containern har ändå exakt en standardväg. Före Compose 2.33.1 avgjordes oavgjort genom att sortera nätverksnamnen, så en etikett som control som kommer före office bestämde vart trafiken gick. Inget inne i containern registrerar att beslutet var godtyckligt, och därför överlever det kodgranskningen och dyker senare upp som en märklig väg. Att lägga en policy i compose-filen är det enda sättet att göra valet granskningsbart.

Två saker ändrar faktiskt vilket nätverk som vinner: gw_priority-värdena du tilldelar och vilka nätverk som alls är anslutna. Lägg till ett tredje nätverk och kandidatmängden växer; ta bort macvlanet och det finns inget kvar att konkurrera med bryggan. Ingen av åtgärderna syns i applikationsloggarna, eftersom en fel standardväg sällan bryter förbindelsen helt. Den gör bara att svar anländer från en adress som andra sidan kanske inte väntar sig.

Lås gatewayen med gw_priority

Compose exponerar gw_priority på varje tjänst-till-nätverksanslutning från version 2.33.1, och högsta talet vinner. Det finns ingen gateway-nyckel per tjänst, så värdet hör hemma under tjänstens networks-block. Exemplet nedan ger standardvägen till control medan office förblir nåbart för sitt direkt anslutna 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 blocket som två separata kontroller: gw_priority avgör standardvägen och ipam-delen avgör adresseringen. Att bara ändra subnätet lämnar utgångsvalet orört, och det är det vanligaste sättet den här rättelsen blir halvt tillämpad. Håll prioriteterna bredvid nätverket de styr, så att nästa läsare inte behöver leta efter beslutet.

Blanda inte ihop gw_priority med den vanliga priority-egenskapen bredvid. Den ordnar skapandet av anslutningar och säger ingenting om routing, så den kan inte välja en standardgateway och rättar inte till gränssnittsnamn. Om någon rekommenderar att höja priority för att styra trafiken är rekommendationen fel, även när den resulterande ordningen råkar se korrekt ut.

Verifiera vilket nätverk som faktiskt bär standardvägen

Kontrollera inne i den körande containern, eftersom värdens routingtabell beskriver värden och inte det namnutrymme tjänsten använder. Kör konfigurationskontrollen först så att ett skrivfel fallerar före en omstart, och läs sedan den väg som containern faktiskt installerade.

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

Ett korrekt resultat namnger bryggendheten och 172.30.50.1; ett felaktigt namnger 192.168.120.1 och macvlan-enheten. Om imagen inte innehåller iproute2-paketet rapporterar /proc-filen fortfarande standardvägen, med destination 00000000 och gateway-byten omvänd. Jämför gränssnittskolumnen med docker inspect när enhetsnamnen är oklara.

Macvlan är en fysisk port, inte en klon av bryggan

Macvlan ger containern en andra identitet på kabeln, och det är just detta som gör åtkomst till lokala enheter möjlig. Det betyder också att switchporten och hypervisorn måste acceptera en extra MAC-adress, och många molnnätverk avvisar det tyst. Testa en container innan du planerar en flotta, eftersom en avvisad MAC vanligtvis visar sig som en länk som är uppe och inte släpper igenom något.

Inställningen macvlan_mode: bridge är ett läge i macvlan-drivrutinen, inte Dockers programvarubrygga, och passthru är ett eget specialiserat läge och inte en standard. Linux hindrar också en macvlan-container från att nå sin egen värd genom samma förälder, och det är skälet att behålla kontrollbryggan i stället för att förvänta sig att en enda anslutning gör båda jobben.

Namnge VLAN-föräldern innan Compose ser den

Docker behandlar en förälder med punkt som eno1.120 som ett 802.1Q-undergränssnitt och skapar VLAN-enheten själv. Den bekvämligheten har gränser: det härledda namnet beror på namnet på det fysiska gränssnittet, och långa namn kan skjuta resultatet bortom vad verktygen runt omkring förväntar sig. Att skapa ett namngivet VLAN-gränssnitt i värdens nätverkskonfiguration och peka parent dit håller båda ändarna förutsägbara.

Kom ihåg att nyckeln under networks är ett Compose-namn, inte en Linux-enhet. Att leta efter ett gränssnitt som heter office på värden kommer att misslyckas, eftersom kärnan bara ser föräldragränssnittet och veth-paret bakom containern.

Gör plats för VPN:en ovanpå

En VPN-klient ansluter efter att dessa nätverk finns, så den kan lägga till mer specifika vägar, policyregler och filter oavsett gw_priority. Planera fjärrprefixen mot båda lokala subnäten, inklusive de svar som kontrollvägen behöver. När ett fjärrprefix överlappar kontorets LAN ska adressplanen rättas till i stället för att riva ut ett helt privat intervall ur tunneln.

Kontrollera adresser, vägar och tjänstens väg igen efter att VPN:en startar och ännu en gång efter att den återansluter, eftersom det är vid en återanslutning en handpålagd väg försvinner. Skriv ner den förväntade tabellen före första testet så att jämförelsen efteråt är en diff och inte en minnesövning. Behåll det varaktiga nätverksägandet i Compose och låt VPN-konfigurationen bara äga sin egen policy.

Relaterade artiklar