Kontejner s dvije mreže bira pogrešan gateway
Dva priključka, jedna zadana ruta i pogrešna mreža stalno pobjeđuje. Prikvačite izlaz uz Compose gw_priority i potvrdite to iznutra kontejnera.
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.