Ein Web-UI in einem VPN-Container erreichen: den Port-Eigentümer wählen

Die App teilt den VPN-Namensraum, also gehört der Port dem VPN-Container. Binden Sie den Listener richtig, veröffentlichen Sie beim Eigentümer und halten Sie den Pfad schmal.

An der App ist nichts falsch und am Tunnel ist nichts falsch, und trotzdem lädt das Dashboard nicht. Läuft ein Dienst mit network_mode: service:vpn, teilt er den Netzwerk-Namensraum des VPN-Containers, was bedeutet, dass sein Listener und seine veröffentlichten Ports zu diesem Namensraum gehören und nicht zum Dienst. Daraus folgen drei Entscheidungen: wo die App bindet, welcher Container den Port veröffentlicht und wie schmal der Verwaltungspfad ist. Bringen Sie sie in die falsche Reihenfolge, und jede einzelne Einstellung sieht richtig aus, während die Kombination nicht funktionieren kann.

Wem der Port-Namensraum gehört

In einem geteilten Namensraum bringt das Hinzufügen eines ports:-Eintrags zum abhängigen Dienst nichts Nützliches, und mehrere Netzwerkoptionen werden dafür konstruktionsbedingt nicht unterstützt. Veröffentlichen Sie stattdessen auf dem Container, dem der Namensraum gehört. Dieser Container ist auch der, dessen Adresse auf dem Host erscheint, sodass die Zuordnung als ein Eintrag gelesen wird und nicht als einer pro Dienst.

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

Beachten Sie die Adresse links von der Zuordnung. Die Bindung an 127.0.0.1 hält den veröffentlichten Port auf dem Loopback des Hosts, was eine Verwaltungsschnittstelle üblicherweise will. Die Bindung an 0.0.0.0 legt ihn auf jeder Host-Schnittstelle offen, und das ist eine andere Sicherheitsentscheidung, keine Bequemlichkeit.

Lassen Sie die App dort lauschen, wo der Namensraum es erwartet

Ein innerhalb des Namensraums an 127.0.0.1 gebundener Listener ist nur von innerhalb dieses Namensraums erreichbar. Veröffentlichte Host-Ports kommen von außerhalb, also muss die App eine breitere Adresse binden, damit die Zuordnung funktioniert. Das ist bei den meisten Servern eine Zeile Änderung, und genau diesen Schritt überspringen Leute, nachdem sie eine Härtungsanleitung kopiert haben, die für eine Bereitstellung ohne Container geschrieben wurde.

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

Die Listener-Auflistung in der App sagt die Wahrheit über die Bindungsadresse, und docker port zeigt, was der Eigentümer tatsächlich veröffentlicht hat. Zeigt das erste 127.0.0.1 und das zweite eine Host-Zuordnung, haben Sie die Diskrepanz gefunden, ohne die VPN-Konfiguration anzufassen.

Wählen Sie, wie der Verwaltungspfad hereinkommt

Es gibt drei vernünftige Anordnungen. Veröffentlichen Sie auf dem VPN-Container und erreichen Sie ihn vom Host oder aus dem LAN. Setzen Sie einen Reverse-Proxy vor den Namensraum und geben Sie dem Proxy den einzigen exponierten Port. Oder halten Sie das Dashboard nur von innerhalb des Namensraums über eine exec-Sitzung oder einen SSH-Tunnel erreichbar, was die kleinste Exposition und den geringsten Komfort bedeutet.

Welche passt, hängt davon ab, wer die Schnittstelle braucht und von wo. Ein einzelner Administrator auf demselben Host ist mit einer Loopback-Bindung gut bedient. Ein Team, das sie über das VPN erreicht, braucht einen bewussten Pfad und einen benannten Eigentümer. Die Proxy-Option bringt Ihnen TLS und Zugriffsprotokolle, zum Preis einer weiteren Komponente, die aktuell gehalten werden muss.

Öffnen Sie den Verwaltungsport, ohne alles zu öffnen

Die eigene Richtlinie des VPN-Clients für lokalen Zugriff oder Sperre kann eine eingehende Verwaltungsanfrage verwerfen, selbst wenn der ausgehende Tunnel einwandfrei funktioniert. Erlauben Sie eine dokumentierte Ausnahme für die vorgesehene Quelle und den Port und bestätigen Sie dann, dass der übliche Schutz des Tunnels unverändert ist. Den Kill-Switch zu deaktivieren, damit ein Dashboard lädt, tauscht eine echte Kontrolle gegen einen Browser-Tab.

Lassen Sie die eigene Authentifizierung der App aktiviert. Innerhalb eines VPN-verbundenen Stacks zu sein, berechtigt nicht jeden lokalen Benutzer und nicht jedes Gerät, das den Host erreichen kann, und ein nicht authentifiziertes Admin-Panel hinter einem Tunnel bleibt ein nicht authentifiziertes Admin-Panel.

Prüfen Sie vom Verwaltungsgerät aus und prüfen Sie später erneut

Testen Sie von der Maschine, die den Dienst tatsächlich verwalten wird, nicht vom Host, und prüfen Sie dann den von der App benötigten Internetpfad getrennt. Ein Verwaltungserfolg beweist eine Richtung und sagt nichts über den ausgehenden Verkehr.

Testen Sie erneut, nachdem der Stack neu erstellt wurde. Ein ersetzter Netzwerk-Eigentümer ändert den Namensraum, an den sich die App anhängt, und eine URL, die vor einem Update funktionierte, kann danach auf nichts zeigen. Notieren Sie die veröffentlichte Zuordnung und die Bindungsadresse, damit der nächste Neuaufbau eine Zwei-Minuten-Prüfung ist statt einer erneuten Untersuchung.

Ähnliche Artikel