L’IP pubblico è cambiato e la VPN ha smesso di far passare traffico

Una riconnessione del fornitore o un cambiamento nella traduzione a monte altera l’origine pubblica di una sessione VPN, mentre l’indirizzo privato locale del client di solito resta esattamente com’era. Il tunnel allora sembra connesso mentre nulla di utile lo attraversa. Entrambe le osservazioni sono vere contemporaneamente, ed è questo che rende confuso il rapporto.

Percorrete i quattro controlli in ordine e fermatevi al primo che fallisce.

Quale indirizzo è cambiato davvero

Confrontate lo stato dell’interfaccia locale con l’origine che vede un endpoint remoto, in un punto in cui siete autorizzati a guardare. Un nuovo indirizzo pubblico non implica un nuovo gateway locale, e un cambiamento dell’interfaccia locale non garantisce che l’origine pubblica si sia spostata. La traduzione in mezzo significa che sono due fatti indipendenti. Annotate il percorso esatto e l’ora in cui l’avete osservato, perché un’etichetta di geolocalizzazione copiata da un vecchio rapporto risponde a un’altra domanda.

Chiedete specificamente se è cambiata l’origine esterna, l’indirizzo interno del tunnel o entrambi. Solo il primo spiega un pari che continua a inviare verso un percorso che non esiste più.

Lasciate che sia il protocollo a gestire lo spostamento

I protocolli differiscono nel modo in cui apprendono che un pari si è spostato, e la differenza conta per capire se dobbiate intervenire. WireGuard aggiorna l’endpoint di un pari quando riceve un pacchetto che si autentica con la chiave di quel pari, ed è per questo che un cambio di indirizzo può essere assorbito senza alcuna configurazione. IKEv2 dispone di MOBIKE per lo stesso scopo dove entrambe le estremità lo supportano. I progetti più vecchi si riprendono ricostruendo il tunnel.

Quello che non dovreste fare è accettare un messaggio non autenticato come prova che l’identità di un pari si è spostata. Falsificare un datagramma che dichiara un nuovo indirizzo è banale, e un client che crede di poter essere indirizzato all’endpoint dell’attaccante. Il protocollo autenticato è il meccanismo; una notifica non lo è.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Pulite il binding esterno obsoleto

Quando il protocollo supporta il roaming e il traffico continua a fallire, l’ostacolo è spesso un apparato con stato nel mezzo o una politica all’estremità remota. Un firewall che seguiva il vecchio flusso può conservare la voce obsoleta, e una regola di accesso lato server legata alla vecchia origine scarterà quella nuova in silenzio. Ripulire la mappatura e ricontrollare la regola è più rapido che sostituire le credenziali.

Mantenete il blocco necessario durante l’indagine. Aprire la politica in modo ampio per verificare se il tunnel si riprende non vi insegna nulla sulla causa e lascia l’implementazione peggiore di come l’avete trovata.

Riprovate con una richiesta nuova

Una sessione applicativa stabilita prima del cambiamento non gli sopravvive, perché la quadrupla su cui era costruita non esiste più. Generatene una nuova dopo il ripristino e confermate che si completa, invece di guardare un vecchio download fermo a zero e concludere che il tunnel è ancora rotto. Proprio questa distinzione risolve gran parte di questi rapporti.

Poi annotate entrambe le metà della diagnosi: cosa è cambiato a monte e quale passo di ripristino supportato ha ristabilito il flusso. La prossima volta sarà più rapida, e la nota è ciò che la rende più rapida.

Se una nuova richiesta riesce e la vecchia non riprende mai, il tunnel è stato riparato e l’applicazione deve solo riconnettersi.