Miért nem tud válaszolni egy macvlan konténer egy VPN kliensnek

Képzeljen el egy Linux gazdagépet, amely lezár egy VPN-t, és közben egy konténert is futtat egy macvlan hálózaton. A LAN 192.168.60.0/24, a konténer a 192.168.60.210 címet tartja, a VPN kliensek pedig a 10.95.0.0/24 hálózatból érkeznek. A kliens eléri a szolgáltatást, a válasz soha nem jön vissza, és a gazdagépen minden tűzfal-szabály helyesnek tűnik. Ezt a tünetet két különálló korlát okozza, és az egyik javítása a másikat a helyén hagyja.

Két korlát, egy tünet

Az első korlát az elkülönítés: a Docker macvlan illesztőprogramja nem engedi, hogy egy konténer a szülő-interfészen keresztül beszéljen a saját gazdagépével. A gazdagép verme és a konténer közötti forgalomnak nincs útja, akárhogyan is vannak megírva az útvonalak a gazdagépen.

A második korlát a visszaút. A konténer alapértelmezett átjárója általában a LAN router, ezért a VPN kliensnek címzett válasz azon a routeren keresztül megy ki. Ha a routernek nincs útvonala vissza a VPN készletbe, a válasz valahol középen eldobódik.

A két hiba a kliens szemszögéből azonosnak látszik: megérkezik egy kérés, és soha nem érkezik meg a válasz. Különböző javításokat igényelnek, és egy széles masquerade szabály elrejtheti, melyikük romlott még el. Ezért az első teszt egy csomagrögzítés a konténer oldalán, és nem egy újabb tűzfal-módosítás. Ha a kérés ott soha nem jelenik meg, akkor az elkülönítési korlát van játékban.

Építse fel a gazdagép oldali shimet, szűken

Egy második macvlan interfész a gazdagépen, ugyanahhoz a szülőhöz híd módban csatlakoztatva, saját identitást ad a gazdagép vermének azon a LAN szegmensen. Foglaljon le neki egy címet a DHCP készleten kívül és a konténer tartományán kívül, és csak a konténert irányítsa rajta keresztül.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Az első parancs híd módban hozza létre az interfészt, ami ennek az illesztőprogramnak a dokumentált alapértelmezése, és ez a mód kell a gazdagép és a konténer közötti forgalomhoz. A második /32-t ad, hogy a cím ne ütközzön a LAN előtaggal, a negyedik pedig csak a konténer címét küldi át a shimen.

Ne irányítsa át a teljes LAN-t az új interfészen. A szokásos csatlakoztatott útvonal úgy marad, ahogy van, a gazdagép útvonala pedig szándékosan szűk, hogy egy konténer utat kapjon anélkül, hogy a szegmens többi része megváltoztatná a viselkedését. Egy a shimre mutató alapértelmezett útvonal más következményekkel járó más tervezés lenne. Tartsa konkrétnak, és a kár sugara kicsi marad.

Ezek a parancsok módosítják a hálózati beállításokat egy futó gazdagépen. Készüléken vagy felügyelt platformon használja az adott platform támogatott konfigurációs mechanizmusát, mert egy interaktív root-shell módosítás nem biztos, hogy túlél egy frissítést.

Döntse el, hogyan őrizhető meg a forrás

Ha a shim a helyén van, a konténer eléri a gazdagépet, és a kérdés az lesz, milyen forráscímet hordoz a válasz. Az eredeti VPN forrás megőrzése a tisztább modell: a konténer látja a kliens valódi címét, és a szolgáltatás naplói és hozzáférési szabályai használhatják.

Ehhez a konténer hálózati konfigurációjának ezen az útvonalon a 10.95.0.0/24 forgalmát a 192.168.60.250 címre kell küldenie átjáróként. Ez a konténer saját konfigurációján belüli támogatott útvonal- vagy átjáróbeállítás, nem gazdagép oldali trükk. Erősítse meg a konténer belsejéből, ahelyett hogy feltételezné, hogy a beállítás érvénybe lépett. Az alapértelmezett átjáró, amely még mindig a LAN routerre mutat, továbbra is ugyanabba a lyukba küldi a válaszokat.

Ha a jóváhagyott terv inkább elrejti a VPN forrásokat, szűkítse a fordítást: a valódi VPN készlet, a shim mint kimenő interfész, valamint a konkrét konténer és szolgáltatás.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

A shimet kimenő interfészként illessze, nem az alagutat. Egy szabály, amely az alagutat nevezi meg kimenő interfészként, nem fog illeszkedni a konténer felé tartó csomagra, és pont ez a hiba szokott lenni az ilyen beállításban. Tartsa a szabályt olyan szűken, mint a fenti mondat, és vizsgálja felül, amikor a készlet változik.

A kliensről ellenőrizze, ne a gazdagépről

A gazdagépről magáról indított, a shim címéhez kötött kérés bizonyítja, hogy a shim eléri a konténert. Azt nem bizonyítja, hogy a konténer vissza tudja küldeni a forgalmat egy megőrzött 10.95.0.x forráshoz, mert abban a tesztben a forráscím a shim saját címe.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Az első parancs a gazdagéptől a konténerig tartó szakaszt teszteli, a második pedig megmutatja, mi halad át valóban a shimen, miközben egy valódi VPN kliens indítja a kérést. Nézze meg a forráscímet a bejövő úton, és azt, hogy megjelenik-e azonos folyammal egy válasz.

A gazdagépen engedélyezni kell a továbbítást, és a továbbítási útvonalnak engedélyeznie kell a VPN készlet és a shim közötti forgalmat a szolgáltatás portján, valamint a létrejött válaszokat. A gazdagép INPUT szabálya nem engedélyezi a továbbított forgalmat, és ez gyakori oka annak, hogy a csomag elvész, miután az útválasztás helyesnek tűnik.

Futtassa a valódi alkalmazást valódi hitelesítő adatokkal, majd ellenőrizze, hogy egy második, nem kapcsolódó szolgáltatás ugyanazon a konténeren továbbra is elutasítja-e önt. Ha a működéshez egyetlen út a továbbítási szabályok mindegyikének megnyitása volt, a tervezés nincs kész. Jegyezze fel azt is, milyen forráscímet rögzített a szolgáltatás, mert ezt fogják használni a saját hozzáférési szabályai mostantól.