OpenVPN o IKEv2: quattro verifiche prima di scegliere un protocollo

La scelta tra OpenVPN e IKEv2 viene di solito discussa come una questione di protocollo, e questa impostazione spreca la decisione. A decidere è se il server e i dispositivi supportano lo stesso profilo completo, e se quel profilo sopravvive al modo in cui vi spostate tra le reti. I due stack non si traducono l’uno nell’altro: un file OVPN non è un profilo IKEv2 con una sintassi diversa. Quattro verifiche, eseguite in ordine, rispondono alla domanda più in fretta di qualsiasi tabella di funzionalità.

Un client mancante chiude la discussione

Windows e macOS includono un client IKEv2, quindi un profilo IKEv2 non costa nulla in più da distribuire lì ed eredita le opzioni di provisioning che il sistema operativo già espone. OpenVPN sulle stesse macchine significa un client di terze parti da installare, aggiornare e supportare, e quel client deve accettare ogni opzione usata dal profilo. Contate le piattaforme che dovete coprire prima di confrontare qualsiasi altra cosa, perché una piattaforma senza un client funzionante non è affatto un termine di paragone.

Su Windows un solo comando elenca i profili già esistenti e mostra di che tipo è ciascuno. Il nome che stampa è il nome che usano le verifiche successive.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

La richiesta di installare un client è la vera risposta per la colonna OpenVPN su quelle piattaforme, ed è un’attività di distribuzione, non un limite del protocollo. Nessuna delle due soluzioni elimina i controlli di fiducia, la verifica dell’identità o la manutenzione. Chiedete come vengono distribuiti i profili, come vengono rinnovate le credenziali e come viene rimosso un dispositivo smarrito prima di impegnarvi. Un’installazione semplice può comunque nascondere una procedura di ripristino che nessuno vuole eseguire nel fine settimana.

La mobilità è un’impostazione congiunta, non una promessa del protocollo

IKEv2 può usare MOBIKE quando entrambe le estremità lo supportano e lo abilitano, il che consente a un client di mantenere il tunnel mentre il suo indirizzo cambia. RFC 4555 definisce l’estensione, e la formulazione condizionale conta: un server che ignora la capacità rinegozia invece. Il risultato può sembrare identico per un trasferimento di file e molto diverso per una chiamata in diretta.

Provate la transizione che vi interessa davvero, con qualcosa in esecuzione che possiate osservare. Tenete ping -t <internal-host> in esecuzione su Windows, o il semplice ping altrove, poi passate dal Wi-Fi alla rete cellulare e osservate le interruzioni. Un guasto di MOBIKE appare come una riautenticazione completa nel log del client, non come un silenzioso aggiornamento dell’indirizzo. Quello che state misurando è se il tunnel sopravvive al cambiamento, non se il protocollo dichiara il supporto.

I client OpenVPN si riconnettono secondo il comportamento della loro piattaforma e i timer del profilo, quindi lo stesso test può produrre un’interruzione di forma diversa. Confrontate l’evento che conta per i vostri utenti, non l’etichetta sul protocollo.

Le credenziali appartengono al servizio, non allo stack

I certificati e le altre modalità di accesso appartengono al servizio che termina la connessione. Una richiesta di password in un client non dice nulla sulla compatibilità con un altro, e un profilo che funziona contro un altro gateway non dice nulla su questo. Mantenete intatte le regole sull’identità del server mentre confrontate i due stack. Cambiare protocollo prima di aver identificato il guasto di solito produce un secondo profilo incompatibile.

Ispezionate la credenziale che il client presenterà prima di dare la colpa all’uno o all’altro protocollo, perché un certificato scaduto o rilasciato male fallisce allo stesso modo su entrambi. L’output qui sotto mostra soggetto, emittente e date di validità senza leggere la chiave privata.

openssl x509 -in client.crt -noout -subject -issuer -dates

Per una connessione aziendale usate il metodo che l’azienda pubblica e smettete di trattare il confronto come un esperimento. Se state confrontando i due per conto vostro, controllate prima se entrambe le opzioni terminano su un unico gateway, perché quel singolo dettaglio decide quanto del vostro risultato riguardi il protocollo. Un rifiuto che nomina la credenziale è un problema di credenziale, e nessuna quantità di cambio di protocollo lo riparerà.

Controllate cosa instrada davvero il tunnel

Dopo la connessione, confermate che la rotta necessaria esista e che i nomi si risolvano. Un profilo pensato per le risorse interne può lasciare la navigazione ordinaria sul percorso locale per scelta, e quella è una decisione di policy, non un guasto. Ciò che conta è se le destinazioni usate dal vostro team sono raggiungibili attraverso il tunnel.

Due comandi coprono la rotta e la risoluzione dei nomi su Windows. Gli equivalenti Linux sono ip route show default e resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Un tunnel che si attiva e non instrada nulla di utile è un esito comune quando un profilo è stato copiato tra servizi, e un test di connettività generico non lo mostrerà perché l’interfaccia è attiva. Provate la risorsa che i vostri utenti aprono per prima, non un indirizzo pubblico raggiungibile da qualsiasi percorso. Se il nome si risolve in un indirizzo pubblico mentre la rotta punta dentro il tunnel, la risposta DNS e la rotta appartengono a decisioni diverse e vanno corrette entrambe.

Valutate la manutenzione dopo le verifiche

Nessuno dei due protocolli è più manutenibile in astratto. La manutenzione dipende da chi gestisce il gateway, da come i profili arrivano ai dispositivi e da quanto in fretta un dispositivo smarrito perde l’accesso. Un client endpoint semplice può stare davanti a un server più difficile da gestire, e accade anche il contrario. Chiedete quale dei due il vostro team può continuare a far funzionare dopo che la persona che l’ha costruito se ne va.

Scegliete la connessione supportata che copre il lavoro, poi provatela rispetto all’accesso che vi serve davvero, non rispetto a un elenco di funzionalità. Annotate su quale gateway termina ciascuna opzione, perché due gateway diversi rendono il confronto una questione di rotte oltre che di protocolli. Ripetete le quattro verifiche sul dispositivo che porterete davvero, e tenete il profilo che lo supera.