Un account VPN su due server: tre registri di stato

Un account che può accedere a uno dei due nodi VPN solleva una questione di progettazione molto prima di sollevare una questione di software. La vista dell’account, la rete che ogni nodo possiede e la sessione che un client connesso mantiene sono tre tipi diversi di stato, e falliscono in modi diversi quando li si copia qua e là. Copiare tutti e tre in un unico sistema è un modo comune per perderne uno.

Percorrete i tre registri qui sotto in ordine. Ognuno chiede che cosa è autoritativo, che cosa è locale e che cosa accade quando l’altro nodo non c’è, e le risposte non discendono l’una dall’altra.

Chi può connettersi: una autorità, molti nodi

Iniziate dal registro di ammissione: quale fonte di identità è autoritativa, quali emittenti di certificati sono fidati, quali account sono idonei, quale secondo fattore si applica e a che cosa può arrivare ogni account. Poi annotate come ogni nodo apprende le modifiche, e con quale rapidità.

Un database condiviso è una possibile componente di quella risposta. Non è la prova che ogni politica rilevante risieda lì, né che ogni nodo applichi una modifica nello stesso istante. Un account disattivato sul nodo A ma ancora accettato sul nodo B significa che il processo di uscita non è concluso.

Decidete che cosa fa un nodo quando l’autorità non è raggiungibile. Accettare credenziali in cache durante un’interruzione è una scelta di politica con un costo di sicurezza, e rifiutarle è una scelta di politica con un costo di disponibilità. Entrambe sono difendibili; lasciarla non documentata no.

Tenete l’autorità dell’emittente separata dai dati dell’account. Più gateway possono fidarsi della stessa CA senza detenerne la chiave di firma, e ogni nodo ha comunque bisogno del proprio certificato server e della propria relazione di fiducia lato client.

Che cosa possiede un nodo: indirizzi e rotte

Il secondo registro è locale a ogni nodo: indirizzo di ascolto, identità del server, pool di indirizzi, rotte verso risorse private, politica del resolver e come il traffico esce verso internet. Lo stesso account può essere servito da uno dei due nodi mentre questi oggetti restano distinti.

Il percorso di ritorno è la parte che si dimentica. Se entrambi i nodi distribuiscono indirizzi dallo stesso pool, la rete privata non può dire a quale nodo appartenga un dato client, e la risposta può essere inviata nel posto sbagliato. Pool diversi richiedono anch’essi rotte e permessi, quindi un intervallo di numeri distinto non è una progettazione completa.

Indirizzate i client a un nodo deliberatamente. La scelta del DNS, gli elenchi di endpoint dei client e un servizio di front-end sono meccanismi diversi con comportamenti diversi di salute e di commutazione. Sceglierne uno va bene; trattare il «bilanciamento del carico» come la progettazione lascia il percorso di ritorno e il comportamento in caso di guasto non definiti.

Un esempio di prodotto documentato aiuta qui. La documentazione di replica di Pritunl tratta la rete VPN come un oggetto per replica, e i client su repliche diverse hanno bisogno di rotte e connettività aggiuntive per raggiungersi. È un assetto specifico del prodotto, non una ricetta per Community OpenVPN, ma mostra perché aggiungere una replica cambia la rete e non solo l’archivio degli account.

Che cos’è una sessione: stato vivo, non una riga

Il terzo registro è la sessione attiva. Un client connesso ha stato di protocollo e un’assegnazione di rete sul nodo che lo ha accettato. Il fatto che l’account sia noto sull’altro nodo non dà a quel nodo la sessione, le chiavi o la capacità di proseguire i pacchetti.

Siate espliciti su che cosa accade quando un nodo si guasta. Il risultato supportato può essere una riconnessione all’altro nodo con autenticazione nuova e un nuovo indirizzo, dopo di che l’applicazione si riprende a modo suo. Se è richiesto un passaggio senza interruzioni, quel requisito necessita di un supporto esplicito nell’implementazione, non di un’inferenza dalla replica del database. Scrivete la risposta dove l’ingegnere di turno può trovarla.

Le regole di capacità richiedono lo stesso trattamento. Un limite di due sessioni simultanee per account può essere applicato tra nodi solo se qualche autorità ha una vista coordinata dei posti occupati. Elenchi locali ai nodi e un registro storico dell’account non si sommano in quella vista.

Provare i tre registri

Esercitate ciascuno separatamente. Accedete tramite il nodo A, poi tramite il nodo B, e confermate che entrambi riescono con gli intervalli di indirizzi attesi. Revocate un’identità e controllate entrambi i nodi, non solo quello che avete provato per caso. Poi fermate un nodo e osservate che cosa fanno davvero il client e l’applicazione privata.

Includete il percorso di ritorno nella prova di accettazione. Un client che si connette a B ma non può ricevere risposte da una risorsa dietro A ha superato il controllo di ammissione e ha fallito quello di rete, e questa distinzione dovrebbe comparire nel rapporto.

La progettazione di un account multi-nodo è completa solo quando i tre registri hanno un proprietario esplicito, un percorso di modifica e un comportamento in caso di guasto. Copiare un file di configurazione tra nodi non risponde a nessuna di quelle domande.