Een webinterface in een VPN-container bereiken: kies de poorteigenaar

De app deelt de VPN-naamruimte, dus de poort is van de VPN-container. Bind de listener correct, publiceer op de eigenaar en houd het pad smal.

Er is niets mis met de app en er is niets mis met de tunnel, en toch laadt het dashboard niet. Wanneer een dienst met network_mode: service:vpn draait, deelt hij de netwerknaamruimte van de VPN-container, wat betekent dat zijn listener en zijn gepubliceerde poorten bij die naamruimte horen en niet bij de dienst. Daaruit volgen drie beslissingen: waar de app bindt, welke container de poort publiceert en hoe smal het beheerpad is. Zet ze in de verkeerde volgorde en elke afzonderlijke instelling lijkt correct, terwijl de combinatie niet kan werken.

Wie bezit de naamruimte van de poort

In een gedeelde naamruimte levert het toevoegen van een ports:-vermelding aan de afhankelijke dienst niets nuttigs op, en verschillende netwerkopties worden er ontwerptechnisch niet voor ondersteund. Publiceer in plaats daarvan op de container die de naamruimte bezit. Die container is ook degene waarvan het adres op de host verschijnt, dus de toewijzing leest als één vermelding en niet als één per dienst.

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

Let op het adres links van de toewijzing. Binden aan 127.0.0.1 houdt de gepubliceerde poort op de loopback van de host, wat een beheerinterface meestal wil. Binden aan 0.0.0.0 stelt hem bloot op elke interface van de host, en dat is een andere beveiligingsbeslissing, geen gemak.

Laat de app luisteren waar de naamruimte het verwacht

Een listener die binnen de naamruimte aan 127.0.0.1 is gebonden, is alleen van binnen die naamruimte bereikbaar. Gepubliceerde hostpoorten komen van buiten, dus de app moet een breder adres binden wil de toewijzing werken. Dat is op de meeste servers een wijziging van één regel, en dat is precies de stap die mensen overslaan nadat ze een hardeninggids hebben gekopieerd die voor een uitrol zonder containers is geschreven.

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

De listenerlijst in de app vertelt de waarheid over het bindadres, en docker port vertelt wat de eigenaar werkelijk heeft gepubliceerd. Als de eerste 127.0.0.1 toont en de tweede een toewijzing op de host, hebt u de mismatch gevonden zonder de VPN-configuratie aan te raken.

Kies hoe het beheerpad binnenkomt

Er zijn drie redelijke opstellingen. Publiceer op de VPN-container en bereik hem vanaf de host of het LAN. Zet een reverse proxy voor de naamruimte en geef de proxy de enige blootgestelde poort. Of houd het dashboard alleen van binnen de naamruimte bereikbaar via een exec-sessie of een SSH-tunnel, wat de kleinste blootstelling en het minste gemak is.

Welke past hangt af van wie de interface nodig heeft en van waar. Eén beheerder op dezelfde host is geholpen met een loopback-binding. Een team dat hem via de VPN bereikt, heeft een bewust pad en een genoemde eigenaar nodig. De proxy-optie levert u TLS en toegangslogboeken op, tegen de prijs van nog een component die bijgehouden moet worden.

Open de beheerpoort zonder alles te openen

Het eigen lokale-toegangs- of vergrendelingsbeleid van de VPN-client kan een inkomend beheerverzoek laten vallen, zelfs terwijl de uitgaande tunnel perfect werkt. Sta één gedocumenteerde uitzondering toe voor de beoogde bron en poort en bevestig daarna dat de gewone bescherming van de tunnel onveranderd is. De killswitch uitzetten om een dashboard te laten laden, ruilt een echte controle tegen een browsertabblad.

Laat de eigen authenticatie van de app aan staan. Binnen een met VPN verbonden stack zitten geeft geen toestemming aan elke lokale gebruiker of elk apparaat dat de host kan bereiken, en een beheerpaneel zonder authenticatie achter een tunnel blijft een beheerpaneel zonder authenticatie.

Controleer vanaf het beheerapparaat en controleer later opnieuw

Test vanaf de machine die de dienst daadwerkelijk beheert, niet vanaf de host, en controleer daarna het internetpad dat de app nodig heeft apart. Een geslaagd beheer bewijst één richting en zegt niets over uitgaand verkeer.

Test opnieuw nadat de stack opnieuw is gemaakt. Een vervangen netwerkeigenaar verandert de naamruimte waaraan de app zich hecht, en een URL die voor een update werkte, kan daarna nergens meer naar wijzen. Noteer de gepubliceerde toewijzing en het bindadres, zodat de volgende herbouw een controle van twee minuten is in plaats van een herhaald onderzoek.

Gerelateerde artikelen