Nå eit webgrensesnitt inne i ein VPN-container: vel portens eigar
Appen deler VPN-namnerommet, så porten høyrer til VPN-containeren. Bind lyttaren rett, publiser på eigaren og hald stien smal.
Det er ingenting gale med appen, og det er ingenting gale med tunnelen, og likevel vert dashbordet ikkje lasta. Når ei teneste køyrer med network_mode: service:vpn, deler ho nettverksnamnerommet til VPN-containeren, som tyder at lyttaren og dei publiserte portane høyrer til det namnerommet og ikkje til tenesta. Tre avgjerder følgjer av det: kvar appen bind, kva container som publiserer porten, og kor smal administrasjonsstien er. Ta dei i feil rekkjefølgje, og kvar einskild innstilling ser rett ut medan kombinasjonen ikkje kan fungere.
Kven eig portens namnerom
Med eit delt namnerom gjer det inga nytte å leggje til ein ports:-oppføring på den avhengige tenesta, og fleire nettverksval er ikkje støtta for henne av design. Publiser i staden på containeren som eig namnerommet. Den containeren er òg den der adressa blir vist på verten, så tilordninga blir lesen som éi oppføring og ikkje éi per teneste.
services:
vpn:
image: vpn-client-image
cap_add: [NET_ADMIN]
ports:
- "127.0.0.1:8080:8080"
app:
network_mode: "service:vpn"
Legg merke til adressa til venstre for tilordninga. Binding til 127.0.0.1 held den publiserte porten på loopbacken til verten, noko eit administrasjonsgrensesnitt vanlegvis vil ha. Binding til 0.0.0.0 eksponerer henne på alle grensesnitt på verten, og det er eit anna tryggleiksval, ikkje ei bekvemmelegheit.
Få appen til å lytte der namnerommet ventar det
Ein lyttar bunden til 127.0.0.1 inne i namnerommet er berre tilgjengeleg frå innsida av det namnerommet. Publiserte vertsportar kjem utanfrå, så appen må binde ei breiare adresse for at tilordninga skal verke. Det er ei endring på éi linje på dei fleste servarane, og det er nettopp det steget folk hoppar over etter å ha kopiert ei herdingsrettleiing skriven for ei utrulling utan containarar.
docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/
Lyttarlista inne i appen fortel sanninga om bindingsadressa, og docker port fortel kva eigaren faktisk publiserte. Viss den første viser 127.0.0.1 og den andre viser ei vertstilordning, har du funne avviket utan å røre VPN-konfigurasjonen.
Vel koss administrasjonsstien kjem inn
Det finst tre rimelege ordningar. Publiser på VPN-containeren og nå han frå verten eller frå lokalnettet. Set ein omvend proxy framfor namnerommet og gje proxyen den einaste eksponerte porten. Eller hald dashbordet tilgjengeleg berre frå innsida av namnerommet via ei exec-økt eller ein SSH-tunnel, som er den minste eksponeringa og den minste bekvemmelegheita.
Kva som passar avheng av kven som treng grensesnittet og kvarfrå. Éin administrator på same verten klarer seg med ei loopback-binding. Eit team som når det over VPN, treng ein medviten sti og ein namngjeven eigar. Vel du proxy-alternativet, får du TLS og tilgangsloggar, mot prisen av endå ein komponent som må haldast oppdatert.
Opne administrasjonsporten utan å opne alt
VPN-klienten sin eigen politikk for lokal tilgang eller låsing kan kaste bort ein innkommande administrasjonsførespurnad sjølv medan den utgåande tunnelen fungerer perfekt. Tillat eitt dokumentert unntak for den tiltenkte kjelda og porten, og stadfest deretter at den vanlege verna av tunnelen er uendra. Å slå av naudbrytaren for å få eit dashbord til å laste byter ein reell kontroll mot ei nettlesarfane.
La appens eigen autentisering vere påslått. Å vere inne i ein VPN-tilkopla stabel autoriserer ikkje kvar lokal brukar eller kvar eining som kan nå verten, og eit administrasjonspanel utan autentisering bak ein tunnel er framleis eit administrasjonspanel utan autentisering.
Stadfest frå administrasjonseininga, og stadfest på nytt seinare
Test frå maskinen som faktisk skal administrere tenesta, ikkje frå verten, og stadfest deretter den internettstien appen treng, separat. Vellukka administrasjon beviser éin retning og seier ingenting om utgåande trafikk.
Test på nytt etter at stabelen er attskapt. Ein erstatta nettverkseigar endrar namnerommet appen festar seg til, og ein URL som verka før ei oppdatering, kan etterpå peike på ingenting. Skriv ned den publiserte tilordninga og bindingsadressa, slik at neste gjenoppbygging blir ein kontroll på to minutt i staden for ei gjenteken gransking.