Gám með tvö net velur rangt gátt

Gámurinn þinn svarar enn á stýribrúnni sinni, en hvert útfarandi pakki fer út um skrifstofu-macvlan. Ekkert hefur bilað. Tvær tengingar gefa hvor sína gátt, og eina sjálfgefna leiðin fór á netið sem þú ætlaðir ekki, svo þjónustan heldur áfram að virka á meðan umferðin hennar fer lengri leið. Þegar einhver tekur eftir því er sönnunin beiningartafla, ekki villuskilaboð.

Venjulega skýringin er að Docker hafi valið netið fyrir tilviljun. Í reynd fylgdi gamla ákvörðunin stafrófsröð nafna tengdu netanna, sem gerði beiningu að aukaverkun merkis. gw_priority kemur í staðinn með tölu sem þú velur viljandi, og að taka hana upp tekur um eina mínútu þegar skipulagið er skrifað niður.

Hvers vegna sjálfgefna leiðin lendir á ranga netinu

Hvert net sem þjónusta gengur inn í getur boðið sína eigin gátt, og gámurinn endar samt með nákvæmlega eina sjálfgefna leið. Fyrir Compose 2.33.1 var jafntefli leyst með því að raða netheitunum, svo merki eins og control sem kemur á undan office ákvað hvert umferðin fór. Ekkert inni í gámnum skráir að ákvörðunin hafi verið handahófskennd, og þess vegna lifir hún kóðarýni af og kemur síðar fram sem undarleg leið. Að setja stefnu í compose-skrána er eina leiðin til að gera valið skoðanlegt.

Tvennt breytir í raun hvaða net vinnur: gw_priority-gildin sem þú úthlutar og hvaða net eru yfirleitt tengd. Bættu við þriðja neti og mengið stækkar; fjarlægðu macvlan og ekkert er eftir til að keppa við brúna. Hvorug hreyfingin birtist í forritaskrám, því röng sjálfgefin leið rofnar sjaldan tengingu algjörlega. Hún lætur svörin koma frá vistfang sem hin hliðin á kannski ekki von á.

Festu gáttina með gw_priority

Compose birtir gw_priority á hverri þjónustu-til-nets tengingu frá útgáfu 2.33.1, og hæsta talan vinnur. Ekkert gáttarlykill er fyrir hverja þjónustu, svo gildið tilheyrir networks-blokki þjónustunnar. Dæmið hér að neðan gefur control sjálfgefnu leiðina á meðan office helst aðgengilegt fyrir beintengda LAN sitt.

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

Lestu blokkin sem tvo aðskilda stýringar: gw_priority ákveður sjálfgefnu leiðina og ipam-hlutinn ákveður vistfangsgerð. Að breyta aðeins subnet lætur útgáttarvalið ósnert, og það er algengasta leiðin sem þessi lagfæring er sett í hálfa gátt. Haltu forgangsröðuninni við hlið netsins sem hún stýrir svo næsti lesandi þurfi ekki að elta ákvörðunina.

Ruglaðu gw_priority ekki saman við hina venjulegu priority-eiginleika við hliðina. Sú raðar stofnun tenginga og segir ekkert um beiningu, svo hún getur ekki valið sjálfgefna gátt og lagar ekki nöfn viðmóta. Ef einhver mælir með að hækka priority til að stýra umferð er ráðið rangt, jafnvel þótt röðin sem kemur út líti tilviljunarkennt rétt út.

Staðfestu hvaða net ber í raun sjálfgefnu leiðina

Athugaðu inni í keyrandi gámnum, því beiningartafla hýsilsins lýsir hýslinum en ekki nafnrýminu sem þjónustan notar. Keyrðu stillingaprófið fyrst svo innsláttarvilla falli áður en endurræst er, og lestu svo leiðina sem gámurinn raunverulega setti upp.

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

Rétt niðurstaða nefnir brúartækið og 172.30.50.1; röng nefnir 192.168.120.1 og macvlan-tækið. Ef myndin inniheldur ekki iproute2-pakkann greinir /proc-skráin samt frá sjálfgefnu leiðinni, með áfangastað 00000000 og gáttarbætin öfug. Berðu viðmótssúlkuna saman við docker inspect þegar tækjanöfnin eru óljós.

Macvlan er líkamleg gátt, ekki klónn af brú

Macvlan gefur gámnum aðra auðkenningu á vírnum, og það er einmitt það sem gerir aðgang að staðbundnum tækjum virkandi. Það þýðir líka að rofaportinn og ofurtölvan verða að samþykkja auka MAC-vistfang, og mörg skynet skjóta því hljóðlega á bug. Prófaðu einn gám áður en þú skipuleggur flota, því hafnað MAC birtist venjulega sem tenging sem er uppi og hleypir engu í gegn.

Stillingin macvlan_mode: bridge er háttur macvlan-rekilsins, ekki hugbúnaðarbrú Docker, og passthru er sérhæfður háttur í eigin flokki en ekki sjálfgefið. Linux kemur líka í veg fyrir að macvlan-gámur nái eigin hýsli um sama foreldri, og það er ástæðan fyrir að halda stýribrúnni í stað þess að ætla einni tengingu að leysa bæði verk.

Nefndu VLAN-foreldrið áður en Compose sér það

Docker meðhöndlar foreldri með punkti eins og eno1.120 sem 802.1Q undirviðmót og býr sjálft til VLAN-tækið. Þessi þægindi hafa mörk: afleita nafnið fer eftir nafni líkamlega viðmótsins, og löng nöfn geta ýtt niðurstöðunni út fyrir það sem verkfærin í kring vænta. Að búa til nefnt VLAN-viðmót í netstillingum hýsilsins og beina parent að því heldur báðum endum fyrirsjáanlegum.

Mundu að lykillinn undir networks er Compose-nafn, ekki Linux-tæki. Að leita á hýslinum að viðmóti sem heitir office mun mistakast, því kjarninn sér aðeins foreldraviðmótið og veth-parið bak við þennan gám.

Gerðu pláss fyrir VPN ofan á

VPN-biðlari tengist eftir að þessi net eru til, svo hann getur bætt við nákvæmari leiðum, stefnureglum og síum óháð gw_priority. Skipuleggðu fjarlægu forskeytin gagnvart báðum staðbundnu subnetunum, þar á meðal svörunum sem stýrileiðin þarf. Þegar fjarlægt forskeyti skarast við skrifstofu-LAN skaltu laga vistfangaskipulagið í stað þess að rífa heilt einkasvið úr göngunni.

Athugaðu vistföng, leiðir og leið þjónustunnar aftur eftir að VPN byrjar og einu sinni enn eftir að það tengist aftur, því við endurtengingu hverfur leið sem var bætt við handvirkt. Skrifaðu væntu töfluna niður fyrir fyrstu prófun svo samanburðurinn eftir á sé diff en ekki minningaræfing. Haltu varanlegu eignarhaldi netsins í Compose og láttu VPN-stillingarnar eiga aðeins sína eigin stefnu.