Prevádzka Dockeru a virtuálnych strojov za OpenVPN: smerovať alebo prečíslovať?

Hostiteľ prehliada cez tunel a kontajner vedľa neho nedosiahne nič. Publikovať port z kontajnera, ktorý má vlastného klienta VPN, je horšie: požiadavka dorazí a odpoveď nikdy neodíde. Obe sú rozhodnutia o smerovaní na hostiteľovi a Docker je len posol.

Ktorý z tých dvoch prípadov vidíte, rozhodnú tri otázky a zaberú asi minútu.

Dve poruchy, ktoré vyzerajú rovnako

Prvá je problém spiatočnej cesty. Publikovaný port sa preloží do kontajnera, požiadavka dorazí a odpoveď sa smeruje podľa predvolenej trasy hostiteľa, ktorú klient OpenVPN nasmeroval na tun0. Odpoveď odchádza z adresy, ktorú vzdialený partner neočakáva, a je zahodená. Druhá je kolízia prefixov: predvolený most Dockeru vlastní 172.17.0.0/16 a podnikový tunel pretláča rovnaký rozsah.

Jedna sa opraví smerovacou tabuľkou, druhá prečíslovaním mosta. Upravovať skôr, než viete, ktorá je ktorá, je spôsob, ako pokaziť fungujúci kontajner.

Rozhodnite tromi otázkami

Otázka prvá: zmizne porucha, keď vypnete VPN? Ak všetko funguje s vypnutým tunelom, podozrievajte spiatočnú cestu. Otázka druhá: vypisuje ip route show table all rovnaký prefix dvakrát, raz na moste a raz na tun0? To je tá kolízia. Otázka tretia: je postihnutá adresa kontajner, NAT hosť alebo hosť pripojený cez most?

Tretia otázka je dôležitá, pretože každý má inú správnu opravu, a aplikácia opravy pre kontajner na hosťa libvirt premrhá 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}}'

Spiatočná cesta: tabuľka pre jednu zdrojovú adresu

Keď prevádzka kontajnera musí odchádzať cez fyzické rozhranie, zatiaľ čo hostiteľ sám používa tunel, smerovanie podľa zdroja je najmenšia zmena. Pridajte pravidlo zodpovedajúce adrese kontajnera a pošlite ho do vyhradenej tabuľky. Nič iné na hostiteľovi sa 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, ktorého zdrojom je táto adresa, najprv nahliadne do tabuľky 10 a tabuľka 10 ho pošle na bránu mosta namiesto do tunela.

Overte pomocou ip route get 1.1.1.1 from 172.22.0.3. Odpoveď musí uviesť rozhranie mosta, nie tun0. Pravidlá pridané týmto spôsobom pri reštarte zmiznú, preto ich vložte do unit alebo sieťového háku, ktorý kontajner vlastní.

Rovnaký vzor funguje aj pre kontajner WireGuard, kde aj spiatočná cesta potrebuje výslovné pravidlo.

Kolízia prefixov: prečíslujte most

Smerovacia tabuľka posiela jeden prefix na jedno miesto. Ak VPN pretláča 172.17.0.0/16, zatiaľ čo most Dockeru už tam je, vyhrá nižšia metrika: Docker nainštaluje svoju pripojenú trasu s metrikou 0 a pretlačená trasa dorazí s 50. Tunel potom vyzerá pokazený, zatiaľ čo Docker ďalej funguje, alebo naopak, podľa poradia inštalácie. Prečíslujte most namiesto boja s metrikou.

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

Po zmene reštartujte Docker a znova vytvorte siete postavené na starom poole. Zmena metriky namiesto toho len presunie konflikt do ďalšieho štartu.

Virtuálne stroje chcú zase inú odpoveď

Hosť libvirt v predvolenej sieti NAT dedí smerovanie hostiteľa a prestane dosahovať von, len čo tunel hostiteľa získa predvolenú trasu. Prepnutie hosťa na most alebo zariadenie macvtap mu dá vlastnú cestu vo fyzickej sieti. Vo virt-manageri pridajte hardvér, vyberte Network, nastavte zdroj na hostiteľské zariadenie macvtap, ponechajte virtio ako model a potom deaktivujte staré rozhranie NAT.

Hosť macvtap zvyčajne nedosiahne na vlastného hostiteľa. To je očakávané správanie, nie porucha, a patrí to do poznámky, ktorú po sebe necháte.

Pre hosťa, ktorý potrebuje len LAN hostiteľa, môže mať klientsky softvér dodávateľa chýbajúci prepínač: s Mullvadom mullvad lan set allow obnoví miestnu dostupnosť bez toho, aby sa dotkol libvirtu. A keď má byť kontajner dostupný len cez tunel, priviažte publikovaný port k adrese tunela, -p 10.8.0.5:8080:8080, namiesto publikovania na každej adrese.