Ujo kun du retoj elektas la malĝustan enirejon

Du aligoj, unu defaŭlta vojo, kaj la malĝusta reto gajnas ĉiam. Fiksu la eliron per Compose gw_priority kaj konfirmu ĝin el la interno de la ujo.

Via ujo ankoraŭ respondas sur sia rega ponto, tamen ĉiu eliranta paketo foriras tra la oficeja macvlan. Nenio fiaskis. Du aligoj ĉiu liveras enirejon, kaj la sola defaŭlta vojo iris al la reto, kiun vi ne intencis, do la servo daŭre funkcias dum ĝia trafiko prenas pli longan vojon. Kiam iu rimarkas, la pruvo estas enkursiga tabelo anstataŭ erarmesaĝo.

La kutima klarigo estas, ke Docker elektis la reton hazarde. En praktiko la malnova decido sekvis la alfabetan ordon de la aligitaj retnomoj, kio igis enkursigadon flanka efiko de etikedo. gw_priority anstataŭigas tion per numero, kiun vi elektas intence, kaj adaptiĝi al ĝi daŭras ĉirkaŭ unu minuton post kiam la aranĝo estas skribita.

Kial la defaŭlta vojo surteriĝas sur la malĝusta reto

Ĉiu reto, al kiu servo aliĝas, povas proponi sian propran enirejon, kaj la ujo tamen finiĝas kun ekzakte unu defaŭlta vojo. Antaŭ Compose 2.33.1 la egaleco estis solvita per ordigado de la retnomoj, do etikedo kiel control, kiu venas antaŭ office, decidis kien la trafiko iras. Nenio en la ujo registras, ke la decido estis arbitra, kaj tial ĝi postvivas kodrevizion kaj poste aperas kiel stranga vojo. Meti regulon en la compose-dosieron estas la sola maniero igi la elekton kontrolebla.

Du aferoj vere ŝanĝas, kiu reto gajnas: la valoroj gw_priority, kiujn vi asignas, kaj kiuj retoj entute estas aligitaj. Aldonu trian reton kaj la aro da kandidatoj kreskas; forigu la macvlan kaj restas nenio por konkuri kun la ponto. Neniu el la du movoj aperas en aplikaj protokoloj, ĉar malĝusta defaŭlta vojo malofte rompas konekton tute. Ĝi nur kaŭzas, ke respondoj alvenas de adreso, kiun la alia flanko eble ne atendas.

Fiksu la enirejon per gw_priority

Compose elmontras gw_priority sur ĉiu servo-al-reto aligo ekde versio 2.33.1, kaj la plej alta numero gajnas. Ne ekzistas enireja ŝlosilo po servo, do la valoro apartenas sub la networks-bloko de la servo. La suba ekzemplo donas la defaŭltan vojon al control, lasante office atingebla por sia rekte konektita 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

Legu la blokon kiel du apartaj regiloj: gw_priority decidas la defaŭltan vojon, kaj la ipam-sekcio decidas adresadon. Ŝanĝi nur la subnet lasas la elirelekton netuŝita, kaj tio estas la plej ofta maniero apliki ĉi tiun riparon duone. Tenu la prioritatojn apud la reto, kiun ili regas, por ke la sekva leganto ne devu ĉasi la decidon.

Ne konfuzu gw_priority kun la ordinara propraĵo priority apude. Tiu ordigas la kreadon de konektoj kaj diras nenion pri enkursigado, do ĝi ne povas elekti defaŭltan enirejon kaj ne riparas interfacajn nomojn. Se iu rekomendas plialtigi priority por direkti trafikon, la rekomendo estas malĝusta eĉ kiam la rezulta ordo hazarde aspektas ĝusta.

Kontrolu, kiu reto vere portas la defaŭltan vojon

Kontrolu ene de la kuranta ujo, ĉar la enkursiga tabelo de la gastiganto priskribas la gastiganton, ne la nomspacon, kiun la servo uzas. Unue rulu la konfiguran kontrolon, por ke tajperaro fiasku antaŭ restartigo, poste legu la vojon, kiun la ujo vere instalas.

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

Ĝusta rezulto nomas la pontan aparaton kaj 172.30.50.1; malĝusta nomas 192.168.120.1 kaj la macvlan-aparaton. Se la bildo ne enhavas la pakaĵon iproute2, la dosiero /proc tamen raportas la defaŭltan vojon, kun celo 00000000 kaj la enirejaj bajtoj inversigitaj. Komparu la interfacan kolumnon kun docker inspect kiam la aparataj nomoj ne estas klaraj.

Macvlan estas fizika pordo, ne klono de ponto

Macvlan donas al la ujo duan identecon sur la drato, kaj ĝuste tio ebligas aliron al lokaj aparatoj. Ĝi ankaŭ signifas, ke la ŝaltila pordo kaj la hipervizoro devas akcepti plian MAC-adreson, kaj multaj nubaj retoj silente rifuzas tion. Testu unu ujon antaŭ ol plani floton, ĉar rifuzita MAC kutime aperas kiel ligo, kiu estas supre kaj pasigas nenion.

La agordo macvlan_mode: bridge estas reĝimo de la macvlan-ŝoforo, ne la programara ponto de Docker, kaj passthru estas aparta specialigita reĝimo, ne defaŭlto. Linux ankaŭ malhelpas macvlan-ujon atingi sian propran gastiganton tra la sama parent, kaj tio estas la kialo teni la regan ponton anstataŭ atendi, ke unu aligo plenumu ambaŭ taskojn.

Nomu la VLAN-parent antaŭ ol Compose vidas ĝin

Docker traktas parenton kun punkto kiel eno1.120 kiel 802.1Q-subinterfacon kaj mem kreas la VLAN-aparaton. Tiu komforto havas limojn: la derivita nomo dependas de la nomo de la fizika interfaco, kaj longaj nomoj povas puŝi la rezulton preter tio, kion la ĉirkaŭaj iloj atendas. Krei nomitan VLAN-interfacon en la reta agordo de la gastiganto kaj montri parent al ĝi tenas ambaŭ finojn antaŭvideblaj.

Memoru, ke la ŝlosilo sub networks estas Compose-nomo, ne Linux-aparato. Serĉi en la gastiganto interfacon nomatan office malsukcesos, ĉar la kerno vidas nur la parent-interfacon kaj la veth-paron malantaŭ la ujo.

Faru lokon por la VPN supre

VPN-kliento aliĝas post kiam ĉi tiuj retoj ekzistas, do ĝi povas aldoni pli specifajn vojojn, regulojn de politiko kaj filtrilojn sendepende de gw_priority. Planu la malproksimajn prefiksojn kontraŭ ambaŭ lokaj subnet, inkluzive la respondojn, kiujn la rega vojo bezonas. Kiam malproksima prefikso koincidas kun la oficeja LAN, riparu la adresan planon anstataŭ elŝiri tutan privatan gamon el la tunelo.

Rekontrolu adresojn, vojojn kaj la servan vojon post kiam la VPN ekfunkcias kaj denove post kiam ĝi rekonektiĝas, ĉar ĝuste ĉe rekonekto malaperas mane aldonita vojo. Skribu la atendatan tabelon antaŭ la unua testo, por ke la posta komparo estu diff kaj ne memorekzerco. Tenu la daŭran posedon de la reto en Compose kaj lasu la VPN-agordon posedi nur sian propran politikon.

Rilataj artikoloj