Një kontejner me dy rrjeta zgjedh portën e gabuar

Dy lidhje, një rrugë e paracaktuar, dhe rrjeti i gabuar fiton gjithmonë. Fiksoni daljen me Compose gw_priority dhe verifikojeni nga brenda kontejnerit.

Kontejneri juaj vazhdon të përgjigjet në urën e tij të kontrollit, por çdo paketë dalëse largohet përmes macvlan-it të zyrës. Asgjë nuk ka dështuar. Dy lidhje ofrojnë secila një portë, dhe rruga e vetme e paracaktuar shkoi drejt rrjetit që nuk e kishit parasysh, kështu që shërbimi vazhdon të punojë ndërsa trafiku i tij ndjek një rrugë më të gjatë. Kur dikush e vëren, prova është një tabelë rrugëzimi dhe jo një mesazh gabimi.

Shpjegimi i zakonshëm është se Docker e zgjodhi rrjetin rastësisht. Në praktikë vendimi i vjetër ndiqte rendin alfabetik të emrave të rrjeteve të lidhura, gjë që e kthente rrugëzimin në një efekt anësor të një etikete. gw_priority e zëvendëson atë me një numër që ju e zgjidhni me qëllim, dhe adoptimi i tij merr rreth një minutë pasi skema të jetë shkruar.

Pse rruga e paracaktuar zbret në rrjetin e gabuar

Çdo rrjet që i bashkohet një shërbimi mund të ofrojë portën e vet, dhe kontejneri përsëri mbetet me saktësisht një rrugë të paracaktuar. Përpara Compose 2.33.1 barazia zgjidhej duke renditur emrat e rrjeteve, kështu që një etiketë si control që vjen përpara office vendoste ku shkonte trafiku. Asgjë brenda kontejnerit nuk regjistron se vendimi ishte arbitrar, dhe për këtë arsye ai i kalon rishikimit të kodit dhe shfaqet më vonë si një rrugë e çuditshme. Vendosja e një politike në skedarin compose është e vetmja mënyrë për ta bërë zgjedhjen të inspektueshme.

Dy gjëra ndryshojnë vërtet se cili rrjet fiton: vlerat gw_priority që caktoni, dhe cilat rrjeta janë të lidhura fare. Shtoni një rrjet të tretë dhe grupi i kandidatëve rritet; hiqni macvlan-in dhe nuk mbetet asgjë për t'u përballur me urën. Asnjëra prej lëvizjeve nuk shfaqet në regjistrat e aplikacionit, sepse një rrugë e paracaktuar e gabuar rrallë e prish lidhjen plotësisht. Ajo vetëm bën që përgjigjet të vijnë nga një adresë që pala tjetër mund të mos e presë.

Fiksoni portën me gw_priority

Compose ekspozon gw_priority në çdo lidhje shërbim-me-rrjet që nga versioni 2.33.1, dhe numri më i madh fiton. Nuk ka çelës porte për çdo shërbim, kështu që vlera i përket bllokut networks të shërbimit. Shembulli më poshtë ia jep rrugën e paracaktuar control ndërsa office mbetet e arritshme për LAN-in e tij të lidhur drejtpërdrejt.

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

Lexojeni bllokun si dy kontrolle të veçanta: gw_priority vendos rrugën e paracaktuar dhe seksioni ipam vendos adresimin. Ndryshimi vetëm i subnet-it e lë zgjedhjen e daljes të paprekur, dhe kjo është mënyra më e zakonshme që ky rregullim të zbatohet përgjysmë. Mbani prioritetet pranë rrjetit që ato qeverisin, që lexuesi i ardhshëm të mos ketë nevojë ta gjuajë vendimin.

Mos e ngatërroni gw_priority me vetinë e thjeshtë priority pranë tij. Ajo rendit krijimin e lidhjeve dhe nuk thotë asgjë për rrugëzimin, kështu që nuk mund të zgjedhë një portë të paracaktuar dhe nuk i rregullon emrat e ndërfaqeve. Nëse dikush rekomandon të rritet priority për të drejtuar trafikun, rekomandimi është i gabuar edhe kur rendi që rezulton duket i saktë nga rastësia.

Verifikoni cili rrjet e mban vërtet rrugën e paracaktuar

Kontrolloni brenda kontejnerit në punë, sepse tabela e rrugëzimit e hostit përshkruan hostin dhe jo hapësirën e emrave që përdor shërbimi. Ekzekutoni fillimisht kontrollin e konfigurimit që një gabim shtypi të dështojë para një rindezjeje, dhe pastaj lexoni rrugën që kontejneri ka instaluar vërtet.

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

Një rezultat i saktë përmend pajisjen e urës dhe 172.30.50.1; një i gabuar përmend 192.168.120.1 dhe pajisjen macvlan. Nëse imazhi nuk përfshin paketën iproute2, skedari /proc përsëri raporton rrugën e paracaktuar, me destinacion 00000000 dhe bajtët e portës të përmbysur. Krahasoni kolonën e ndërfaqes me docker inspect kur emrat e pajisjeve nuk janë të qartë.

Macvlan është një portë fizike, jo një klon i urës

Macvlan i jep kontejnerit një identitet të dytë në kabllo, dhe pikërisht kjo e bën të funksionojë aksesin te pajisjet lokale. Kjo do të thotë gjithashtu se porta e komutatorit dhe hipervizori duhet të pranojnë një adresë MAC shtesë, dhe shumë rrjeta cloud e refuzojnë atë në heshtje. Provoni një kontejner përpara se të planifikoni një flotë, sepse një MAC i refuzuar zakonisht shfaqet si një lidhje që është lart dhe nuk kalon asgjë.

Cilësimi macvlan_mode: bridge është një mënyrë e drejtuesit macvlan, jo ura softuerike e Docker, dhe passthru është një mënyrë e veçantë e specializuar dhe jo një parazgjedhje. Linux gjithashtu e pengon një kontejner macvlan të arrijë hostin e vet përmes të njëjtit prind, dhe kjo është arsyeja pse ura e kontrollit mbahet në vend që të pritet që një lidhje të bëjë të dyja punët.

Emërtoni prindin e VLAN përpara se Compose ta shohë

Docker e trajton një prind me pikë si eno1.120 si një nën-ndërfaqe 802.1Q dhe e krijon vetë pajisjen VLAN. Ky komoditet ka kufij: emri i prejardhur varet nga emri i ndërfaqes fizike, dhe emrat e gjatë mund ta shtyjnë rezultatin përtej asaj që presin mjetet përreth. Krijimi i një ndërfaqeje VLAN me emër në konfigurimin e rrjetit të hostit dhe drejtimi i parent drejt saj i mban të dy skajet të parashikueshme.

Mbani mend se çelësi nën networks është një emër Compose, jo një pajisje Linux. Kërkimi në host për një ndërfaqe të quajtur office do të dështojë, sepse kernel-i sheh vetëm ndërfaqen prind dhe çiftin veth pas kontejnerit.

Bëni vend për VPN-në sipër

Një klient VPN lidhet pasi këto rrjeta ekzistojnë, kështu që mund të shtojë rrugë më specifike, rregulla politike dhe filtra pavarësisht nga gw_priority. Planifikoni prefikset e largëta kundrejt të dy subnet-eve lokale, duke përfshirë përgjigjet që i duhen rrugës së kontrollit. Kur një prefiks i largët mbivendoset me LAN-in e zyrës, rregulloni planin e adresave në vend që të shkëputni një interval privat të tërë nga tuneli.

Rikontrolloni adresat, rrugët dhe rrugën e shërbimit pasi VPN të nisë dhe edhe një herë pasi të rilidhet, sepse është pikërisht në rilidhje që zhduket një rrugë e shtuar me dorë. Shkruani tabelën e pritur përpara provës së parë, që krahasimi më pas të jetë një diff dhe jo një ushtrim kujtese. Mbani pronësinë e vazhdueshme të rrjetit në Compose dhe lëreni konfigurimin e VPN të zotërojë vetëm politikën e vet.

Artikuj të ngjashëm