So starten Sie einen Reverse-Proxy neu, ohne sitzungsstatusbehaftete Dienste neu zu starten

Geplante Wartungsarbeiten am Proxy sind sicherer, wenn der Reverse-Proxy unabhängig von den dahinterliegenden Authentifizierungs- und Sitzungsstatusdiensten neu geladen oder neu gestartet werden kann.

Ein Proxy-Prozess muss normalerweise nicht den Anmeldestatus besitzen, den er weiterleitet. Ermitteln Sie vor der Wartung, welche Komponente Cookies signiert, serverseitige Sitzungen speichert, die Authentifizierung beendet und aktive HTTP-Verbindungen auslaufen lässt. Lassen Sie diese zustandsbehafteten Komponenten weiterlaufen, bevorzugen Sie bei reinen Konfigurationsänderungen ein schonendes Neuladen des Proxys und überprüfen Sie, dass ein vollständiger Austausch des Proxys wieder mit demselben Authentifizierungs-Gateway und Sitzungsspeicher sowie unveränderten Geheimnissen verbunden wird.

Proxy-Lebenszyklus vom Lebenszyklus des Authentifizierungsdienstes trennen

Prüfen Sie Ihre Compose-Abhängigkeiten, Neustartrichtlinien, gemeinsam genutzten Skripte und Aktionen des Stack-Managers, um sicherzustellen, dass ein Neustart des Proxys nicht automatisch das Authentifizierungs-Gateway, die Anwendung, Redis oder die Datenbank neu erstellt.

Ein Beispiel für eine Sitzungsarchitektur verwendet Redis außerhalb des Proxy-Lebenszyklus, sodass mehrere Authentifizierungsinstanzen und Neustarts dasselbe Sitzungs-Backend nutzen können.

Gruppieren Sie nicht jeden Edge-Dienst unter einem pauschalen Neustartbefehl. Wenn eine Zertifikats- oder Routenänderung nur den Proxy betrifft, lassen Sie die Dienste, die den bestehenden Anmeldestatus validieren, unangetastet.

Konfiguration nach Möglichkeit neu laden statt neu starten

Verwenden Sie bei Änderungen an Routen, Zertifikaten oder Headern den vom Proxy unterstützten schonenden Neuladevorgang, anstatt den Dienst zu stoppen. Validieren Sie die Konfiguration vor der Anwendung, damit ein Syntaxfehler die geplante Wartung nicht in einen Ausfall verwandelt.

Die NGINX-Anleitung von API7 erklärt, wie alte Worker Verbindungen auslaufen lassen, während neue Worker Anfragen mit der aktualisierten Konfiguration annehmen.

Ein Neuladen bewahrt die Prozessfamilie des Proxys, schützt jedoch keinen separaten Authentifizierungsdienst, wenn Ihr Bereitstellungsskript diesen ebenfalls neu startet. Behandeln Sie diese beiden Fragen zum Lebenszyklus unabhängig voneinander.

Externen Sitzungsspeicher beim Austausch des Proxys beibehalten

Wenn ein Authentifizierungs-Gateway Sitzungsdaten außerhalb von Cookies speichert, muss sein Redis- oder anderes Sitzungs-Backend während des Proxy-Vorgangs persistent und unverändert bleiben. Dokumentieren Sie die Backend-Adresse und das von jeder Authentifizierungsinstanz verwendete Geheimnis.

OAuth2 Proxy unterstützt Redis als gemeinsamen Sitzungsspeicher, wenn Sitzungen zwischen Instanzen geteilt werden müssen.

Verwechseln Sie einen kurzlebigen Cache nicht mit dem maßgeblichen Anmeldestatus. Wenn das Sitzungs-Backend zur Validierung aktueller Benutzer erforderlich ist, starten Sie es nur im Rahmen eines eigenen getesteten Wartungsverfahrens neu oder leeren Sie es entsprechend.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Cookie- und Signiergeheimnisse stabil halten

Dokumentieren Sie das vom Authentifizierungs-Gateway verwendete Cookie-Verschlüsselungs- oder Signiergeheimnis und stellen Sie sicher, dass der Ersatz-Stack des Proxys dieselbe Geheimnisquelle einbindet. Wird bei der erneuten Bereitstellung ein neuer Wert erzeugt, werden ansonsten intakte Browser-Cookies ungültig.

Ein Leitfaden zu Reverse-Proxy-Sitzungen weist darauf hin, dass eine stabile Sitzungspolitik Neustarts übersteht und nicht von der Lebensdauer einer einzelnen TCP-Verbindung abhängt.

Rotieren Sie Signiergeheimnisse als separate Sicherheitsänderung mit einer ausdrücklich erwarteten Abmeldung oder einer Strategie mit überlappender Gültigkeit. Kombinieren Sie die Rotation von Geheimnissen nicht mit einem gewöhnlichen geplanten Neuladen des Proxys, es sei denn, die Sitzungsinvalidierung ist beabsichtigt.

Verbindungen während eines vollständigen Proxy-Neustarts auslaufen lassen

Wenn die Proxy-Binärdatei oder der Container ersetzt werden muss, verwenden Sie, sofern verfügbar, den schonenden oder unterbrechungsfreien Neustartmechanismus, damit bestehende Anfragen nicht mitten in der Antwort abgebrochen werden. Legen Sie für langlebige Verbindungen ein Wartungs-Timeout fest.

Die Anleitung zum Neuladen von HAProxy zeigt, wie unterbrechungsfreie Neuladevorgänge Verbindungen erhalten, anstatt den alten Prozess sofort zu beenden.

Verbindungskontinuität und Anmeldekontinuität sind nicht dasselbe. Selbst wenn eine WebSocket-Verbindung wiederhergestellt wird, sollte die Sitzung gültig bleiben, weil der Ersatz-Proxy dieselben Authentifizierungs- und Statusdienste erreicht.

Eine Sitzung vor und nach der geplanten Wartung testen

Verwenden Sie einen angemeldeten Browser und eine neue private Sitzung. Erfassen Sie vor der Wartung das Sitzungscookie, die Proxy-Route, den Authentifizierungsdienst und das Backend. Laden Sie anschließend nur den Proxy neu oder ersetzen Sie ihn und wiederholen Sie dieselbe geschützte Anfrage.

Ein Caddy-Betriebsleitfaden empfiehlt bei geplanten Konfigurationsaktualisierungen Neuladen statt vollständigem Neustart.

Das Wartungskonzept funktioniert, wenn bestehende Anmeldungen erhalten bleiben, neue Anmeldungen weiterhin erfolgreich sind und keine zustandsbehaftete Abhängigkeit unbeabsichtigt neu gestartet wurde. Der zugehörige ZimaSpace-Artikel über Sitzungsverlust nach einem Proxy-Neustart bleibt der richtige Wiederherstellungspfad, wenn Benutzer weiterhin abgemeldet sind.

Häufig gestellte Fragen

Garantiert ein schonendes Neuladen des Proxys, dass Benutzer angemeldet bleiben?

Nein. Es schützt Proxy-Verbindungen, aber Benutzer können trotzdem abgemeldet werden, wenn der Authentifizierungsdienst, der Sitzungsspeicher oder das Cookie-Signiergeheimnis gleichzeitig geändert wird.

Sollte Redis einen Proxy-Neustart immer überstehen?

Nur wenn Redis Sitzungsstatus oder eine andere persistente Abhängigkeit für die Authentifizierung speichert. Eine Redis-Instanz, die ausschließlich als Cache dient, hat eine andere Wiederherstellungsgrenze.

Reicht es aus, denselben Cookie-Namen beizubehalten?

Nein. Auch das Signier- oder Verschlüsselungsgeheimnis und der Backend-Sitzungsstatus müssen mit dem bereits im Browser gespeicherten Cookie kompatibel bleiben.