Bereik ’n webkoppelvlak in ’n VPN-houer: kies die poort-eienaar

Die toep deel die VPN-naamruimte, dus die poort behoort aan die VPN-houer. Bind die luisteraar korrek, publiseer op die eienaar en hou die pad smal.

Daar is niks verkeerd met die toep nie en niks verkeerd met die tonnel nie, en tog laai die paneelbord nie. Wanneer ’n diens met network_mode: service:vpn loop, deel dit die VPN-houer se netwerknaamruimte, wat beteken dat sy luisteraar en sy gepubliseerde poorte aan daardie naamruimte behoort eerder as aan die diens. Drie besluite volg hieruit: waar die toep bind, watter houer die poort publiseer, en hoe smal die bestuurspad is. Kry dit in die verkeerde volgorde en elke individuele instelling lyk korrek terwyl die kombinasie nie kan werk nie.

Wie besit die poort-naamruimte

Met ’n gedeelde naamruimte doen die byvoeging van ’n ports:-inskrywing by die afhanklike diens niks nuttigs nie, en verskeie netwerkopsies word by ontwerp nie daarvoor ondersteun nie. Publiseer eerder op die houer wat die naamruimte besit. Daardie houer is ook die een wie se adres op die gasheer verskyn, so die kartering lees as een inskrywing eerder as een per diens.

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

Let op die adres links van die kartering. Binding aan 127.0.0.1 hou die gepubliseerde poort op die gasheer se loopback, wat gewoonlik is wat ’n bestuurskoppelvlak wil hê. Binding aan 0.0.0.0 stel dit op elke gasheerkoppelvlak bloot, en dit is ’n ander sekuriteitsbesluit eerder as ’n gerief.

Laat die toep luister waar die naamruimte dit verwag

’n Luisteraar wat binne die naamruimte aan 127.0.0.1 gebind is, is slegs van binne daardie naamruimte bereikbaar. Gepubliseerde gasheerpoorte kom van buite dit, so die toep moet ’n breër adres bind sodat die kartering kan werk. Dit is ’n eenreëlverandering in die meeste bedieners, en dit is die stap wat mense oorslaan nadat hulle ’n verhardingsgids gekopieer het wat vir ’n nie-houer-ontplooiing geskryf is.

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

Die luisteraarlys binne die toep vertel die waarheid oor die bindadres, en docker port vertel wat die eienaar werklik gepubliseer het. As die eerste 127.0.0.1 wys en die tweede ’n gasheerkartering wys, het jy die wanpassing gevind sonder om aan die VPN-konfigurasie te raak.

Kies hoe die bestuurspad inkom

Daar is drie redelike reëlings. Publiseer op die VPN-houer en bereik dit vanaf die gasheer of die LAN. Plaas ’n omgekeerde instaanbediener voor die naamruimte en gee die instaanbediener die enigste blootgestelde poort. Of hou die paneelbord slegs van binne die naamruimte bereikbaar deur ’n exec-sessie of ’n SSH-tonnel, wat die kleinste blootstelling en die minste gerief is.

Watter een pas, hang af van wie die koppelvlak nodig het en van waar. ’n Enkele administrateur op dieselfde gasheer word deur ’n loopback-binding bedien. ’n Span wat dit oor die VPN bereik, het ’n doelbewuste pad en ’n genoemde eienaar nodig. Om die instaanopsie te kies, bring vir jou TLS en toegangslogboeke, ten koste van nog ’n komponent wat bygehou moet word.

Maak die bestuursport oop sonder om alles oop te maak

Die VPN-kliënt se eie plaaslike-toegang- of grendelbeleid kan ’n inkomende bestuursversoek laat val selfs terwyl die uitgaande tonnel perfek werk. Staan een gedokumenteerde uitsondering toe vir die beoogde bron en poort, en bevestig dan dat die tonnel se gewone beskerming onveranderd is. Om die doodskakelaar te deaktiveer om ’n paneelbord te laat laai, ruil ’n werklike beheer vir ’n blaaier-oortjie.

Los die toep se eie verifikasie aangeskakel. Om binne ’n VPN-gekoppelde stapel te wees, magtig nie elke plaaslike gebruiker of elke toestel wat die gasheer kan bereik nie, en ’n ongestaafde administrasiepaneel agter ’n tonnel is steeds ’n ongestaafde administrasiepaneel.

Verifieer vanaf die bestuurstelsel, en verifieer later weer

Toets vanaf die masjien wat die diens werklik sal bestuur, nie vanaf die gasheer nie, en verifieer dan die toep se vereiste internetpad afsonderlik. ’n Bestuursukses bewys een rigting en sê niks oor uitgang nie.

Toets weer nadat die stapel herskep is. ’n Vervangde netwerkeienaar verander die naamruimte waaraan die toep heg, en ’n URL wat voor ’n opdatering gewerk het, kan daarna na niks wys nie. Skryf die gepubliseerde kartering en die bindadres neer sodat die volgende herbou ’n kontrole van twee minute is eerder as ’n herhaling van die ondersoek.

Verwante artikels