Docker- og VM-trafikk bakom OpenVPN: rute eller nummerere på nytt?

Containarar og gjester på ein vert med ein OpenVPN-klient mistar anten returvegen eller kolliderer med tunnelprefikset. Tre spørsmål vel løysinga.

Verten surfar gjennom tunnelen, og containeren ved sida av når ingenting. Å publisere ein port frå ein container som køyrer sin eigen VPN-klient er verre: førespurnaden kjem inn, og svaret forlèt aldri verten. Begge er rutingsavgjerder på verten, og Docker er berre bodberaren.

Tre spørsmål avgjer kva av dei to du ser på, og dei tek om lag eitt minutt.

To feil som ser like ut

Den fyrste er eit problem med returvegen. Ein publisert port blir omsett inn i containeren, førespurnaden kjem inn, og svaret blir ruta av standardruta til verten, som OpenVPN-klienten har peika på tun0. Svaret forlèt ein adresse som den eksterne parten ikkje ventar, og det blir droppa. Den andre er ein prefikskollisjon: standardbrua til Docker eig 172.17.0.0/16, og ein bedriftstunnel skyv det same området.

Den eine blir retta med ein rutetabell, den andre ved å nummerere ei bru på nytt. Å redigere før du veit kva som er kva, er måten å øydelegge ein fungerande container på.

Avgjer med tre spørsmål

Spørsmål ein: forsvinn feilen når du stoppar VPN-en? Viss alt verkar med tunnelen nede, mistenker du returvegen. Spørsmål to: viser ip route show table all det same prefikset to gonger, éin gong på ei bru og éin gong på tun0? Det er kollisjonen. Spørsmål tre: er den råka adressa ein container, ein NAT-gjest eller ein brua gjest?

Det tredje spørsmålet tel fordi kvar av dei har ei anna rett retting, og å bruke containerrettinga på ein libvirt-gjest kastar bort ein kveld.

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

Returveg: ein tabell for éi kjeldeadresse

Når containertrafikken må gå ut gjennom det fysiske grensesnittet medan verten sjølv brukar tunnelen, er kjeldebasert ruting den minste endringa. Legg til ein regel som svarar til adressa til containeren, og send han til ein eigen tabell. Ingenting anna på verten flyttar seg.

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

Kvar pakke med den adressa som kjelde slår opp tabell 10 først, og tabell 10 sender han til gatewayen til brua i staden for tunnelen.

Stadfest med ip route get 1.1.1.1 from 172.22.0.3. Svaret må namngje grensesnittet til brua, ikkje tun0. Reglar lagde til på denne måten forsvinn ved omstart, så legg dei i eininga eller nettverkskroken som eig containeren.

Same mønsteret fungerer for ein WireGuard-container, der returvegen òg treng ein eksplisitt regel.

Prefikskollisjon: nummerer brua på nytt

Ein rutetabell sender eitt prefiks til éin stad. Viss VPN-en skyv 172.17.0.0/16 medan Docker-brua allereie er der, vinn den lågaste metrikken: Docker installerer den tilknytte ruta si med metrikk 0, og den skyvde ruta kjem inn med 50. Då ser tunnelen øydelagd ut medan Docker held fram, eller omvendt, avhengig av installasjonsrekkjefølgja. Nummerer brua på nytt i staden for å kjempe mot metrikken.

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

Start Docker på nytt etter endringa og opprett nettverk som er bygde med den gamle poolen, på nytt. Å endre metrikken i staden flyttar berre konflikten til neste oppstart.

VM-ar treng igjen eit anna svar

Ein libvirt-gjest på standard NAT-nettverk arvar rutinga til verten og sluttar å nå utanfor når tunnelen til verten eig standardruta. Å flytte gjesten til ei brua eller macvtap-eining gir han sin eigen veg på det fysiske nettet. I virt-manager legg du til maskinvare, vel Network, set kjelda til macvtap-eininga til verten, held virtio som modell og deaktiverer deretter det gamle NAT-grensesnittet.

Ein macvtap-gjest kan vanlegvis ikkje nå sin eigen vert. Det er venta åtferd og ikkje ein feil, og det høyrer heime i notatet du legg igjen.

For ein gjest som berre treng LAN-et til verten, kan klienten til leverandøren ha den manglande brytaren: med Mullvad gjenopprettar mullvad lan set allow lokal tilgjenge utan å røre libvirt. Og når ein container berre skal vere tilgjengeleg gjennom tunnelen, bind den publiserte porten til tunneladressa, -p 10.8.0.5:8080:8080, i staden for å publisere han på kvar adresse.

Relaterte artiklar