L’IP WAN è cambiato e il tunnel è caduto: i controlli in ordine

Il tunnel cade, il router registra una riconnessione e nulla sulla LAN si è mosso. Un nuovo indirizzo WAN invalida la connessione esterna senza cambiare nulla all’interno: l’indirizzo di origine del client è cambiato, il vecchio stato NAT punta a un’origine che non esiste più e il peer remoto può ancora inviare all’indirizzo precedente. Il ripristino è un comportamento normale, e la domanda utile è quale stato non è stato aggiornato.

Nominate l’evento prima di leggere il registro

Verificate cosa è successo davvero al livello di accesso. Un rinnovo del lease da parte del provider è un evento. Una sessione PPPoE che si è riconnessa è un altro. Un modem in fibra riavviato, o un failover WAN da un collegamento a un altro, cambia l’indirizzo esterno o il suo percorso in un terzo modo. Non sono lo stesso evento e non lasciano lo stesso residuo.

Una riga di riconnessione nel registro del VPN non è nemmeno prova di un cambio di WAN. Un timeout di inattività, un intervallo di riautenticazione e il rilevamento di peer morto producono tutti riconnessioni senza alcun cambio di indirizzo. Confrontate le marche temporali del registro di accesso con il registro del VPN prima di concludere qualcosa, e mantenete la finestra di confronto abbastanza ampia da cogliere un cambiamento avvenuto durante la notte.

Il roaming e la riconnessione sono protocolli diversi

WireGuard ha il roaming autenticato integrato nel protocollo: quando un peer riceve un pacchetto autenticato correttamente da un nuovo indirizzo di origine, aggiorna l’endpoint di quel peer. L’avvio rapido di WireGuard descrive la configurazione del peer che rende possibile tutto questo, ed è per questo che un client su un indirizzo variabile spesso si riprende senza un riavvio visibile.

OpenVPN si comporta diversamente per impostazione predefinita. Una sessione UDP può terminare e riconnettersi, e il comportamento float opzionale consente a un peer autenticato di continuare da un nuovo indirizzo dove la configurazione lo permette. I tunnel basati su TCP sono più rigidi, perché la connessione stessa è legata alla coppia di indirizzi. Questa differenza decide se il ripristino sembra invisibile o si annuncia nel registro ogni volta.

Nessuno dei due comportamenti dice nulla sulle applicazioni all’interno. Un tunnel ripristinato non ripristina una sessione TCP che il peer considerava già morta.

Lo stato che il tunnel non possiede

Lo stato di traduzione e di routing sopravvive alla riconnessione in modi che sorprendono. Una voce conntrack creata per la vecchia origine mantiene il percorso di risposta ancorato a un indirizzo che non esiste più, e scade secondo il proprio calendario, non quando il tunnel è tornato. Riavviare il servizio del tunnel non accorcia quell’attesa, quindi un collegamento riparato può ancora sembrare rotto per un po’.

Le route e le regole di policy possono fare riferimento al vecchio gateway o all’interfaccia vecchia. Un insieme di regole corretto prima di un cambio di WAN può puntare a un dispositivo ora inattivo, il che produce un tunnel che si dichiara connesso e un traffico che non va da nessuna parte. Il DNS dinamico per un server che ospitate è un problema separato da quello di un client che ottiene una nuova origine. Il record deve essere aggiornato perché i client remoti vi trovino, e nessuna configurazione lato client compensa un indirizzo che la traduzione a monte non inoltrerà.

Ordinate i controlli dall’esterno verso l’interno

L’ordine sotto va dalla connessione esterna verso l’interno, e fermarsi al primo passo che fallisce è ciò che lo rende utile: ogni passaggio esclude lo strato sopra. Mantenete quell’ordine anche quando il guasto sembra ovvio.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Il primo comando mostra l’endpoint attuale e l’età della stretta di mano per ogni peer. Il secondo e il terzo mostrano se l’interfaccia esterna e la route verso l’endpoint hanno ancora senso. Il conteggio conntrack è un controllo grossolano dello stato rimasto dall’indirizzo precedente, e il journal è il punto in cui viene registrato il motivo della riconnessione.

Poi provate da un client della LAN invece che dal router. Un ping originato dal router stesso usa un percorso diverso dal traffico inoltrato, quindi un ping riuscito dal router dimostra che il tunnel esiste e nulla sulla raggiungibilità del client.

Decidete il comportamento atteso e scrivetelo

Riconnettersi è il comportamento corretto per la maggior parte delle installazioni, quindi l’obiettivo non è impedirlo. Decidete invece cosa deve succedere al traffico durante l’interruzione: fermarlo, trattenerlo o passare a un altro percorso. Questa decisione appartiene al firewall e alla politica di routing, non al profilo VPN.

Registrate insieme gli eventi di accesso e gli orari di riconnessione per una settimana. Cambiamenti ripetuti senza un evento di accesso corrispondente indicano il servizio di accesso, e sostituire il profilo VPN non sistemerà un collegamento che rinegozia continuamente. Un solo paio di voci nello stesso minuto risolve la questione per quell’incidente e dà una linea di base al successivo.