Docker i VM saobraćaj iza OpenVPN-a: ruta ili prenumerisanje?

Host pregleda kroz tunel, a kontejner pored njega ne doseže ništa. Objavljivanje porta iz kontejnera koji ima vlastiti VPN klijent je gore: zahtjev stiže, a odgovor nikada ne izlazi. Oba su odluke o rutiranju na hostu, a Docker je samo glasnik.

Tri pitanja odlučuju koji od ta dva slučaja gledate, i traju oko minute.

Dva kvara koja izgledaju isto

Prvi je problem povratnog puta. Objavljeni port se prevodi u kontejner, zahtjev stiže, a odgovor se rutira kroz zadanu rutu hosta, koju je OpenVPN klijent usmjerio na tun0. Odgovor izlazi s adrese koju udaljeni peer ne očekuje i biva odbačen. Drugi je sudar prefiksa: Dockerov zadani bridge posjeduje 172.17.0.0/16, a korporativni tunel gura isti raspon.

Jedan se popravlja tablicom rutiranja, drugi prenumerisanjem bridgea. Uređivanje prije nego što znate koji je koji je način da pokvarite ispravan kontejner.

Odlučite s tri pitanja

Pitanje prvo: nestaje li kvar kada isključite VPN? Ako sve radi s isključenim tunelom, sumnjajte na povratni put. Pitanje drugo: prikazuje li ip route show table all isti prefiks dvaput, jednom na bridgeu i jednom na tun0? To je sudar. Pitanje treće: je li pogođena adresa kontejner, NAT gost ili gost spojen preko bridgea?

Treće pitanje je važno jer svaki ima drugo ispravno rješenje, a primjena rješenja za kontejner na libvirt gosta gubi cijelu večer.

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

Povratni put: tablica za jednu izvornu adresu

Kada saobraćaj kontejnera mora izlaziti kroz fizičko sučelje dok sam host koristi tunel, rutiranje prema izvoru je najmanja promjena. Dodajte pravilo koje odgovara adresi kontejnera i pošaljite ga u namjensku tablicu. Ništa drugo na hostu se ne pomjera.

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

Svaki paket čiji je izvor ta adresa prvo provjerava tablicu 10, a tablica 10 ga šalje na gateway bridgea umjesto u tunel.

Potvrdite s ip route get 1.1.1.1 from 172.22.0.3. Odgovor mora navesti sučelje bridgea, ne tun0. Pravila dodana na ovaj način nestaju pri ponovnom pokretanju, pa ih stavite u unit ili mrežnu kuku koja posjeduje kontejner.

Isti obrazac radi za WireGuard kontejner, gdje i povratni put treba eksplicitno pravilo.

Sudar prefiksa: prenumerišite bridge

Tablica rutiranja šalje jedan prefiks na jedno mjesto. Ako VPN gura 172.17.0.0/16 dok Dockerov bridge već postoji, pobjeđuje niža metrika: Docker postavlja svoju povezanu rutu na metriku 0, a gurnuta ruta stiže na 50. Tunel tada izgleda pokvaren dok Docker nastavlja raditi, ili obrnuto, zavisno od reda instalacije. Prenumerišite bridge umjesto da se borite s metrikom.

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

Ponovo pokrenite Docker nakon promjene i ponovno stvorite mreže izgrađene sa starim poolom. Promjena metrike umjesto toga samo premješta sukob u sljedeće podizanje.

VM-ovi opet traže drugi odgovor

libvirt gost na zadanoj NAT mreži nasljeđuje rutiranje hosta i prestaje dosezati vanjski svijet kad tunel hosta preuzme zadanu rutu. Prebacivanje gosta na bridge ili macvtap uređaj daje mu vlastiti put na fizičkoj mreži. U virt-manageru dodajte hardver, odaberite Network, postavite izvor na macvtap host uređaj, zadržite virtio kao model, zatim deaktivirajte staro NAT sučelje.

macvtap gost obično ne može doseći vlastiti host. To je očekivano ponašanje, a ne kvar, i pripada u bilješku koju ostavljate.

Za gosta kojem treba samo LAN hosta, klijent dobavljača može imati prekidač koji nedostaje: s Mullvadom mullvad lan set allow vraća lokalnu dostupnost bez diranja libvirta. A kada kontejner mora biti dostupan samo kroz tunel, vežite objavljeni port na adresu tunela, -p 10.8.0.5:8080:8080, umjesto objavljivanja na svakoj adresi.