Perché una riconnessione VPN chiede di nuovo le credenziali

Un tunnel che ha funzionato per ore chiede una password nel momento in cui il portatile si sveglia, e nulla nella configurazione è cambiato. Ciò che è cambiato è lo stato della credenziale che la riconnessione ha tentato di riutilizzare. Tre tipi di materiale lo governano, e solo uno di essi sopravvive a un intervallo arbitrario.

Leggi quale ha richiesto il client, perché i tre scadono con orologi diversi e falliscono con messaggi diversi.

Tre tipi di materiale riutilizzabile

Una password nella cache è un segreto detenuto dal client, e resta valida finché l'account non la cambia. Un token di sessione è emesso dal server dopo un accesso riuscito, porta con sé la propria durata e può essere revocato in qualsiasi momento. Un biglietto di sessione TLS o un'associazione di sicurezza IKE è stato di protocollo, economico da riprendere e completamente indipendente dalla tua password. Ognuno è emesso da un componente diverso, e ognuno scade alle proprie condizioni.

Il primo sopravvive a un riavvio, il secondo di solito sopravvive a una sospensione, e il terzo potrebbe non sopravvivere affatto a un cambio di rete. Confonderli produce la correzione sbagliata, come reimpostare una password che non è mai stata rifiutata.

La richiesta stessa è la diagnosi. Una finestra del browser o un codice di secondo fattore significa che il server ha richiesto un'autenticazione interattiva, mentre un fallimento silenzioso senza richiesta significa che il client non è mai arrivato abbastanza lontano da essere interrogato.

Rinnovare le chiavi non è riautenticare

Un rinnovo delle chiavi sostituisce le chiavi mantenendo l'identità autenticata, ed è per questo che avviene silenziosamente di tanto in tanto su un tunnel sano. La riautenticazione ripete il controllo d'identità stesso, ed è l'evento che ha bisogno di te. IKEv2 separa esplicitamente i due, e un peer può richiedere una riautenticazione completa a un intervallo configurato, indipendentemente da quanti rinnovi di chiavi siano avvenuti nel frattempo. I due eventi sembrano identici dall'esterno finché non leggi quale nomina il registro.

OpenVPN si comporta allo stesso modo nel proprio vocabolario: un intervallo di rinegoziazione aggiorna il canale dati, e un token di autenticazione può essere restituito al client per evitare un accesso completo alla connessione successiva. Quel token ha una durata, e il server decide se accettarlo di nuovo.

Così una riconnessione dopo otto ore può fallire dove una riconnessione dopo otto minuti era riuscita, senza alcun cambio di configurazione da nessuna delle due parti. È tutta la spiegazione di una richiesta che appare solo dopo pranzo.

Quando il client non riesce a completare la nuova sfida

Una politica che richiede un passaggio nel browser fallirà su un client che non ha modo di mostrarne uno. Server senza interfaccia, script di avvio e profili vecchi creati per l'autenticazione solo con password urtano tutti contro quel muro, e il fallimento spesso appare come un timeout generico anziché come un errore di autenticazione.

Anche le transizioni di dispositivo e rete possono cadere dentro una finestra di valutazione della politica, così un roaming da Wi-Fi a hotspot coincide con un controllo che sarebbe avvenuto comunque. La coincidenza fa sembrare colpevole la rete quando la causa è il timer.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

La prima riga mostra gli eventi di rinegoziazione e autenticazione nel registro del client, e la seconda mostra le associazioni di sicurezza che un peer strongSwan detiene ora. Confronta le marche temporali con il momento in cui è apparsa la richiesta; una corrispondenza conferma il timer e non la rete.

Cosa segnalare e cosa non disattivare

Se un accesso manuale riesce e il riutilizzo automatico fallisce costantemente, dillo esattamente all'operatore. Nomina il componente: il percorso di riutilizzo, non la credenziale. Includi l'ora del fallimento, l'account in uso e il tipo di richiesta che hai visto.

Non disattivare il secondo fattore, non saltare la validazione del certificato e non incollare le credenziali in uno script per rendere silenziosa la riconnessione. Ognuna di queste cose rimuove il controllo che la politica esiste per imporre, e ognuna trasforma una richiesta di accesso in un incidente.

Chiedi invece il flusso supportato: un client in grado di completare la sfida, una durata del token adatta alla giornata lavorativa, o un profilo non interattivo approvato per la macchina che non può chiedere. Sono tutte decisioni di configurazione che qualcuno può approvare, cosa che un aggiramento non è.