Webes felület elérése VPN-konténeren belül: válassza ki a port gazdáját

Az alkalmazás osztozik a VPN névtérén, ezért a port a VPN-konténerhez tartozik. Kösse be helyesen a figyelőt, tegye közzé a gazdánál, és tartsa szűken az útvonalat.

Az alkalmazással nincs baj, és az alagúttal sincs baj, az irányítópult mégsem töltődik be. Amikor egy szolgáltatás network_mode: service:vpn beállítással fut, osztozik a VPN-konténer hálózati névterén, ami azt jelenti, hogy a figyelője és a közzétett portjai ahhoz a névtérhez tartoznak, nem a szolgáltatáshoz. Ebből három döntés következik: hová kötődik az alkalmazás, melyik konténer teszi közzé a portot, és mennyire szűk a felügyeleti útvonal. Rossz sorrendben csinálja őket, és minden egyes beállítás helyesnek látszik, miközben a kombináció nem működhet.

Ki birtokolja a port névterét

Megosztott névtérben a ports: bejegyzés hozzáadása a függő szolgáltatáshoz semmi hasznosat nem tesz, és több hálózati beállítás tervezésből nem támogatott hozzá. Tegye közzé inkább azon a konténeren, amelyik birtokolja a névteret. Ez a konténer az is, amelynek a címe a gazdagépen megjelenik, ezért a leképezés egy bejegyzésként olvasható, nem szolgáltatásonként egyként.

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

Figyelje meg a leképezéstől balra lévő címet. A 127.0.0.1-hez kötés a közzétett portot a gazdagép loopbackjén tartja, amit egy felügyeleti felület általában szeret. A 0.0.0.0-hoz kötés minden gazdagép-interfészen kitárja, és ez más biztonsági döntés, nem kényelem.

Késztesse az alkalmazást ott figyelni, ahol a névtér várja

A névtéren belül 127.0.0.1-hez kötött figyelő csak a névtér belsejéből érhető el. A közzétett gazdagép-portok kívülről érkeznek, ezért az alkalmazásnak szélesebb címet kell kötnie, hogy a leképezés működjön. Ez a legtöbb szerveren egy soros változtatás, és pontosan ezt a lépést hagyják ki az emberek, miután lemásoltak egy keményítési útmutatót, amelyet konténer nélküli telepítéshez írtak.

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

Az alkalmazáson belüli figyelőlista az igazat mondja a kötési címről, és a docker port megmutatja, mit tett közzé a gazda valójában. Ha az első 127.0.0.1-et mutat, a második pedig gazdagép-leképezést, akkor megtalálta az eltérést anélkül, hogy hozzányúlt volna a VPN beállításaihoz.

Válassza ki, hogyan jut be a felügyeleti útvonal

Három ésszerű elrendezés van. Tegye közzé a VPN-konténeren, és érje el a gazdagépről vagy a helyi hálózatról. Tegyen fordított proxyt a névtér elé, és adja a proxynak az egyetlen kitett portot. Vagy tartsa az irányítópultot csak a névtér belsejéből elérhetően egy exec-munkameneten vagy SSH-alagúton át, ami a legkisebb kitettség és a legkevesebb kényelem.

Melyik illik, attól függ, kinek és honnan kell a felület. Egyetlen rendszergazda ugyanazon a gazdagépen megelégszik egy loopback-kötéssel. A VPN-en át érkező csapatnak megfontolt útvonalra és megnevezett gazdára van szüksége. A proxy lehetőség TLS-t és hozzáférési naplókat ad, cserébe még egy karbantartandó összetevőért.

Nyissa meg a felügyeleti portot anélkül, hogy mindent megnyitna

A VPN-kliens saját helyi hozzáférési vagy lezárási szabályzata eldobhat egy bejövő felügyeleti kérést akkor is, amikor a kimenő alagút hibátlanul működik. Engedélyezzen egy dokumentált kivételt a szándékolt forráshoz és porthoz, majd erősítse meg, hogy az alagút szokásos védelme változatlan maradt. A vészfék kikapcsolása azért, hogy egy irányítópult betöltődjön, valódi ellenőrzést cserél egy böngészőfülre.

Hagyja bekapcsolva az alkalmazás saját hitelesítését. Az, hogy valaki egy VPN-hez kapcsolt verem belsejében van, nem jogosít fel minden helyi felhasználót és minden eszközt, amely eléri a gazdagépet, és egy hitelesítés nélküli adminpanel az alagút mögött is hitelesítés nélküli adminpanel marad.

Ellenőrizze a felügyeleti eszközről, majd ellenőrizze újra később

Teszteljen arról a gépről, amely valóban felügyelni fogja a szolgáltatást, ne a gazdagépről, majd külön ellenőrizze az alkalmazás által igényelt internetútvonalat. A felügyelet sikere egy irányt bizonyít, és semmit sem mond a kimenő forgalomról.

Tesztelje újra, miután a vermet újra létrehozták. A lecserélt hálózati gazda megváltoztatja a névteret, amelyhez az alkalmazás csatlakozik, és egy frissítés előtt működő URL utána semmire sem mutathat. Írja fel a közzétett leképezést és a kötési címet, hogy a következő újraépítés kétperces ellenőrzés legyen, ne megismételt vizsgálat.

Kapcsolódó cikkek