Docker- és VM-forgalom OpenVPN mögött: útvonal vagy újraszámozás?

Az OpenVPN-klienssel futó gazdagépen a konténerek és vendégek vagy elveszítik a visszautat, vagy ütköznek az alagút előtagjával. Három kérdés választja ki a megoldást.

A gazdagép az alagúton keresztül böngészik, a mellette lévő konténer viszont semmit nem ér el. Még rosszabb portot közzétenni egy olyan konténerből, amely saját VPN-klienst futtat: a kérés megérkezik, a válasz pedig soha nem lép ki. Mindkettő útválasztási döntés a gazdagépen, a Docker csak a hírnök.

Három kérdés dönti el, melyik a két eset közül, amit lát, és körülbelül egy percet vesz igénybe.

Két hiba, amely ugyanúgy néz ki

Az első a visszaút problémája. A közzétett port befordítódik a konténerbe, a kérés megérkezik, a választ pedig a gazdagép alapértelmezett útvonala irányítja, amelyet a OpenVPN kliens a tun0 felé állított. A válasz olyan címről lép ki, amelyet a távoli fél nem vár, és eldobódik. A második előtagütközés: a Docker alapértelmezett hídja a 172.17.0.0/16-ot birtokolja, és egy vállalati alagút ugyanazt a tartományt tolja.

Az egyiket útválasztási táblával javítják, a másikat egy híd újraszámozásával. Szerkeszteni, mielőtt tudnád, melyik melyik, így lehet egy működő konténert tönkretenni.

Döntsd el három kérdéssel

Első kérdés: eltűnik-e a hiba, amikor leállítod a VPN-t? Ha minden működik lekapcsolt alagút mellett, gyanakodj a visszaútra. Második kérdés: felsorolja-e a ip route show table all ugyanazt az előtagot kétszer, egyszer egy hídon és egyszer a tun0-n? Ez az ütközés. Harmadik kérdés: az érintett cím konténer, NAT-vendég vagy hídra kötött vendég?

A harmadik kérdés azért számít, mert mindegyiknek más a helyes javítása, és a konténer javítását egy libvirt-vendégre alkalmazni egy estét pazarol el.

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

Visszaút: tábla egyetlen forráscímhez

Amikor a konténer forgalmának a fizikai interfészen kell kilépnie, miközben maga a gazdagép az alagutat használja, a forrásalapú útválasztás a legkisebb változtatás. Adj hozzá egy szabályt, amely a konténer címére illeszkedik, és küldd egy dedikált táblába. Semmi más nem mozdul a gazdagépen.

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

Minden csomag, amelynek forrása ez a cím, először a 10-es táblát nézi meg, és a 10-es tábla a híd átjárójához küldi az alagút helyett.

Ellenőrizd ezzel: ip route get 1.1.1.1 from 172.22.0.3. A válasznak a híd interfészét kell megneveznie, nem a tun0-t. Az így hozzáadott szabályok újraindításkor eltűnnek, ezért tedd őket abba az unitba vagy hálózati hookba, amely a konténert birtokolja.

Ugyanez a minta működik WireGuard-konténer esetén is, ahol a válaszútnak szintén kifejezett szabály kell.

Előtagütközés: számozd újra a hidat

Egy útválasztási tábla egy előtagot egy helyre küld. Ha a VPN a 172.17.0.0/16-ot tolja, miközben a Docker hídja már ott van, az alacsonyabb metrika nyer: a Docker a csatlakoztatott útvonalát 0 metrikával telepíti, a betoltott útvonal pedig 50 metrikával érkezik. Ilyenkor az alagút hibásnak tűnik, miközben a Docker tovább működik, vagy fordítva, a telepítés sorrendjétől függően. Számozd újra a hidat, ahelyett hogy a metrikával harcolnál.

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

A változtatás után indítsd újra a Dockert, és hozd létre újra a régi pool-lal épült hálózatokat. A metrika módosítása csak a következő indításra helyezi át az ütközést.

A VM-eknek megint más válasz kell

Az alapértelmezett NAT-hálózaton lévő libvirt-vendég örökli a gazdagép útválasztását, és amint a gazdagép alagútja birtokolja az alapértelmezett útvonalat, már nem éri el a külvilágot. A vendég áthelyezése hídra vagy macvtap-eszközre saját utat ad neki a fizikai hálózaton. A virt-managerben adj hozzá hardvert, válaszd a Network elemet, állítsd a forrást a macvtap gazdagépeszközre, tartsd meg a virtio modellt, majd kapcsold ki a régi NAT-interfészt.

Egy macvtap-vendég általában nem éri el a saját gazdagépét. Ez várt viselkedés, nem hiba, és a hátrahagyott feljegyzésbe való.

Egy olyan vendéghez, amelynek csak a gazdagép LAN-ja kell, a szállító kliensében lehet a hiányzó kapcsoló: a Mullvaddal a mullvad lan set allow helyi elérhetőséget állít vissza anélkül, hogy a libvirthoz nyúlna. És amikor egy konténernek csak az alagúton keresztül kell elérhetőnek lennie, kösd a közzétett portot az alagút címéhez, -p 10.8.0.5:8080:8080, ahelyett hogy minden címen közzétennéd.

Kapcsolódó cikkek