Nå et webgrensesnitt inne i en VPN-container: velg portens eier

Det er ingenting galt med appen, og det er ingenting galt med tunnelen, og likevel lastes ikke dashbordet. Når en tjeneste kjører med network_mode: service:vpn, deler den VPN-containerens nettverksnavnerom, som betyr at lytteren og de publiserte portene tilhører det navnerommet og ikke tjenesten. Tre beslutninger følger av det: hvor appen binder, hvilken container som publiserer porten, og hvor smal administrasjonsstien er. Ta dem i feil rekkefølge, og hver enkelt innstilling ser riktig ut mens kombinasjonen ikke kan fungere.

Hvem eier portens navnerom

Med et delt navnerom gjør det ingen nytte å legge til en ports:-oppføring på den avhengige tjenesten, og flere nettverksvalg støttes ikke for den av design. Publiser i stedet på containeren som eier navnerommet. Den containeren er også den hvis adresse vises på verten, så tilordningen leses som én oppføring og ikke én per tjeneste.

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 adressen til venstre for tilordningen. Binding til 127.0.0.1 holder den publiserte porten på vertens loopback, noe et administrasjonsgrensesnitt vanligvis ønsker. Binding til 0.0.0.0 eksponerer den på alle vertens grensesnitt, og det er en annen sikkerhetsbeslutning, ikke en bekvemmelighet.

Få appen til å lytte der navnerommet forventer det

En lytter bundet til 127.0.0.1 inne i navnerommet er bare tilgjengelig fra innsiden av det navnerommet. Publiserte vertsportet kommer utenfra, så appen må binde en bredere adresse for at tilordningen skal virke. Det er en endring på én linje på de fleste servere, og det er nettopp det trinnet folk hopper over etter å ha kopiert en herdingsveiledning skrevet for en utrulling uten containere.

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

Lytterlisten inne i appen forteller sannheten om bindingsadressen, og docker port forteller hva eieren faktisk publiserte. Hvis den første viser 127.0.0.1 og den andre viser en vertstilordning, har du funnet avviket uten å røre VPN-konfigurasjonen.

Velg hvordan administrasjonsstien kommer inn

Det finnes tre rimelige ordninger. Publiser på VPN-containeren og nå den fra verten eller fra lokalnettet. Sett en omvendt proxy foran navnerommet og gi proxyen den eneste eksponerte porten. Eller hold dashbordet tilgjengelig bare fra innsiden av navnerommet via en exec-økt eller en SSH-tunnel, som er den minste eksponeringen og den minste bekvemmeligheten.

Hvilken som passer avhenger av hvem som trenger grensesnittet og hvorfra. Én administrator på samme vert klarer seg med en loopback-binding. Et team som når det over VPN, trenger en bevisst sti og en navngitt eier. Velger du proxy-alternativet, får du TLS og tilgangslogger, mot prisen av enda en komponent som må holdes oppdatert.

Åpne administrasjonsporten uten å åpne alt

VPN-klientens egen policy for lokal tilgang eller låsing kan forkaste en innkommende administrasjonsforespørsel selv mens den utgående tunnelen fungerer perfekt. Tillat ett dokumentert unntak for den tiltenkte kilden og porten, og bekreft deretter at tunnelens vanlige beskyttelse er uendret. Å deaktivere kill switch for å få et dashbord til å laste bytter en reell kontroll mot en nettleserfane.

La appens egen autentisering være påslått. Å være inne i en VPN-tilkoblet stabel autoriserer ikke enhver lokal bruker eller enhver enhet som kan nå verten, og et administrasjonspanel uten autentisering bak en tunnel er fortsatt et administrasjonspanel uten autentisering.

Verifiser fra administrasjonsenheten, og verifiser på nytt senere

Test fra maskinen som faktisk skal administrere tjenesten, ikke fra verten, og verifiser deretter appens nødvendige internettsti separat. En vellykket administrasjon beviser én retning og sier ingenting om utgående trafikk.

Test på nytt etter at stabelen er gjenskapt. En erstattet nettverkseier endrer navnerommet appen fester seg til, og en URL som virket før en oppdatering, kan etterpå peke på ingenting. Skriv ned den publiserte tilordningen og bindingsadressen, slik at neste gjenoppbygging blir en kontroll på to minutter i stedet for en gjentatt undersøkelse.