Come riavviare un proxy inverso senza riavviare i servizi che gestiscono lo stato delle sessioni
La manutenzione pianificata del proxy è più sicura quando il reverse proxy può essere ricaricato o riavviato indipendentemente dai servizi di autenticazione e di gestione dello stato delle sessioni che si trovano dietro di esso.
Di solito un processo proxy non deve gestire direttamente lo stato di accesso che inoltra. Prima della manutenzione, identifica quale componente firma i cookie, archivia le sessioni lato server, gestisce l’autenticazione e chiude gradualmente le connessioni HTTP attive. Mantieni in esecuzione questi componenti che conservano lo stato, preferisci i ricaricamenti graduali del proxy quando cambiano solo le configurazioni e verifica che una sostituzione completa del proxy si riconnetta allo stesso gateway di autenticazione e allo stesso archivio delle sessioni, utilizzando segreti invariati.
Separa il ciclo di vita del proxy da quello del servizio di autenticazione
Controlla le dipendenze di Compose, le policy di riavvio, gli script condivisi e le azioni del gestore dello stack per assicurarti che il riavvio del proxy non ricrei automaticamente il gateway di autenticazione, l’applicazione, Redis o il database.
Un esempio di architettura delle sessioni utilizza Redis al di fuori del ciclo di vita del proxy, così più istanze di autenticazione e i relativi riavvii possono condividere lo stesso backend delle sessioni.
Non raggruppare tutti i servizi edge in un unico comando di riavvio indiscriminato. Se una modifica al certificato o al routing riguarda solo il proxy, lascia invariati i servizi che convalidano lo stato degli accessi esistenti.
Ricarica la configurazione invece di riavviare quando possibile
Per le modifiche a routing, certificati o intestazioni, utilizza il percorso di ricaricamento graduale supportato dal proxy invece di arrestare il servizio. Convalida la configurazione prima di applicarla, così un errore di sintassi non trasforma la manutenzione pianificata in un’interruzione del servizio.
La guida di API7 su NGINX spiega come i vecchi worker completino le connessioni mentre i nuovi worker accettano richieste con la configurazione aggiornata.
Un ricaricamento mantiene la stessa famiglia di processi del proxy, ma non protegge un servizio di autenticazione separato se anche quel servizio viene riavviato dallo script di distribuzione. Mantieni indipendenti queste due questioni relative al ciclo di vita.
Conserva l’archiviazione esterna delle sessioni durante la sostituzione del proxy
Se un gateway di autenticazione archivia i dati delle sessioni al di fuori dei cookie, mantieni persistente e invariato il relativo backend Redis o un altro backend delle sessioni durante l’operazione sul proxy. Registra l’indirizzo del backend e il segreto utilizzato da ogni istanza di autenticazione.
OAuth2 Proxy supporta Redis come archivio condiviso delle sessioni quando è necessario condividere le sessioni tra più istanze.
Non confondere una cache temporanea con lo stato autorevole degli accessi. Se il backend delle sessioni è necessario per convalidare gli utenti attuali, riavvialo o svuotalo solo seguendo una procedura di manutenzione testata e specifica.
Mantieni invariati i segreti dei cookie e della firma
Registra il segreto di crittografia o firma dei cookie utilizzato dal gateway di autenticazione e assicurati che lo stack proxy sostitutivo monti la stessa origine del segreto. Generare un nuovo valore durante una ridistribuzione invaliderà i cookie del browser che altrimenti sarebbero ancora validi.
Una guida alle sessioni con reverse proxy osserva che la policy stabile delle sessioni sopravvive ai riavvii, invece di dipendere dalla durata di una singola connessione TCP.
Ruota i segreti di firma come modifica di sicurezza separata, definendo esplicitamente l’eventuale disconnessione degli utenti o una strategia di sovrapposizione. Non combinare la rotazione dei segreti con un normale ricaricamento pianificato del proxy, a meno che l’invalidazione delle sessioni non sia intenzionale.
Chiudi gradualmente le connessioni durante un riavvio completo del proxy
Quando è necessario sostituire il binario o il container del proxy, utilizza, se disponibile, il relativo meccanismo di riavvio graduale o senza interruzioni, così le richieste già stabilite non vengono interrotte a metà risposta. Imposta un timeout di manutenzione per le connessioni di lunga durata.
La guida di HAProxy sul ricaricamento mostra come i ricaricamenti senza interruzioni preservino le connessioni invece di terminare immediatamente il processo precedente.
La continuità delle connessioni e quella degli accessi sono due aspetti diversi. Anche se un WebSocket si riconnette, la sessione dovrebbe rimanere valida perché il proxy sostitutivo raggiunge gli stessi servizi di autenticazione e gestione dello stato.
Verifica una sessione prima e dopo la manutenzione pianificata
Utilizza un browser con un accesso già effettuato e una sessione privata nuova. Registra il cookie di sessione, il routing del proxy, il servizio di autenticazione e il backend prima della manutenzione, quindi ricarica o sostituisci solo il proxy e ripeti la stessa richiesta protetta.
Una guida operativa su Caddy consiglia di ricaricare invece di riavviare completamente per gli aggiornamenti di configurazione pianificati.
La progettazione della manutenzione funziona quando gli accessi esistenti sopravvivono, i nuovi accessi continuano ad avere esito positivo e nessuna dipendenza che conserva lo stato ha ricevuto un riavvio imprevisto. L’articolo correlato di ZimaSpace sulla perdita delle sessioni dopo il riavvio del proxy resta il percorso di ripristino corretto se gli utenti risultano ancora disconnessi.
Domande frequenti
Un ricaricamento graduale del proxy garantisce che gli utenti rimangano connessi?
No. Protegge le connessioni del proxy, ma gli utenti possono comunque essere disconnessi se nello stesso momento cambiano il servizio di autenticazione, l’archivio delle sessioni o il segreto di firma dei cookie.
Redis deve sopravvivere sempre a un riavvio del proxy?
Solo quando Redis archivia lo stato delle sessioni o un’altra dipendenza persistente per l’autenticazione. Un’istanza Redis utilizzata esclusivamente come cache ha un diverso limite di ripristino.
Mantenere lo stesso nome del cookie è sufficiente?
No. Anche il segreto di firma o crittografia e lo stato delle sessioni nel backend devono rimanere compatibili con il cookie già presente nel browser.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
