So richten Sie ein dediziertes Docker-Netzwerk für Reverse-Proxy-Backends ein

Verbinden Sie den Reverse-Proxy und jedes HTTP-Backend mit einem gemeinsamen benutzerdefinierten Netzwerk; belassen Sie Datenbanken in privaten App-Netzwerken.

Es ist nicht erforderlich, jeden Backend-Port auf dem NAS-Host zu veröffentlichen, wenn der Proxy Compose-Dienstnamen in einer benutzerdefinierten Bridge auflösen kann. Ein Zwei-Netzwerk-Muster gibt dem Proxy einen kontrollierten Pfad zu Web-Backends, während Datenbanken nur für ihre Anwendungen erreichbar bleiben. Definieren Sie den Netzwerkbesitz, vermeiden Sie mehrdeutige Aliase, entscheiden Sie, welche Dienste ausgehenden Zugriff benötigen, und überprüfen Sie, dass Host-Ports geschlossen bleiben.

Erstellen Sie die beabsichtigte Erreichbarkeitsmatrix

Listen Sie jede Verbindung auf: Client zum Proxy, Proxy zum Backend, Backend zur Datenbank, Backend zu externen APIs sowie Administrator zu Wartungsendpunkten. Kennzeichnen Sie Protokoll, Port, DNS-Namen und ob der Pfad den Host durchquert.

Normalerweise sollte nur der Reverse-Proxy die Ports 80 und 443 veröffentlichen. Backends stellen ihren Anwendungsport im Docker-Netzwerk bereit, ohne eine ports-Zuordnung zum Host. Datenbanken werden nur mit dem privaten App-Netzwerk verbunden, sofern kein ausdrücklicher Administrationspfad erforderlich ist.

Wählen Sie stabile, eindeutige Dienstnamen oder Netzwerkaliase. Docker-DNS löst Dienste in gemeinsamen benutzerdefinierten Netzwerken auf, aber allgemeine Aliase wie web können kollidieren, wenn viele Compose-Projekte mit demselben Proxy-Netzwerk verbunden sind.

Erstellen Sie ein gemeinsames Proxy-Netzwerk und ein privates App-Netzwerk

Erstellen Sie das Proxy-Netzwerk einmal, kennzeichnen Sie es in jedem Anwendungsprojekt als extern und verbinden Sie den Proxy sowie das vorgesehene Backend damit. Dadurch bleibt die Netzwerkidentität stabil, wenn ein einzelnes Compose-Projekt neu erstellt wird.

Definieren Sie für jede App ein separates standardmäßiges oder benanntes privates Netzwerk und verbinden Sie Backend und Datenbank damit. Das Backend wird zur kontrollierten Brücke zwischen Proxy-Datenverkehr und privatem Zustand; der Proxy sollte nicht dem Datenbanknetzwerk beitreten.

Die Compose-Netzwerkdefinitionen dokumentieren externe Netzwerke und die Dienstverbindung in Compose. Behandeln Sie ein externes Netzwerk als außerhalb des App-Stacks verwaltet: Beim Deployment muss geprüft werden, dass es vorhanden ist, statt anzunehmen, dass Compose es erstellt oder löscht.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Entfernen Sie unnötige Host-Ports und prüfen Sie den ausgehenden Datenverkehr

Entfernen Sie die Veröffentlichungen von Backend-Ports auf dem Host, sobald die Proxy-Route funktioniert. Die Deklaration expose kann den Container-Port dokumentieren, ist aber keine Firewall; die Netzwerkzugehörigkeit bestimmt, welche Container eine Verbindung herstellen können.

Verwenden Sie internal: true nur für Netzwerke, deren Mitglieder tatsächlich keine externe Route benötigen. Backends, die Identitätsanbieter, Webhooks, Paketdienste oder entfernte APIs aufrufen, können in einem rein internen Netzwerk ausfallen. Verwenden Sie ein zweites Netzwerk mit ausgehendem Zugriff, wenn das Anwendungsdesign dies erfordert.

Schützen Sie den Docker-Socket, der für die automatische Proxy-Erkennung verwendet wird. Ein schreibgeschütztes Bind-Mount reduziert versehentliche Schreibvorgänge, macht den Socket aber nicht harmlos; ein eingeschränkter Socket-Proxy oder eine statische Konfiguration bietet eine kleinere Angriffsfläche.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Überprüfen Sie Dienst-DNS, Port-Freigaben und Isolation

Lösen Sie im Proxy-Container den Backend-Dienstnamen auf und rufen Sie dessen Health-Endpunkt am Container-Port auf. Bestätigen Sie in einem unabhängigen Container, dass der Name oder die Verbindung nicht verfügbar ist, sofern dieser Container nicht absichtlich mit dem Proxy-Netzwerk verbunden ist.

Scannen Sie den NAS-Host von einem anderen LAN-Gerät und bestätigen Sie, dass nur die Proxy-Ports offen sind. Testen Sie anschließend TLS, weitergeleitete Header, WebSocket-Upgrades, große Uploads und Anwendungsweiterleitungen über den öffentlichen Hostnamen. Die Dienstübersicht des Heimservers sollte das Proxy-Netzwerk als Teil der Dienstübersicht des Heimservers dokumentieren.

Führen Sie ein Rollback durch, indem Sie die vorherige Port-Zuordnung nur zur Diagnose wiederherstellen, nicht als dauerhafte versteckte Abhängigkeit. Halten Sie an, wenn der Proxy direkten Datenbankzugriff benötigt, Aliase zum falschen Projekt weiterleiten oder das Entfernen eines Host-Ports eine undokumentierte Integration unterbricht.

FAQ 

Ist ein externes Docker-Netzwerk automatisch sicherer?

Nein. „Extern“ beschreibt den Lebenszyklusbesitz, nicht die Sicherheit. Im Allgemeinen kann jeder verbundene Container gemäß dem Verhalten des Netzwerk-Treibers und der Host-Firewall kommunizieren.

Sollten Backend-Dienste weiterhin expose deklarieren?

Für die Verbindung in einem benutzerdefinierten Netzwerk ist es optional, kann aber den vorgesehenen Container-Port dokumentieren. Der Port wird dadurch nicht auf dem Host veröffentlicht.

Kann das Proxy-Netzwerk als intern gekennzeichnet werden?

Nur wenn der Proxy und das Routing-Design weiterhin über die erforderlichen eingehenden und ausgehenden Pfade verfügen. Ein internes Netzwerk blockiert die normale externe Konnektivität für verbundene Container und kann Zertifikats- oder Identitätsabläufe beeinträchtigen.

Warum Dienstnamen statt Container-IP-Adressen verwenden?

Containeradressen können sich nach einer Neuerstellung ändern. Die Diensterkennung von Docker stellt innerhalb des gemeinsamen Netzwerks einen stabilen Namen bereit, wodurch die Proxy-Konfiguration dauerhafter wird.

Stellen Sie die gespeicherte Baseline wieder her, wenden Sie die genehmigte Konfiguration einmal an, wiederholen Sie die ursprüngliche produktionsnahe Arbeitslast, überprüfen Sie das zugesagte Erfolgssignal und führen Sie anschließend das dokumentierte Rollback durch. Schließen Sie die Änderung erst ab, wenn Protokolle, Zeitverhalten, Berechtigungen, Kapazität und die wiederhergestellte Ausgabe alle den Abnahmekriterien entsprechen.