Miért nem éri el a Docker-konténer a VPN mögötti gazdagépeket

Egy konténer, amely semmit sem ér el a vállalati VPN mögött, általában más hálózati névtérben él, mint az alagút. A gazdagép-kliens útvonalai, DNS-kiszolgálói és tűzfal-jelölései a gazdagép vereméhez tartoznak; a hídhálózatos konténernek sajátja van. Ez az egyetlen tény magyarázza a platformcsapathoz érkező jelentések többségét, és ez az oka annak is, hogy a „a VPN elromlott” és a „a Docker megkerüli a VPN-t” egyszerre is lehet téves. Két nagyon különböző beállítás bújik meg egyetlen tünet mögött, ezért állapítsa meg, melyik van Önnél, mielőtt bármely beállítást módosít.

Állapítsa meg, kinek a névteréhez tartozik az alagút

A macOS-hez vagy Windowshoz készült Docker Desktop alatt a konténerek egy Linux virtuális gépen belül futnak. Az asztali gépre telepített VPN-kliens alagutat hoz létre az asztali operációs rendszerben, és a virtuális gép soha nem látja. Semmilyen konténerkonfiguráció nem javítja ezt, mert az az interfész, amelyre a konténernek szüksége lenne, egyáltalán nem létezik a hálózati névterében.

Linux gazdagépen az alagút a gazdagép névterében él, és a híd-konténerek általában a gazdagép útválasztási tábláján keresztül érik el, a kimenetnél alkalmazott forrás-NAT-tal. Amikor ez az útvonal meghiúsul, az ok általában továbbítási irányelv, fordított útvonal szűrése vagy egy átfedő alhálózat, nem pedig hiányzó útvonal. Erősítse meg, melyik világban van, mielőtt tovább olvasna:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

A két útválasztási tábla közötti különbség az egész probléma egyetlen képernyőn. Ha a gazdagép nézetében ott van az alagút interfésze, a hídéban pedig nem, névtér-izolációt lát, és minden más arról szóló döntés, hogyan lehet átkelni rajta.

A gazdagép hálózata teszt, nem tervezés

Ha egy konténert gazdagép-hálózattal futtat, amelyet a Docker a gazdagép hálózati névterének megosztásaként dokumentál, az közvetlenül örökli az alagút interfészét és útvonalait. Ha ugyanaz a kérés ezután sikerül, az útvonalelmélet beigazolódik, és a hiba névtér-izoláció, nem hitelesítő adatok, DNS vagy hozzáférési szabály.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Tartsa meg diagnosztikaként. A gazdagép-hálózat feladja a portközzétételt és a konténertől várt izoláció nagy részét, a Docker Desktop alatt pedig a „host” a virtuális gépet jelenti, nem az asztalt, így az ottani siker vagy kudarc megtévesztheti, ha elfelejti, melyik gazdagépet célozta.

Egy tun eszköz és a vele járó jogosultságok

A konténeren belüli VPN-kliensnek alagút-eszközre és annak konfigurálására vonatkozó engedélyre van szüksége. A szokásos rövidítés a --privileged, amely minden eszközt megad, és fellazítja a biztonsági irányelvet az egész konténerben. Ez sokkal több, mint amit ez a feladat igényel, és nehéz megindokolni egy felülvizsgálatban.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

A szűkebb forma az egyetlen eszközcsomópontot képezi le, és csak a hálózatfelügyeleti képességet adja hozzá. Először töltse be a modult a gazdagépen, hogy a csomópont létezzen. Ha a konténer elindul, és a kliens jelzi, hogy nem tudja megnyitni az alagút-eszközt, ellenőrizze a leképezést, mielőtt a profilra gyanakodna, mert ez a hiba általában szó szerinti.

Ez a tervezés azt is jelenti, hogy a kliens konténerenként fut. Ez a helyes válasz, ha minden munkaterhelésnek saját alagútra van szüksége, és a helytelen, ha csak a gazdagép alagútját szerette volna láthatóvá tenni, amit a platformcsapat valószínűleg feltételezett.

A híd NAT-ja megváltoztatja a forrást, amelyet a VPN lát

Az alapértelmezett hídnál a konténer kimenő forgalma a gazdagép címére fordul. Ezért a VPN mögött a vállalati oldal a gazdagép alagút-címét látja a konténeré helyett, a forrás szerinti hozzáférési szabályok úgy viselkednek, mintha a gazdagép küldte volna a kérést, és két konténer megkülönböztethetetlenné válik a VPN-kiszolgáló számára.

A macvlan vagy az ipvlan ehelyett LAN-címet ad a konténernek, ami segíti a LAN-felfedezést, és a konténert a szegmens egyenrangú tagjaként mutatja. Teljesen megkerüli a gazdagép alagútját is, így az ilyen konténer nem éri el a csak-VPN-előtagokat, hacsak a VPN abból a LAN-ból is elérhető.

Mindkét forma legitim; különböző követelményekre válaszolnak. Ha a követelmény az, hogy „ennek a konténernek el kell érnie egy csak-VPN-szolgáltatást”, akkor a gazdagépen keresztüli útválasztás és az alagút konténeren belüli lezárása között választ. Írja le ezt a döntést a telepítés előtt, ne az első sikertelen kérés után. Bármit is választ, jegyezze fel a forráscímet, amelyet a távoli fél látni fog, mert pontosan ezt mutatják majd a hozzáférési szabályai és a naplói. Egy tervezés, amely nem tudja megnevezni ezt a címet, nincs kész.

A DNS a démont követi, nem az alagutat

A konténer indításkor kapja meg a feloldó konfigurációját, a démonból vagy az image-ből másolva. A VPN által csatlakozás után küldött címek túl későn érkeznek ehhez a másolathoz, és a gazdagép feloldójához kerülnek, nem a konténerbe.

Állítsa be a feloldót kifejezetten a szolgáltatáshoz, vagy irányítsa egy belső feloldóra, amely az alagúton keresztül elérhető. Az a konténer, amely egy privát nevet nyilvános címre old fel, általában nyilvános feloldót használ, nem törött útvonaltól szenved, és a javítás a compose-fájlba vagy a démon konfigurációjába tartozik.

Ugyanez a logika vonatkozik a kimeneti cím kérdésére. Ha minden konténernek más VPN-címről kell megjelennie, egyetlen gazdagép-alagút nem tudja ezt nyújtani, mert a NAT egyetlen forrásba vonja össze őket. A járható formák egy kliens minden konténer névterében vagy egy sidecar, amely birtokolja az alagutat és megosztja a vermét, és mindkettő megváltoztatja, hogyan címezhető az alkalmazás.

Ellenőrzőlista a jegy lezárása előtt: azonosítsa az alagutat birtokló névteret, bizonyítsa az útvonalat gazdagép-hálózattal, csak a szükséges tun eszközt képezze le, jegyezze meg a forráscímet NAT után, állítsa be kifejezetten a feloldót, és kezelje a konténerenkénti kimeneti címeket architektúradöntésként, nem kapcsolóként.