OpenVPN o WireGuard? Decidere da identità e trasporto

Confrontare questi due protocolli è utile solo se confronta ciò che gestirete davvero. WireGuard identifica i peer tramite chiave pubblica e trasporta il suo protocollo su UDP, mentre OpenVPN offre un insieme più ampio di modalità di autenticazione e può funzionare su UDP o TCP quando il server fornisce entrambi. Queste differenze plasmano il provisioning e la via di riserva molto prima di plasmare la velocità effettiva. Eseguite i quattro controlli seguenti in ordine; i primi due di solito decidono la scelta, e gli ultimi due dicono se la decisione era giusta.

Iniziate dall'identità, non dall'elenco dei cifrari

Un peer WireGuard conserva una chiave privata ed elenca le chiavi pubbliche che può raggiungere. Un fornitore può avvolgerlo in un portale dell'account, ma il protocollo stesso non ha scambio di nome utente e password, quindi il ciclo di vita dell'account vive in ciò che distribuisce le chiavi. OpenVPN può usare certificati, un plugin contro una directory esistente o uno script di verifica, ed è per questo che le organizzazioni con un sistema di identità lo preferiscono spesso. Nessuno dei due progetti elimina la domanda su come si rimuove un dispositivo smarrito.

Una configurazione breve non equivale a un provisioning semplice. Consegnare una chiave privata a più persone rende ambigua la rimozione successiva, perché revocarla le rimuove tutte insieme. Scrivete la corrispondenza tra persona e chiave o certificato prima di scegliere, e la decisione sul protocollo diventa molto più facile.

Poi guardate cosa consente il trasporto

Il protocollo di WireGuard usa UDP. I servizi OpenVPN possono offrire profili UDP e TCP, e su una rete che blocca o degrada UDP quella seconda opzione è una via di riserva pratica e non teorica. Il server deve supportare il profilo che scegliete, e cambiare il numero di porta non trasforma il tunnel in HTTPS né convince un firewall a consentirlo.

Trasportare TCP dentro TCP cambia anche il comportamento in caso di perdita, perché entrambi gli strati ritentano e riordinano in modo indipendente. Un profilo TCP che funziona su una rete restrittiva può comunque comportarsi male su una rete con perdite, ed è un motivo per tenere disponibili entrambi i profili invece di dichiararne uno superiore.

Poi verificate instradamento e risoluzione dei nomi

AllowedIPs di WireGuard mappa intervalli di indirizzi sui peer e agisce come decisione di instradamento dentro il protocollo, e gli strumenti circostanti usano quegli intervalli quando installano le rotte. OpenVPN spinge rotte e opzioni DNS dal server. In entrambi i casi il client può salire mentre la policy prevista è applicata solo a metà.

ip route show
ip -6 route show
resolvectl status
wg show

Leggete l'output prima di fidarvi dell'indicatore di connessione. ip route show elenca ciò che il client ha installato per IPv4, e la variante IPv6 intercetta un tunnel che trasporta una sola famiglia. resolvectl status mostra quale resolver il client interrogherà davvero, e wg show stampa le AllowedIPs che WireGuard ritiene di possedere. Se il resolver punta ancora alla rete locale mentre le rotte rivendicano copertura completa, il DNS esce dal tunnel.

Poi misurate il compito che vi interessa

Tenete fermi dispositivo, rete e destinazione, e annotate i client e gli endpoint che avete usato. Se i due servizi escono in città diverse o girano su hardware diverso, ditelo, perché allora il risultato descrive quei servizi e non i protocolli.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

Eseguite entrambi i comandi due volte, una per ogni coppia di profili, sulla stessa rete e sullo stesso dispositivo. iperf3 dà una cifra di velocità effettiva, e mtr dà il percorso e dove compaiono le perdite, cosa che una singola cifra di download non può mostrare. Una cifra di download trascura anche ciò che una chiamata nota: latenza aggiunta, jitter e quanto dura una riconnessione. Annotatele separatamente, perché un protocollo che vince sulla velocità effettiva può perdere sul compito che eseguite davvero.

Per una connessione gestita, compatibilità, supporto e sforzo di rinnovo possono pesare più di una piccola differenza nel benchmark. Per un'uscita personale, la registrazione e la giurisdizione dell'operatore contano più dell'etichetta del protocollo. Entrambi i protocolli possono trasportare una buona connessione; il servizio e la sua configurazione decidono cosa ottenete.

Scrivete la coppia di profili prima di testare

Scegliete un profilo per protocollo prima di misurare e scrivete cosa dovrebbe fare ciascuno: solo sottoreti private, o tutto il traffico con un'uscita specifica. Un test che confronta un profilo a tunnel diviso con uno a tunnel completo misura i profili, non i protocolli. Mettete il nome del client, la versione del client e la posizione dell'uscita nella stessa nota.

Poi eseguite lo stesso compito su entrambi, sulla stessa rete, nella stessa sessione. Se uno non riesce affatto a connettersi, quel fallimento è il risultato e appartiene al resoconto insieme al motivo. Conservate il resoconto con la documentazione del servizio, così la persona successiva confronta la stessa coppia invece di ricominciare.