VPN-konténer hálózatának megosztása: mi történik a DNS-sel

A VPN-konténer hálózati névterének megosztása az alagút interfészeit és útvonalait adja az alkalmazásodnak. Nem adja neki az alagút feloldóját, és nem ad egyesített másolatot semmi másról a gazdagépen. Ez a rés nagyon konkrét hibát okoz: a nyilvános nevek feloldódnak, a belsők nem, és a meghiúsuló alkalmazás úgy tűnik, mintha rossz DNS-kiszolgálót használna, mert valóban azt használja. A javítás általában kisebb, mint amit a diagnózis sugall.

1. lépés: Az alkalmazásból tesztelj, ne a gazdagépről

Futtasd a keresést a problémás konténeren belül, ne a gazdagépen és ne böngészőben. docker exec app-container getent hosts db.internal arra az egyetlen kérdésre válaszol, amely számít: mit ad vissza ennek a folyamatnak a feloldója.

Ha a gazdagép feloldja a nevet, a konténer pedig nem, megtaláltad a hibát. Minden ezután a támogatott javítási mód kiválasztása.

2. lépés: Olvasd el a futtatókörnyezet támogatott modelljét

A Docker hálózati dokumentációja korlátozásokat rögzít a DNS-kapcsolókra azoknál a konténereknél, amelyek egy másik konténer hálózati módját használják. A Compose-ban network_mode: service:vpn az alkalmazást a VPN-konténer névteréhez köti, és szolgáltatásonként dns a beállítások nem úgy viselkednek, mint egy hétköznapi szolgáltatásnál. A kapott feloldás az, amivel a megosztott névtér rendelkezik.

A felhasználó által meghatározott hídhálózatok is másképp használják a Docker beépített DNS-ét, mint az alapértelmezett híd. Ezért egy dns működő hídpéldából másolt záradék semmit sem tehet egy megosztott veremben. A záradék másolása előtt ellenőrizd az elrendezést.

A loopback-cím mindig a vonatkozó hálózati kontextusra utal. Egy megosztott névtéren belül 127.0.0.1 nem a gazdagép feloldója.

3. lépés: Kövesd a lekérdezést a címzettjéig

Olvasd el az alkalmazás feloldókonfigurációját, majd minden alkalmazásspecifikus titkosított DNS-t, amelyet az alkalmazás hoz magával, mert a saját feloldót futtató alkalmazás figyelmen kívül hagyja az általad szerkesztett fájlt. Ezután ellenőrizd, hogy a kiválasztott feloldó elérhető-e a VPN útvonalai és tűzfal-szabályzata alatt. A feloldó címe az alagút túloldalán haszontalan, ha a névtérnek nincs útvonala hozzá. Szerkessz bármilyen fájlt csak a címzett megerősítése után.

A böngésző IP-ellenőrző oldala nem tudja megmondani, hová mentek a névlekérdezések. Azt mondja meg, hová ment egy HTTP-kapcsolat.

4. lépés: A két hibatípust különbözőképpen javítsd

Ha a szolgáltatásnevek meghiúsulnak, miközben a nyilvános nevek működnek, a probléma a konténerhálózaton belüli szolgáltatásfelderítés, nem a nyilvános feloldók listája. Minden nyilvános DNS-cím megváltoztatása nem hoz létre olyan rekordokat, amelyeket a hálózat felderítési mechanizmusától soha nem kértek.

Ha mindkét típus meghiúsul, kezdd a feloldó elérhetőségével. Ha csak az egyik hiúsul meg, kezdd a felderítési mechanizmussal. A kettőnek különböző tulajdonosai vannak, ezért egy javítás soha nem fedi le mindkettőt.

5. lépés: Újratesztelés újralétrehozás után

Módosítsd a konfigurációt a futtatókörnyezet támogatott mechanizmusán keresztül, majd hozd létre újra a konténereket ahelyett, hogy egy futó konténeren belül szerkesztenél fájlokat. Tesztelj egy friss privát nevet, egy friss nyilvános nevet és a keresést követő alkalmazáskérést. A /etc/resolv.conf konténeren belüli szerkesztése eltűnik az újralétrehozásnál, és meggyőz arról, hogy a javítás működött, amikor nem.

Jegyezd fel a feloldó tulajdonosát és a várt névteret a megosztott hálózat definíciója mellé. A következő embernek mindkettőre szüksége lesz.