Container mei twa netwurken kiest de ferkearde gateway

Twa oanslutings, ien standertrûte, en it ferkearde netwurk wint altyd. Pin de útgong fêst mei Compose gw_priority en befêstigje it fan binnenút de container.

Jo container antwurdet noch hieltyd op syn kontrôlebrêge, mar elk útgeand pakket ferlit it netwurk troch de kantoar-macvlan. Der is neat misgien. Twa oanslutings jouwe elk in gateway, en de ienige standertrûte gie nei it netwurk dat jo net bedoelden, dat de tsjinst bliuwt wurkjen wylst har ferkear in langer paad nimt. Tsjin de tiid dat immen it merkt, is it bewiis in rûtekaart yn plak fan in flaterberjocht.

De gewoane ferklearring is dat Docker it netwurk by tafal keas. Yn 'e praktyk folge de âlde beslissing de alfabetyske oarder fan 'e oanslette netwurknammen, wat rûtering in by-effekt fan in label makke. gw_priority ferfangt dat troch in nûmer dat jo bewust kieze, en it oernimmen duorret sawat in minút sadree't de yndieling opskreaun is.

Wêrom't de standertrûte op it ferkearde netwurk telâne komt

Elk netwurk dêr't in tsjinst by oanslút kin syn eigen gateway biede, en de container einiget noch altyd mei krekt ien standertrûte. Foar Compose 2.33.1 waard de lykstân besljochte troch de netwurknammen te sortearjen, sadat in label lykas control dy't foar office komt, bepaalde wêr't it ferkear hinne gie. Neat yn 'e container registrearret dat de beslissing willekeurich wie, en dêrom oerlibbet it koadebesjoch en komt it letter as in frjemd paad foar 't ljocht. In belied yn it compose-bestân pleatse is de iennichste manier om de kar ynspektearber te meitsjen.

Twa dingen feroarje wier hokker netwurk wint: de gw_priority-wearden dy't jo tawize, en hokker netwurken der hielendal oansletten binne. Foegje in tredde netwurk ta en de set fan kandidaten groeit; helje de macvlan fuort en der is neat mear om mei de brêge te konkurrearjen. Gjin fan beide bewegings is te sjen yn 'e applikaasjelogboeken, want in ferkearde standertrûte brekt in ferbining selden folslein. It makket allinnich dat antwurden oankomme fan in adres dat de oare kant miskien net ferwachtet.

Pin de gateway fêst mei gw_priority

Compose biedt gw_priority oan op elke tsjinst-nei-netwurk-oansluting fanôf ferzje 2.33.1, en it heechste nûmer wint. Der is gjin gateway-kaai per tsjinst, dat de wearde heart ûnder it networks-blok fan 'e tsjinst. It foarbyld hjirûnder jout de standertrûte oan control wylst office berikber bliuwt foar syn direkt ferbûne 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 it blok as twa aparte kontrôles: gw_priority beslút de standertrûte, en de ipam-seksje beslút de adressearring. Allinnich de subnet feroarje lit de útgongskar ûnoantaast, en dat is de meast foarkommende manier wêrop dizze oplossing heal tapast wurdt. Hâld de prioriteiten neist it netwurk dat se bestjoere, sadat de folgjende lêzer de beslissing net sykje hoecht.

Ferwikselje gw_priority net mei de gewoane priority-eigenskip derneist. Dy oardere it oanmeitsjen fan ferbiningen en seit neat oer rûtering, dat it kin gjin standertgateway kieze en reparearret gjin ynterfazenammen. As immen oanriedt priority te ferheegjen om ferkear te stjoeren, is de oanrieding ferkeard, sels wannear't de resultearjende oarder tafallich goed liket.

Kontrolearje hokker netwurk de standertrûte echt draacht

Kontrolearje yn 'e rinnende container, want de rûtekaart fan 'e host beskriuwt de host en net de nammromte dy't de tsjinst brûkt. Rin earst de konfiguraasjekontrôle, sadat in typflater foar in werstart mislearret, en lês dan de rûte dy't de container wier ynstallearre hat.

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

In juste útkomst neamt it brêge-apparaat en 172.30.50.1; in ferkearde neamt 192.168.120.1 en it macvlan-apparaat. As de ôfbylding gjin iproute2-pakket befettet, meldt it /proc-bestân noch altyd de standertrûte, mei bestimmingsadres 00000000 en de gateway-bytes omkeard. Fergelykje de ynterfazekolom mei docker inspect as de apparaatnammen ûndúdlik binne.

Macvlan is in fysike poarte, gjin kloan fan in brêge

Macvlan jout de container in twadde identiteit op 'e tried, en dat is krekt wat tagong ta lokale apparaten wurkje lit. It betsjut ek dat de switcherpoarte en de hypervisor in ekstra MAC-adres akseptearje moatte, en in protte wolknetwurken wegerje dat stil. Test ien container foardat jo in float plenje, want in wegere MAC ferskynt meastentiids as in keppeling dy't omheech is en neat trochlit.

De ynstelling macvlan_mode: bridge is in modus fan 'e macvlan-stjoerder, net Docker syn softwarebrêge, en passthru is in aparte spesjalisearre modus en net in standert. Linux hâldt ek in macvlan-container tsjin om syn eigen host te berikken fia deselde âlder, en dat is de reden om de kontrôlebrêge te hâlden ynstee fan te ferwachtsjen dat ien oansluting beide taken docht.

Nammje de VLAN-âlder foardat Compose him sjocht

Docker behannelet in âlder mei punt lykas eno1.120 as in 802.1Q-subynterface en makket it VLAN-apparaat sels oan. Dy gemak hat grinzen: de ôflate namme hinget ôf fan 'e namme fan 'e fysike ynterface, en lange nammen kinne it resultaat foarby de ferwachtings fan 'e omlizzende ark stjitte. In neamde VLAN-ynterface oanmeitsje yn 'e netwurkkonfiguraasje fan 'e host en parent dêrhinne wize hâldt beide einen foarsisber.

Tink derom dat de kaai ûnder networks in Compose-namme is, gjin Linux-apparaat. It sykjen fan 'e host nei in ynterface mei de namme office sil mislearje, want de kearn sjocht allinnich de âlderlike ynterface en it veth-pear efter de container.

Meitsje romte foar de VPN boppe-op

In VPN-klant slút oan neidat dizze netwurken bestean, dus hy kin spesifiker rûtes, beliedsregels en filters tafoegje los fan gw_priority. Plan de fiere foarheaksels tsjin beide lokale subnets, ynklusyf de antwurden dy't it kontrôlepaad nedich hat. Wannear't in fier foarheaksel it kantoar-LAN oerlapet, reparearje it adresplan ynstee fan in hiel privee berik út 'e tunnel te skuorren.

Kontrolearje adressen, rûtes en it paad fan 'e tsjinst op 'e nij neidat de VPN start en nochris neidat er wer ferbynt, want by in werferbining ferdwynt in mei de hân tafoege rûte. Skriuw de ferwachte tabel foar de earste test op, sadat de fergeliking letter in diff is en gjin geheugen-oefening. Hâld it bliuwende netwurkeigendom yn Compose en lit de VPN-konfiguraasje allinnich syn eigen belied besitte.

Relatearre artikelen