Come MOBIKE mantiene vivo un VPN IKEv2 quando cambia la rete

Un telefono lascia il Wi-Fi e si unisce alla rete cellulare, un portatile passa da Ethernet a un hotspot, e il tunnel IKEv2 sopravvive oppure no. MOBIKE è l'estensione che gli permette di sopravvivere, dicendo all'estremità remota che l'indirizzo di origine è cambiato invece di ricominciare da capo. Quello che non fa è mantenere viva ogni applicazione durante il cambiamento. Sono due affermazioni, e la seconda è quella che le persone di solito intendono.

Percorri la transizione per fasi, perché ogni fase fallisce in modo diverso.

Cosa cambia davvero l'aggiornamento

Finché l'associazione di sicurezza è ancora valida, l'iniziatore apprende il suo nuovo indirizzo e invia un aggiornamento al risponditore, che poi usa quell'indirizzo per la stessa associazione. I parametri di sicurezza non vengono rinegoziati da zero. Questo è l'intero vantaggio: nessun nuovo ciclo di autenticazione, nessun nuovo scambio di chiavi, nessuna richiesta all'utente. Significa anche che lo stato sopravvissuto appartiene ancora alla vecchia sessione.

MOBIKE può anche spostare il traffico sull'incapsulamento UDP, ed è per questo che un tunnel funzionante a volte inizia a usare la porta 4500 dopo un cambio di rete. Quella transizione da sola non dimostra che NAT sia stato rilevato, anche se i due spesso compaiono insieme.

Il tuo profilo lo abilita davvero

Entrambi i peer devono supportare l'estensione, e la distribuzione deve abilitarla. In strongSwan il comportamento è configurabile per connessione, e i cambi di interfaccia o di rotta possono attivare una ricerca del percorso e un aggiornamento quando serve. Ispeziona le impostazioni effettive della connessione invece di presumere che ogni profilo IKEv2 la attivi. Un profilo copiato da una guida precedente alla funzionalità è una fonte comune di questo.

Lo stato negoziato su entrambi i lati è l'autorità, non la documentazione della famiglia di prodotti.

Percorri la transizione per fasi

Registra lo stato dell'applicazione prima di cambiare rete. Poi cambia, e registra in seguito lo stato del client e del server. Un indirizzo mancante, un peer irraggiungibile e un'applicazione che deve riconnettere la propria sessione sono tre esiti diversi. Solo i primi due appartengono al livello VPN; il terzo appartiene al protocollo che parla l'applicazione.

Confronta un cambio di rete con un test stazionario, per sapere quale evento scatena il problema. Una misura di throughput sulla rete finale non può riprodurre una transizione. Misura la destinazione, non il viaggio.

Separa i livelli di guasto

Una sessione TCP di lunga durata può fallire per motivi esterni allo scambio IKEv2. La nuova rete può filtrare, risolvere o instradare in modo diverso. L'indirizzo del tunnel può non cambiare affatto mentre il percorso sottostante cambia. Ecco perché una riconnessione dell'applicazione può riparare qualcosa che il VPN non ha mai rotto.

Mantieni in vigore anche la politica di blocco durante il ripristino.

La mobilità automatica e una regola che impedisce il traffico diretto sono controlli diversi, e disattivare la seconda per far funzionare la prima è un cattivo scambio. Se l'aggiornamento di mobilità fallisce, il blocco dovrebbe tenere invece di far trapelare traffico attorno al tunnel.

Cosa registrare quando si ripete

Conserva i timestamp ed entrambi i valori di indirizzo da entrambi i lati. Quel registro mostra se l'aggiornamento si è completato prima che l'applicazione perdesse il contatto, che è la differenza tra un difetto di mobilità e un timeout dell'applicazione. Poi confronta la direzione del cambio: uscire dal Wi-Fi verso la rete cellulare non è simmetrico con il contrario. Una direzione può funzionare mentre l'altra fallisce.

Quell'asimmetria è abbastanza comune da essere la prima cosa da provare.

Con il registro in mano, l'incidente smette di essere un'altra icona disconnessa e diventa un evento in una sequenza con un proprietario noto. Che è tutto ciò che un percorso può onestamente promettere.