Kontejner se dvěma sítěmi volí špatnou bránu

Dvě připojení, jedna výchozí trasa a špatná síť vyhrává pořád. Přišpendlete východ pomocí Compose gw_priority a ověřte to zevnitř kontejneru.

Váš kontejner stále odpovídá na svém řídicím mostu, ale každý odchozí paket odchází přes kancelářský macvlan. Nic neselhalo. Dvě připojení dodávají každé vlastní bránu a jediná výchozí trasa šla k síti, kterou jste nezamýšleli, takže služba dál funguje, zatímco její provoz jde delší cestou. Než si toho někdo všimne, důkazem je směrovací tabulka, nikoli chybová zpráva.

Obvyklé vysvětlení je, že Docker vybral síť omylem. V praxi se staré rozhodnutí řídilo abecedním pořadím názvů připojených sítí, což ze směrování udělalo vedlejší efekt popisku. gw_priority to nahrazuje číslem, které volíte záměrně, a přechod na něj zabere asi minutu, jakmile je rozvržení zapsané.

Proč výchozí trasa skončí na špatné síti

Každá síť, ke které se služba připojí, může nabídnout vlastní bránu, a kontejner přesto skončí s právě jednou výchozí trasou. Před Compose 2.33.1 se nerozhodné pořadí řešilo setříděním názvů sítí, takže popisek jako control, který přichází před office, určoval, kam provoz půjde. Nic uvnitř kontejneru nezaznamenává, že rozhodnutí bylo libovolné, a proto projde revizí kódu a později se vynoří jako podivná cesta. Uložit zásadu do souboru compose je jediný způsob, jak volbu učinit přezkoumatelnou.

Která síť vyhraje, mění doopravdy dvě věci: hodnoty gw_priority, které přiřadíte, a to, které sítě jsou vůbec připojené. Přidejte třetí síť a množina kandidátů roste; odeberte macvlan a nezbývá nic, co by mostu konkurovalo. Ani jeden z kroků se neobjeví v protokolech aplikace, protože špatná výchozí trasa málokdy spojení úplně přeruší. Jen způsobí, že odpovědi přicházejí z adresy, kterou druhá strana nemusí čekat.

Přišpendlete bránu pomocí gw_priority

Compose vystavuje gw_priority u každého připojení služby k síti od verze 2.33.1 a vyhrává vyšší číslo. Klíč brány pro službu neexistuje, takže hodnota patří do bloku networks dané služby. Níže uvedený příklad předá výchozí trasu síti control a office zůstane dostupná pro svou přímo připojenou 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

Čtěte blok jako dvě oddělené ovládací prvky: gw_priority určuje výchozí trasu a část ipam určuje adresování. Změna pouze subnetu ponechá volbu východu nedotčenou, a to je nejčastější způsob, jak se tato oprava aplikuje napůl. Držte priority vedle sítě, kterou řídí, aby je další čtenář nemusel hledat.

Nezaměňujte gw_priority s obyčejnou vlastností priority vedle ní. Ta řadí vytváření spojení a o směrování neříká nic, takže nemůže vybrat výchozí bránu a neopravuje pojmenování rozhraní. Pokud někdo doporučuje zvýšit priority, aby nasměroval provoz, doporučení je špatné, i když výsledné pořadí náhodou vypadá správně.

Ověřte, která síť skutečně nese výchozí trasu

Kontrolujte uvnitř běžícího kontejneru, protože směrovací tabulka hostitele popisuje hostitele, ne jmenný prostor, který služba používá. Nejprve spusťte kontrolu konfigurace, aby překlep selhal dřív než restart, a potom přečtěte trasu, kterou kontejner opravdu nainstaloval.

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

Správný výsledek uvádí mostové zařízení a 172.30.50.1; špatný uvádí 192.168.120.1 a zařízení macvlan. Pokud obraz neobsahuje balíček iproute2, soubor /proc přesto hlásí výchozí trasu, s cílem 00000000 a bajty brány obráceně. Když jsou názvy zařízení nejasné, porovnejte sloupec rozhraní s docker inspect.

Macvlan je fyzický port, ne klon mostu

Macvlan dává kontejneru druhou identitu na drátě a právě to umožňuje přístup k místním zařízením. Znamená to také, že port přepínače a hypervizor musí přijmout další MAC adresu, a mnoho cloudových sítí to tiše odmítá. Otestujte jeden kontejner, než naplánujete flotilu, protože odmítnutá MAC se obvykle projeví jako spoj, který je nahoře a nic nepředává.

Nastavení macvlan_mode: bridge je režim ovladače macvlan, ne softwarový most Dockeru, a passthru je samostatný specializovaný režim, nikoli výchozí. Linux také brání kontejneru macvlan dosáhnout vlastního hostitele přes stejného rodiče, a to je důvod ponechat řídicí most místo očekávání, že jedno připojení zvládne obě práce.

Pojmenujte rodiče VLAN dřív, než ho Compose uvidí

Docker považuje rodiče s tečkou, jako je eno1.120, za podrozhraní 802.1Q a zařízení VLAN vytvoří sám. Tahle výhoda má meze: odvozený název závisí na názvu fyzického rozhraní a dlouhé názvy mohou výsledek vytlačit za to, co okolní nástroje očekávají. Vytvoření pojmenovaného rozhraní VLAN v konfiguraci sítě hostitele a nasměrování parent na něj udrží oba konce předvídatelné.

Pamatujte, že klíč pod networks je název Compose, ne linuxové zařízení. Hledání rozhraní zvaného office na hostiteli selže, protože jádro vidí jen rodičovské rozhraní a pár veth za kontejnerem.

Udělejte místo pro VPN navrch

Klient VPN se připojí poté, co tyto sítě existují, takže může přidat konkrétnější trasy, pravidla zásad a filtry bez ohledu na gw_priority. Plánujte vzdálené prefixy proti oběma místním subnetům, včetně odpovědí, které řídicí cesta potřebuje. Když se vzdálený prefix překryje s kancelářskou LAN, opravte plán adres, místo abyste z tunelu vytrhli celý privátní rozsah.

Znovu zkontrolujte adresy, trasy a cestu služby po startu VPN a ještě jednou po jejím opětovném připojení, protože právě při opětovném připojení mizí ručně přidaná trasa. Zapište očekávanou tabulku před prvním testem, aby následné srovnání bylo diffem a ne cvičením paměti. Držte trvalé vlastnictví sítě v Compose a nechte konfiguraci VPN vlastnit jen její vlastní zásadu.

Související články