Nå ett webbgränssnitt inuti en VPN-container: välj portens ägare

Appen delar VPN:ns namnrymd, så porten tillhör VPN-containern. Bind lyssnaren rätt, publicera på ägaren och håll vägen smal.

Det är inget fel på appen och det är inget fel på tunneln, och ändå laddas inte instrumentpanelen. När en tjänst körs med network_mode: service:vpn, delar den VPN-containerns nätverksnamnrymd, vilket betyder att dess lyssnare och dess publicerade portar tillhör den namnrymden och inte tjänsten. Tre beslut följer av det: var appen binder, vilken container som publicerar porten och hur smal administrationsvägen är. Ta dem i fel ordning och varje enskild inställning ser korrekt ut medan kombinationen inte kan fungera.

Vem äger portens namnrymd

I en delad namnrymd gör det ingen nytta att lägga till en ports:-post på den beroende tjänsten, och flera nätverksalternativ stöds inte för den av design. Publicera i stället på containern som äger namnrymden. Den containern är också den vars adress syns på värden, så mappningen läses som en post och inte en per tjänst.

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

Lägg märke till adressen till vänster om mappningen. Bindning till 127.0.0.1 håller den publicerade porten på värdens loopback, vilket ett administrationsgränssnitt oftast vill. Bindning till 0.0.0.0 exponerar den på alla värdens gränssnitt, och det är ett annat säkerhetsbeslut, inte en bekvämlighet.

Låt appen lyssna där namnrymden förväntar sig det

En lyssnare bunden till 127.0.0.1 inne i namnrymden är bara nåbar inifrån den namnrymden. Publicerade värdportar kommer utifrån, så appen måste binda en bredare adress för att mappningen ska fungera. Det är en ändring på en rad på de flesta servrar, och det är just det steget folk hoppar över efter att ha kopierat en härdningsguide skriven för en driftsättning utan containrar.

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

Lyssnarlistan inne i appen säger sanningen om bindningsadressen, och docker port säger vad ägaren faktiskt publicerade. Om den första visar 127.0.0.1 och den andra visar en värdmappning, har du hittat avvikelsen utan att röra VPN-konfigurationen.

Välj hur administrationsvägen kommer in

Det finns tre rimliga upplägg. Publicera på VPN-containern och nå den från värden eller från lokalnätet. Sätt en omvänd proxy framför namnrymden och ge proxyn den enda exponerade porten. Eller håll instrumentpanelen nåbar bara inifrån namnrymden via en exec-session eller en SSH-tunnel, vilket är den minsta exponeringen och den minsta bekvämligheten.

Vilken som passar beror på vem som behöver gränssnittet och varifrån. En enda administratör på samma värd klarar sig med en loopback-bindning. Ett team som når den över VPN behöver en medveten väg och en namngiven ägare. Väljer du proxy-alternativet får du TLS och åtkomstloggar, mot priset av ytterligare en komponent som måste hållas uppdaterad.

Öppna administrationsporten utan att öppna allt

VPN-klientens egen policy för lokal åtkomst eller låsning kan kasta bort en inkommande administrationsbegäran även när den utgående tunneln fungerar perfekt. Tillåt ett dokumenterat undantag för den avsedda källan och porten och bekräfta sedan att tunnelns vanliga skydd är oförändrat. Att stänga av nödstoppet för att få en instrumentpanel att laddas byter en verklig kontroll mot en webbläsarflik.

Låt appens egen autentisering vara påslagen. Att vara inne i en VPN-ansluten stack ger inte varje lokal användare eller varje enhet som kan nå värden behörighet, och en adminpanel utan autentisering bakom en tunnel är fortfarande en adminpanel utan autentisering.

Verifiera från administrationsenheten och verifiera sedan igen senare

Testa från maskinen som faktiskt ska administrera tjänsten, inte från värden, och verifiera sedan appens nödvändiga internetväg separat. En lyckad administration bevisar en riktning och säger ingenting om det utgående.

Testa igen efter att stacken har återskapats. En utbytt nätverksägare ändrar den namnrymd som appen fäster vid, och en URL som fungerade före en uppdatering kan efteråt inte peka någonstans. Skriv ned den publicerade mappningen och bindningsadressen så att nästa ombyggnad blir en kontroll på två minuter i stället för en upprepad undersökning.

Relaterade artiklar