Provoz Dockeru a virtuálních strojů za OpenVPN: směrovat, nebo přečíslovat?

Hostitel prohlíží přes tunel a kontejner vedle něj nedosáhne na nic. Publikovat port z kontejneru, který má vlastního klienta VPN, je horší: požadavek dorazí a odpověď nikdy neodejde. Obojí jsou rozhodnutí o směrování na hostiteli a Docker je jen posel.

Který z těch dvou případů vidíte, rozhodnou tři otázky a zaberou asi minutu.

Dvě poruchy, které vypadají stejně

První je problém zpáteční cesty. Publikovaný port se přeloží do kontejneru, požadavek dorazí a odpověď se směruje podle výchozí trasy hostitele, kterou klient OpenVPN nasměroval na tun0. Odpověď odchází z adresy, kterou vzdálený protějšek nečeká, a je zahozena. Druhá je kolize prefixů: výchozí bridge Dockeru vlastní 172.17.0.0/16 a podnikový tunel protlačuje stejný rozsah.

Jedna se opraví směrovací tabulkou, druhá přečíslováním bridge. Upravovat dřív, než víte, která je která, je způsob, jak rozbít fungující kontejner.

Rozhodněte třemi otázkami

Otázka první: zmizí porucha, když vypnete VPN? Pokud všechno funguje s vypnutým tunelem, podezřívejte zpáteční cestu. Otázka druhá: vypisuje ip route show table all stejný prefix dvakrát, jednou na bridge a jednou na tun0? To je ta kolize. Otázka třetí: je postižená adresa kontejner, NAT host nebo host připojený přes bridge?

Třetí otázka je důležitá, protože každý má jinou správnou opravu, a aplikace opravy pro kontejner na hosta libvirt promrhá celý večer.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Zpáteční cesta: tabulka pro jednu zdrojovou adresu

Když provoz kontejneru musí odcházet přes fyzické rozhraní, zatímco hostitel sám používá tunel, směrování podle zdroje je nejmenší změna. Přidejte pravidlo odpovídající adrese kontejneru a pošlete ho do vyhrazené tabulky. Nic jiného na hostiteli se nepohne.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Každý paket, jehož zdrojem je tato adresa, nejdřív nahlédne do tabulky 10 a tabulka 10 ho pošle na bránu bridge místo do tunelu.

Ověřte pomocí ip route get 1.1.1.1 from 172.22.0.3. Odpověď musí uvádět rozhraní bridge, ne tun0. Pravidla přidaná tímto způsobem při restartu zmizí, proto je vložte do unit nebo síťového háku, který kontejner vlastní.

Stejný vzor funguje i pro kontejner WireGuard, kde i zpáteční cesta potřebuje výslovné pravidlo.

Kolize prefixů: přečíslujte bridge

Směrovací tabulka posílá jeden prefix na jedno místo. Pokud VPN protlačí 172.17.0.0/16, zatímco bridge Dockeru už tam je, vyhraje nižší metrika: Docker instaluje svou připojenou trasu s metrikou 0 a protlačená trasa dorazí s 50. Tunel pak vypadá rozbitý, zatímco Docker dál funguje, nebo naopak, podle pořadí instalace. Přečíslujte bridge, místo abyste bojovali s metrikou.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Po změně restartujte Docker a znovu vytvořte sítě postavené na starém poolu. Změna metriky místo toho jen přesune konflikt do dalšího startu.

Virtuální stroje chtějí zase jinou odpověď

Host libvirt ve výchozí síti NAT dědí směrování hostitele a přestane dosahovat ven, jakmile tunel hostitele získá výchozí trasu. Přepnutí hosta na bridge nebo zařízení macvtap mu dá vlastní cestu ve fyzické síti. Ve virt-manageru přidejte hardware, zvolte Network, nastavte zdroj na hostitelské zařízení macvtap, ponechte virtio jako model a potom deaktivujte staré rozhraní NAT.

Host macvtap obvykle nedosáhne na vlastního hostitele. To je očekávané chování, ne závada, a patří to do poznámky, kterou po sobě necháte.

Pro hosta, který potřebuje jen LAN hostitele, může mít klientský software dodavatele chybějící přepínač: u Mullvadu mullvad lan set allow obnoví místní dostupnost, aniž by se dotkl libvirtu. A když má být kontejner dostupný jen přes tunel, přivažte publikovaný port k adrese tunelu, -p 10.8.0.5:8080:8080, místo publikování na každé adrese.