Vaš kontejner još uvijek odgovara na svom kontrolnom mostu, ali svaki odlazni paket izlazi kroz uredski macvlan. Ništa nije otkazalo. Dva priključka daju po jedan gateway, a jedina zadana ruta otišla je na mrežu koju niste namjeravali, pa usluga nastavlja raditi dok njezin promet ide dužim putem. Kad to netko primijeti, dokaz je tablica rutiranja, a ne poruka o grešci.

Uobičajeno objašnjenje je da je Docker odabrao mrežu slučajno. U praksi je stara odluka slijedila abecedni red naziva priključenih mreža, što je rutiranje pretvorilo u nuspojavu oznake. gw_priority to zamjenjuje brojem koji birate namjerno, a usvajanje traje oko minute nakon što je raspored zapisan.

Zašto zadana ruta završi na pogrešnoj mreži

Svaka mreža kojoj se usluga pridruži može ponuditi vlastiti gateway, a kontejner ipak završi s točno jednom zadanom rutom. Prije Compose 2.33.1 neriješeno se rješavalo sortiranjem naziva mreža, pa je oznaka poput control koja dolazi prije office odlučivala kamo promet ide. Ništa u kontejneru ne bilježi da je odluka bila proizvoljna, zato ona prolazi pregled koda i kasnije se pojavi kao neobičan put. Stavljanje pravila u compose datoteku jedini je način da izbor bude provjerljiv.

Dvije stvari doista mijenjaju koja mreža pobjeđuje: vrijednosti gw_priority koje dodijelite i to koje su mreže uopće priključene. Dodajte treću mrežu i skup kandidata raste; uklonite macvlan i nema više ničega da se natječe s mostom. Nijedan potez se ne vidi u zapisnicima aplikacije, jer pogrešna zadana ruta rijetko prekida vezu posve. Samo čini da odgovori stižu s adrese koju druga strana možda ne očekuje.

Prikvačite gateway uz gw_priority

Compose izlaže gw_priority na svakom priključku usluge na mrežu od verzije 2.33.1, a pobjeđuje najveći broj. Ne postoji ključ gatewaya po usluzi, pa vrijednost pripada u blok networks te usluge. Primjer ispod dodjeljuje zadanu rutu mreži control, dok office ostaje dostupna za svoj izravno povezani 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

Čitajte blok kao dvije odvojene kontrole: gw_priority odlučuje o zadanoj ruti, a ipam dio odlučuje o adresiranju. Promjena samo subnet-a ostavlja izbor izlaza netaknutim, a to je najčešći način da ovo rješenje bude primijenjeno napola. Držite prioritete uz mrežu kojom upravljaju da sljedeći čitatelj ne mora tražiti odluku.

Ne miješajte gw_priority s običnim svojstvom priority pored njega. Ono poreda stvaranje veza i ne govori ništa o rutiranju, pa ne može odabrati zadani gateway i ne popravlja imenovanje sučelja. Ako netko preporuči podizanje priorityja da usmjeri promet, preporuka je pogrešna čak i kad rezultirajući redoslijed slučajno izgleda ispravno.

Provjerite koja mreža doista nosi zadanu rutu

Provjeravajte unutar pokrenutog kontejnera, jer tablica rutiranja hosta opisuje host, a ne imenski prostor koji usluga koristi. Prvo pokrenite provjeru konfiguracije da tipfeler padne prije restarta, zatim pročitajte rutu koju je kontejner stvarno instalirao.

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

Ispravan rezultat navodi mostovni uređaj i 172.30.50.1; pogrešan navodi 192.168.120.1 i macvlan uređaj. Ako slika ne sadrži paket iproute2, datoteka /proc i dalje prijavljuje zadanu rutu, s odredištem 00000000 i bajtovima gatewaya obrnutim. Usporedite stupac sučelja s docker inspect kad su nazivi uređaja nejasni.

Macvlan je fizički port, a ne klon mosta

Macvlan daje kontejneru drugi identitet na mreži i upravo to omogućuje pristup lokalnim uređajima. To također znači da priključak preklopnika i hipervizor moraju prihvatiti dodatnu MAC adresu, a mnoge oblak-mreže to tiho odbijaju. Testirajte jedan kontejner prije planiranja flote, jer odbijena MAC adresa obično izgleda kao veza koja je podignuta i ništa ne propušta.

Postavka macvlan_mode: bridge način je upravljačkog programa macvlan, a ne Dockerov softverski most, a passthru je zaseban specijalizirani način, a ne zadani. Linux također sprječava macvlan kontejner da dosegne vlastiti host kroz isti roditelj, i to je razlog da se kontrolni most zadrži umjesto očekivanja da jedan priključak obavi oba posla.

Imenujte VLAN roditelja prije nego ga Compose vidi

Docker tretira roditelja s točkom poput eno1.120 kao 802.1Q podsučelje i sam stvara VLAN uređaj. Ta pogodnost ima granice: izvedeni naziv ovisi o nazivu fizičkog sučelja, a dugi nazivi mogu gurnuti rezultat izvan onoga što okolni alati očekuju. Stvaranje imenovanog VLAN sučelja u mrežnoj konfiguraciji hosta i usmjeravanje parent na njega čini oba kraja predvidljivima.

Zapamtite da je ključ pod networks Compose naziv, a ne Linux uređaj. Traženje sučelja zvanog office na hostu neće uspjeti, jer jezgra vidi samo roditeljsko sučelje i veth par iza kontejnera.

Napravite mjesta za VPN povrh toga

VPN klijent se priključuje nakon što te mreže postoje, pa može dodati preciznije rute, pravila politike i filtre neovisno o gw_priority. Planirajte udaljene prefikse prema obama lokalnim subnetima, uključujući odgovore koje kontrolni put treba. Kad se udaljeni prefiks preklopi s uredskim LAN-om, popravite plan adresa umjesto da cijeli privatni raspon iščupate iz tunela.

Ponovno provjerite adrese, rute i put usluge nakon što VPN krene i još jednom nakon ponovnog spajanja, jer se upravo pri ponovnom spajanju gubi ručno dodana ruta. Zapišite očekivanu tablicu prije prvog testa da usporedba poslije bude diff, a ne vježba pamćenja. Zadržite trajno vlasništvo nad mrežom u Composeu i pustite VPN konfiguraciji da posjeduje samo vlastitu politiku.

Povezani članci