Konteineris su dviem tinklais pasirenka netinkamą šliuzą

Du prisijungimai, vienas numatytasis maršrutas, ir netinkamas tinklas visada laimi. Užfiksuokite išėjimą su Compose gw_priority ir patikrinkite tai konteinerio viduje.

Jūsų konteineris vis dar atsako savo valdymo tiltu, tačiau kiekvienas išeinantis paketas palieka tinklą per biuro macvlan. Niekas nesugedo. Du prisijungimai kiekvienas siūlo savo šliuzą, o vienintelis numatytasis maršrutas nukeliavo į tinklą, kurio nenorėjote, todėl paslauga toliau veikia, o jos srautas eina ilgesniu keliu. Kai kas nors tai pastebi, įrodymas yra maršrutų lentelė, o ne klaidos pranešimas.

Įprastas paaiškinimas yra tas, kad Docker tinklą pasirinko atsitiktinai. Praktiškai senasis sprendimas laikėsi prijungtų tinklų pavadinimų abėcėlės tvarkos, todėl maršrutizavimas tapo etiketės šalutiniu poveikiu. gw_priority pakeičia tai jūsų sąmoningai pasirenkamu skaičiumi, o perėjimas užima apie minutę, kai išdėstymas jau užrašytas.

Kodėl numatytasis maršrutas patenka į netinkamą tinklą

Kiekvienas tinklas, prie kurio prisijungia paslauga, gali pasiūlyti savo šliuzą, o konteineris vis tiek turi lygiai vieną numatytąjį maršrutą. Iki Compose 2.33.1 lygybė buvo sprendžiama rikiuojant tinklų pavadinimus, todėl etiketė kaip control, einanti prieš office, nustatydavo, kur keliaus srautas. Niekas konteinerio viduje neužrašo, kad sprendimas buvo savavališkas, todėl jis praeina kodo peržiūrą ir vėliau iškyla kaip keistas kelias. Politika compose faile yra vienintelis būdas padaryti pasirinkimą patikrinamą.

Kuris tinklas laimi, iš tikrųjų keičia du dalykai: jūsų priskirtos gw_priority reikšmės ir tai, kurie tinklai apskritai prijungti. Pridėkite trečią tinklą ir kandidatų rinkinys padidėja; pašalinkite macvlan ir nebeliks su kuo konkuruoti tiltui. Nė vienas žingsnis neatsiranda programos žurnaluose, nes netinkamas numatytasis maršrutas retai visiškai nutraukia ryšį. Jis tik leidžia atsakymams ateiti iš adreso, kurio kita pusė galbūt nesitiki.

Užfiksuokite šliuzą su gw_priority

Compose nuo 2.33.1 versijos pateikia gw_priority kiekviename paslaugos-tinklo prisijungime, ir laimi didžiausias skaičius. Atskiro šliuzo rakto paslaugai nėra, todėl reikšmė priklauso paslaugos networks blokui. Toliau pateiktas pavyzdys numatytąjį maršrutą atiduoda control, o office lieka pasiekiamas savo tiesiogiai prijungtam 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

Skaitykite bloką kaip du atskirus valdiklius: gw_priority nustato numatytąjį maršrutą, o ipam dalis nustato adresavimą. Pakeitus tik subnet, išėjimo pasirinkimas lieka nepaliestas, ir tai yra dažniausias būdas šį pataisymą pritaikyti pusėtinai. Laikykite prioritetus prie tinklo, kurį jie valdo, kad kitam skaitytojui nereikėtų ieškoti sprendimo.

Nesumaišykite gw_priority su paprasta priority savybe šalia. Ji tvarko ryšių kūrimo eiliškumą ir nieko nesako apie maršrutizavimą, todėl negali pasirinkti numatytojo šliuzo ir netaiso sąsajų pavadinimų. Jei kas nors pataria padidinti priority srautui nukreipti, patarimas neteisingas, net kai gauta tvarka atsitiktinai atrodo teisinga.

Patikrinkite, kuris tinklas iš tikrųjų neša numatytąjį maršrutą

Tikrinkite veikiančio konteinerio viduje, nes prieglobos maršrutų lentelė aprašo prieglobą, o ne vardų erdvę, kurią naudoja paslauga. Pirmiausia paleiskite konfigūracijos patikrą, kad rašybos klaida suveiktų prieš perkrovimą, tada perskaitykite maršrutą, kurį konteineris tikrai įdiegė.

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

Teisingas rezultatas nurodo tilto įrenginį ir 172.30.50.1; neteisingas nurodo 192.168.120.1 ir macvlan įrenginį. Jei atvaizde nėra iproute2 paketo, /proc failas vis tiek praneša numatytąjį maršrutą, su paskirties vieta 00000000 ir šliuzo baitais atvirkščiai. Kai įrenginių pavadinimai neaiškūs, palyginkite sąsajos stulpelį su docker inspect.

Macvlan yra fizinis prievadas, o ne tilto klonas

Macvlan suteikia konteineriui antrą tapatybę laidu, ir būtent tai leidžia pasiekti vietinius įrenginius. Tai taip pat reiškia, kad komutatoriaus prievadas ir hipervizorius turi priimti papildomą MAC adresą, o daugelis debesų tinklų to tyliai atsisako. Išbandykite vieną konteinerį prieš planuodami laivyną, nes atmestas MAC paprastai pasirodo kaip ryšys, kuris yra įjungtas ir nieko nepraleidžia.

Nustatymas macvlan_mode: bridge yra macvlan tvarkyklės režimas, o ne Docker programinis tiltas, o passthru yra atskiras specializuotas režimas, o ne numatytasis. Linux taip pat neleidžia macvlan konteineriui pasiekti savo prieglobos per tą patį tėvą, ir todėl paliekamas valdymo tiltas, o ne tikimasi, kad vienas prisijungimas atliks abu darbus.

Pavadinkite VLAN tėvą, kol Compose jo nepamatė

Docker laiko tėvą su tašku, pavyzdžiui, eno1.120, 802.1Q posąsaja ir pats sukuria VLAN įrenginį. Šis patogumas turi ribas: išvestinis pavadinimas priklauso nuo fizinės sąsajos pavadinimo, o ilgi pavadinimai gali nustumti rezultatą už aplinkinių įrankių lūkesčių. Pavadintos VLAN sąsajos sukūrimas prieglobos tinklo konfigūracijoje ir parent nukreipimas į ją daro abu galus nuspėjamus.

Atminkite, kad raktas po networks yra Compose pavadinimas, o ne Linux įrenginys. Ieškoti priegloboje sąsajos pavadinimu office nepavyks, nes branduolys mato tik tėvinę sąsają ir veth porą už konteinerio.

Padarykite vietos VPN viršuje

VPN klientas prisijungia po to, kai šie tinklai jau egzistuoja, todėl gali pridėti tikslesnių maršrutų, politikos taisyklių ir filtrų nepriklausomai nuo gw_priority. Planuokite nuotolinius prefiksus pagal abu vietinius subnet, įskaitant atsakymus, kurių reikia valdymo keliui. Kai nuotolinis prefiks susikerta su biuro LAN, taisykite adresų planą, o ne išplėškite visą privatų diapazoną iš tunelio.

Dar kartą patikrinkite adresus, maršrutus ir paslaugos kelią paleidus VPN ir dar kartą po jo prisijungimo iš naujo, nes būtent prisijungiant iš naujo dingsta ranka pridėtas maršrutas. Užsirašykite laukiamą lentelę prieš pirmą bandymą, kad vėlesnis palyginimas būtų diff, o ne atminties pratimas. Laikykite nuolatinę tinklo nuosavybę Compose, o VPN konfigūracija tevaldo tik savo politiką.

Susiję straipsniai