Nå en webgrænseflade inde i en VPN-container: vælg portens ejer

Appen deler VPN-navnerummet, så porten tilhører VPN-containeren. Bind lytteren korrekt, udgiv på ejeren, og hold stien smal.

Der er intet galt med appen, og der er intet galt med tunnelen, og alligevel indlæses dashboardet ikke. Når en tjeneste kører med network_mode: service:vpn, deler den VPN-containerens netværksnavnerum, hvilket betyder, at dens lytter og dens udgivne porte tilhører det navnerum og ikke tjenesten. Tre beslutninger følger af det: hvor appen binder, hvilken container der udgiver porten, og hvor smal administrationsstien er. Tag dem i den forkerte rækkefølge, og hver enkelt indstilling ser rigtig ud, mens kombinationen ikke kan fungere.

Hvem ejer portens navnerum

Med et delt navnerum gør det ingen nytte at tilføje en ports:-post til den afhængige tjeneste, og flere netværksindstillinger understøttes ikke for den af design. Udgiv i stedet på den container, der ejer navnerummet. Den container er også den, hvis adresse optræder på værten, så tilknytningen læses som én post i stedet for én for hver tjeneste.

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

Bemærk adressen til venstre for tilknytningen. Binding til 127.0.0.1 holder den udgivne port på værtens loopback, hvilket normalt er det, en administrationsgrænseflade ønsker. Binding til 0.0.0.0 blotlægger den på alle værtsgrænseflader, og det er en anden sikkerhedsbeslutning, ikke en bekvemmelighed.

Få appen til at lytte, hvor navnerummet forventer det

En lytter bundet til 127.0.0.1 inde i navnerummet kan kun nås indefra navnerummet. Udgivne værtsporte kommer udefra, så appen skal binde en bredere adresse, for at tilknytningen kan virke. Det er en ændring på én linje på de fleste servere, og det er netop det trin, folk springer over, efter de har kopieret en hærdningsvejledning skrevet til en installation uden 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 inde i appen fortæller sandheden om bindingsadressen, og docker port fortæller, hvad ejeren faktisk udgav. Hvis den første viser 127.0.0.1, og den anden viser en værts tilknytning, har du fundet uoverensstemmelsen uden at røre VPN-konfigurationen.

Vælg, hvordan administrationsstien kommer ind

Der er tre rimelige ordninger. Udgiv på VPN-containeren, og nå den fra værten eller fra LAN. Sæt en omvendt proxy foran navnerummet, og giv proxyen den eneste eksponerede port. Eller hold dashboardet tilgængeligt kun indefra navnerummet via en exec-session eller en SSH-tunnel, hvilket er den mindste eksponering og den mindste bekvemmelighed.

Hvilken der passer, afhænger af, hvem der har brug for grænsefladen, og hvorfra. En enkelt administrator på samme vært er godt tjent med en loopback-binding. Et team, der når den over VPN, har brug for en bevidst sti og en navngivet ejer. Vælger du proxy-muligheden, får du TLS og adgangslogfiler, for prisen af endnu en komponent, der skal holdes opdateret.

Åbn administrationsporten uden at åbne alt

VPN-klientens egen politik for lokal adgang eller lockdown kan droppe en indgående administrationsanmodning, selv mens den udgående tunnel fungerer perfekt. Tillad én dokumenteret undtagelse for den tilsigtede kilde og port, og bekræft derefter, at tunnelens sædvanlige beskyttelse er uændret. At deaktivere kill switch for at få et dashboard til at indlæse bytter en reel kontrol for en browservane.

Lad appens egen godkendelse være slået til. At være inde i en VPN-forbundet stak godkender ikke enhver lokal bruger eller enhver enhed, der kan nå værten, og et administrationspanel uden godkendelse bag en tunnel er stadig et administrationspanel uden godkendelse.

Verificér fra styreenheden, og verificér igen senere

Test fra den maskine, der faktisk skal administrere tjenesten, ikke fra værten, og verificér derefter appens krævede internetsti separat. En vellykket administration beviser én retning og siger intet om udgående trafik.

Test igen, når stakken er genskabt. En udskiftet netværksejer ændrer det navnerum, som appen knytter sig til, og en URL, der virkede før en opdatering, kan bagefter pege på ingenting. Skriv den udgivne tilknytning og bindingsadressen ned, så den næste genopbygning er et to-minutters tjek i stedet for en gentagen undersøgelse.

Relaterede artikler