Kontena na may dalawang network pumipili ng maling gateway

Sumasagot pa rin ang kontena mo sa control bridge nito, pero bawat palabas na packet ay lumalabas sa macvlan ng opisina. Walang nabigo. Dalawang attachment ang nagbibigay ng tig-isang gateway, at ang nag-iisang default na ruta ay napunta sa network na hindi mo sinadya, kaya patuloy na gumagana ang serbisyo habang ang trapik nito ay dumadaan sa mas mahabang ruta. Pagdating ng may makapansin, ebidensya ang routing table at hindi error message.

Ang karaniwang paliwanag ay aksidenteng pinili ng Docker ang network. Sa praktika sinusundan ng dating desisyon ang alpabetikong pagkakasunod-sunod ng mga pangalan ng nakakabit na network, na ginawang side effect ng isang label ang routing. Pinapalitan ito ng gw_priority ng numerong pinipili mo nang sadya, at tumatagal ng mga isang minuto ang pag-ampon kapag nakasulat na ang layout.

Bakit napupunta sa maling network ang default na ruta

Bawat network na sinasalihan ng serbisyo ay maaaring mag-alok ng sarili nitong gateway, at nagtatapos pa rin ang kontena na may eksaktong isang default na ruta. Bago ang Compose 2.33.1, ang tabla ay niresolba sa pamamagitan ng pag-sort ng mga pangalan ng network, kaya ang label na tulad ng control na nauuna sa office ang nagtatakda kung saan pupunta ang trapik. Walang naitatala sa loob ng kontena na arbitraryo ang desisyon, kaya nakakalusot ito sa code review at lumilitaw mamaya bilang kakaibang ruta. Ang paglalagay ng patakaran sa compose file ang tanging paraan para maging masuri ang pagpili.

Dalawang bagay ang tunay na nagbabago kung aling network ang mananalo: ang mga halaga ng gw_priority na itinatalaga mo, at kung aling mga network ang nakakabit. Magdagdag ng ikatlong network at lumalaki ang set ng kandidato; alisin ang macvlan at wala nang makikipagkumpitensya sa bridge. Wala sa dalawang hakbang ang lumalabas sa mga log ng aplikasyon, dahil bihirang tuluyang maputol ng maling default na ruta ang koneksyon. Ginagawa lang nitong dumating ang mga sagot mula sa address na maaaring hindi inaasahan ng kabilang panig.

I-pin ang gateway gamit ang gw_priority

Inilalantad ng Compose ang gw_priority sa bawat attachment ng serbisyo-sa-network mula bersyon 2.33.1, at ang pinakamataas na numero ang nananalo. Walang gateway key bawat serbisyo, kaya nasa ilalim ng networks block ng serbisyo ang halaga. Ibinibigay ng halimbawa sa ibaba ang default na ruta sa control habang nananatiling maabot ang office para sa direktang nakakabit nitong 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

Basahin ang block bilang dalawang hiwalay na kontrol: pinagpapasyahan ng gw_priority ang default na ruta, at ng ipam na bahagi ang addressing. Ang pagbabago lamang ng subnet ay iniiwan ang pagpili ng labasan na hindi nagalaw, at ito ang pinakakaraniwang paraan kung saan naisasagawa nang kalahati ang pagtatama. Itago ang mga prayoridad sa tabi ng network na kinokontrol nila para hindi na kailangang hanapin ng susunod na mambabasa ang desisyon.

Huwag ipagkamali ang gw_priority sa simpleng priority property sa tabi nito. Inaayos nito ang paggawa ng koneksyon at walang sinasabi tungkol sa routing, kaya hindi ito makakapili ng default na gateway at hindi nito naaayos ang mga pangalan ng interface. Kapag may nagrekomendang taasan ang priority para idirekta ang trapik, mali ang rekomendasyon kahit nagkataong mukhang tama ang resultang pagkakasunod-sunod.

Tiyakin kung aling network talaga ang nagdadala ng default na ruta

Suriin sa loob ng tumatakbong kontena, dahil inilalarawan ng routing table ng host ang host at hindi ang namespace na ginagamit ng serbisyo. Patakbuhin muna ang pagsusuri ng configuration para mabigo ang typo bago ang restart, pagkatapos basahin ang rutang aktwal na inilagay ng kontena.

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

Ang tamang resulta ay nagbabanggit ng bridge device at 172.30.50.1; ang mali ay nagbabanggit ng 192.168.120.1 at ng macvlan device. Kung walang iproute2 package ang image, nag-uulat pa rin ang /proc file ng default na ruta, na may destinasyong 00000000 at mga byte ng gateway na baligtad. Ihambing ang column ng interface sa docker inspect kapag hindi malinaw ang mga pangalan ng device.

Ang macvlan ay pisikal na port, hindi kopya ng bridge

Binibigyan ng macvlan ang kontena ng pangalawang pagkakakilanlan sa kable, at iyon mismo ang nagpapagana ng pag-access sa mga lokal na device. Nangangahulugan din ito na kailangang tanggapin ng switch port at hypervisor ang karagdagang MAC address, at tahimik na tinatanggihan ito ng maraming cloud network. Subukan ang isang kontena bago magplano ng fleet, dahil ang tinanggihang MAC ay karaniwang lumilitaw bilang link na nakataas pero walang pinapasa.

Ang setting na macvlan_mode: bridge ay mode ng macvlan driver, hindi ang software bridge ng Docker, at ang passthru ay hiwalay at espesyal na mode at hindi default.Pinipigilan din ng Linux ang isang macvlan container na maabot ang sariling host nito sa pamamagitan ng parehong parent, at ito ang dahilan kung bakit pinapanatili ang control bridge kaysa umasa na isang attachment lang ang gagawa ng dalawang trabaho.

Pangalanan ang parent ng VLAN bago pa ito makita ng Compose

Itinuturing ng Docker ang parent na may tuldok tulad ng eno1.120 bilang 802.1Q subinterface at siya mismo ang gumagawa ng VLAN device. May hangganan ang kaginhawang iyon: nakadepende ang hinangong pangalan sa pangalan ng pisikal na interface, at ang mahahabang pangalan ay maaaring itulak ang resulta lampas sa inaasahan ng mga tool sa paligid. Ang paggawa ng pinangalanang VLAN interface sa network configuration ng host at pagturo ng parent doon ay nagpapanatiling predictable ang dalawang dulo.

Tandaan na ang key sa ilalim ng networks ay pangalan ng Compose, hindi Linux device. Mabibigo ang paghahanap sa host ng interface na tinatawag na office, dahil nakikita lang ng kernel ang parent interface at ang veth pair sa likod ng kontena.

Maglaan ng espasyo para sa VPN sa itaas

Ang VPN client ay kumakabit pagkatapos umiral ang mga network na ito, kaya makakapagdagdag ito ng mas tiyak na ruta, patakaran sa policy at filter anuman ang gw_priority. Planuhin ang malalayong prefix laban sa dalawang lokal na subnet, kasama ang mga sagot na kailangan ng control path. Kapag ang malayong prefix ay nagsasapawan sa LAN ng opisina, ayusin ang plano ng address kaysa bunutin ang buong pribadong saklaw mula sa tunnel.

Muling suriin ang mga address, ruta at landas ng serbisyo pagkatapos magsimula ang VPN at muli pagkatapos itong makakonekta, dahil sa muling pagkonekta nawawala ang rutang idinagdag gamit ang kamay. Isulat ang inaasahang table bago ang unang pagsubok para ang paghahambing pagkatapos ay diff at hindi pagsasanay sa memorya. Panatilihin ang permanenteng pagmamay-ari ng network sa Compose at hayaang ang configuration ng VPN lang ang magmay-ari ng sarili nitong patakaran.