Houer met twee netwerke kies die verkeerde poort

Twee aanhegsels, een verstekroete, en die verkeerde netwerk wen steeds. Pen die uitgang vas met Compose gw_priority en bevestig dit van binne die houer.

Jou houer antwoord steeds op sy kontrolebrug, tog verlaat elke uitgaande pakkie die netwerk deur die kantoor-macvlan. Niks het gefaal nie. Twee aanhegsels verskaf elk 'n poort, en die enkele verstekroete het na die een gegaan wat jy nie bedoel het nie, so die diens werk steeds terwyl sy verkeer 'n langer pad volg. Teen die tyd dat iemand dit opmerk, is die bewys 'n roetekaart eerder as 'n foutboodskap.

Die gewone verklaring is dat Docker die netwerk per ongeluk gekies het. In die praktyk het die ou beslissing die alfabetiese volgorde van die aangehegte netwerkname gevolg, wat roetering in 'n newe-effek van 'n etiket verander het. gw_priority vervang dit met 'n nommer wat jy doelbewus kies, en die oorname daarvan neem omtrent 'n minuut sodra die uitleg neergeskryf is.

Waarom die verstekroete op die verkeerde netwerk beland

Elke netwerk wat 'n diens betree, kan sy eie poort aanbied, en die houer kry steeds presies een verstekroete. Voor Compose 2.33.1 is die gelykopheid deur die sortering van die netwerkname besleg, so 'n etiket soos control wat voor office kom, het bepaal waar die verkeer heen gaan. Niks binne die houer teken aan dat die beslissing willekeurig was nie, en daarom oorleef dit kodehersiening en duik later as 'n vreemde pad op. Om 'n beleid in die compose-lêer te plaas, is die enigste manier om die keuse inspekteerbaar te maak.

Twee dinge verander werklik watter netwerk wen: die gw_priority-waardes wat jy toeken, en watter netwerke hoegenaamd aangeheg is. Voeg 'n derde netwerk by en die kandidaatstel groei; laat die macvlan val en daar is niks oor om met die brug mee te kompeteer nie. Nie een van die skuiwe verskyn in toepassingslogboeke nie, want 'n verkeerde verstekroete breek selde 'n verbinding heeltemal. Dit maak net dat antwoorde vanaf 'n adres aankom wat die ander kant dalk nie verwag nie.

Pen die poort vas met gw_priority

Compose bied gw_priority op elke diens-tot-netwerk-aanhegsel vanaf weergawe 2.33.1, en die hoogste nommer wen. Daar is geen poort-sleutel per diens nie, so die waarde hoort onder die diens se networks-blok. Die voorbeeld hieronder gee die verstek aan control terwyl office bereikbaar bly vir sy direk gekoppelde 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 die blok as twee aparte beheermaatreëls: gw_priority bepaal die verstekroete, en die ipam-stanza bepaal adressering. Om net die subnet te verander, laat die uitgangkeuse onaangeraak, en dit is die mees algemene manier waarop hierdie regstelling half toegepas word. Hou die prioriteite langs die netwerk wat hulle beheer, sodat die volgende leser nie na die beslissing hoef te soek nie.

Moenie gw_priority met die gewone priority-eienskap daarlangs verwar nie. Daardie een orden die skepping van verbindings en sê niks oor roetering nie, so dit kan nie 'n verstekpoort kies nie en maak nie interfasename reg nie. As iemand aanbeveel om priority te verhoog om verkeer te stuur, is die aanbeveling verkeerd, selfs wanneer die resulterende volgorde toevallig korrek lyk.

Verifieer watter netwerk werklik die verstekroete dra

Kontroleer binne die lopende houer, want die gasheer se roetekaart beskryf die gasheer en nie die naamruimte wat die diens gebruik nie. Voer eers die konfigurasiekontrole uit sodat 'n tikfout voor 'n herstart faal, en lees dan die roete wat die houer werklik geïnstalleer het.

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

'n Korrekte resultaat noem die brugtoestel en 172.30.50.1; 'n verkeerde een noem 192.168.120.1 en die macvlan-toestel. As die beeld geen iproute2-pakket bevat nie, rapporteer die /proc-lêer steeds die verstekroete, met 'n bestemming van 00000000 en die poortgrepe omgekeer. Vergelyk die interfasekolom met docker inspect wanneer die toestelname onduidelik is.

Macvlan is 'n fisiese poort, nie 'n brugkloon nie

Macvlan gee die houer 'n tweede identiteit op die draad, en dit is presies wat toegang tot plaaslike toestelle laat werk. Dit beteken ook die skakelpoort en die hipervisor moet 'n ekstra MAC-adres aanvaar, en baie wolkenetwerke weier dit stilweg. Toets een houer voordat jy 'n vloot beplan, want 'n geweierde MAC verskyn gewoonlik as 'n skakel wat op is en niks deurlaat nie.

Die macvlan_mode: bridge-instelling is 'n modus van die macvlan-drywer, nie Docker se sagtewarebrug nie, en passthru is 'n aparte gespesialiseerde modus eerder as 'n verstek. Linux keer ook dat 'n macvlan-houer sy eie gasheer bereik deur dieselfde ouer, en dit is die rede om die kontrolebrug te behou eerder as om te verwag dat een aanhegsel albei take doen.

Noem die VLAN-ouer voordat Compose dit sien

Docker behandel 'n ouer met 'n punt soos eno1.120 as 'n 802.1Q-subkoppelvlak en skep self die VLAN-toestel. Daardie gerief het perke: die afgeleide naam hang van die fisiese koppelvlaknaam af, en lang name kan die resultaat verby die verwagtinge van die omliggende gereedskap stoot. Om 'n benoemde VLAN-koppelvlak in die gasheer se netwerkkonfigurasie te skep en parent daarheen te wys, hou albei kante voorspelbaar.

Onthou dat die sleutel onder networks 'n Compose-naam is, nie 'n Linux-toestel nie. Om die gasheer vir 'n koppelvlak genaamd office te deursoek, sal misluk, want die kern sien net die ouerkoppelvlak en die veth-paar agter die houer.

Maak plek vir die VPN bo-op

'n VPN-kliënt heg ná hierdie netwerke aan, so dit kan meer spesifieke roetes, beleidsreëls en filters byvoeg ongeag gw_priority. Beplan die afstandvoorvoegsels teen albei plaaslike subnette, insluitend die antwoorde wat die kontrolepad nodig het. Wanneer 'n afstandvoorvoegsel die kantoor-LAN oorvleuel, maak die adresplan reg eerder as om 'n hele private reeks uit die tonnel te stroop.

Kontroleer weer adresse, roetes en die dienspad nadat die VPN begin het en weer nadat dit herverbind het, want dit is by 'n herverbinding waar 'n handmatig bygevoegde roete verdwyn. Skryf die verwagte tabel neer voor die eerste toets sodat die vergelyking daarna 'n diff is eerder as 'n geheue-oefening. Hou blywende netwerkeienaarskap in Compose en laat die VPN-konfigurasie net sy eie beleid besit.

Verwante artikels