OpenVPN o WireGuard? Decidiu a partir de la identitat i el transport
Les claus, els fluxos d'inici de sessió i el transport només per UDP condicionen l'elecció molt abans que el cabal. Feu quatre comprovacions i manteniu la mesura honesta.
Comparar aquests dos protocols només és útil si compara allò que realment operareu. WireGuard identifica els parells per clau pública i transporta el seu protocol per UDP, mentre que OpenVPN ofereix un conjunt més ampli de formes d'autenticació i pot funcionar per UDP o TCP quan el servidor proporciona tots dos. Aquestes diferències configuren l'aprovisionament i la via alternativa molt abans de configurar el cabal. Feu les quatre comprovacions següents en ordre; les dues primeres solen decidir l'elecció, i les dues últimes diuen si la decisió era correcta.
Comenceu per la identitat, no per la llista de xifratges
Un parell de WireGuard desa una clau privada i llista les claus públiques a què pot arribar. Un proveïdor pot embolcallar-ho amb un portal de compte, però el protocol mateix no té intercanvi d'usuari i contrasenya, així que el cicle de vida del compte viu en allò que distribueix les claus. OpenVPN pot fer servir certificats, un connector contra un directori existent o un script de verificació, i per això les organitzacions amb un sistema d'identitat sovint el prefereixen. Cap dels dos dissenys elimina la pregunta de com es retira un dispositiu perdut.
| Decision | OpenVPN | WireGuard |
|---|---|---|
| Identity | Certificates, plugins or scripts against an existing directory | One private key per peer, public keys listed for the peers it may reach |
| Transport | UDP or TCP profiles when the server offers both | UDP only in the native protocol |
| Routing and DNS | Server pushes routes and DNS options | AllowedIPs maps ranges to peers, and tooling installs the routes |
| Where it usually breaks | Profile mismatch, expired certificate, failing plugin | Blocked UDP, wrong AllowedIPs, key not installed |
Una configuració curta no és el mateix que un aprovisionament simple. Donar una clau privada a diverses persones fa ambigua la retirada posterior, perquè revocar-la les retira totes alhora. Escriviu la correspondència de persona a clau o certificat abans de triar, i la decisió sobre el protocol es fa molt més fàcil.
Després mireu què permet el transport
El protocol de WireGuard fa servir UDP. Els serveis OpenVPN poden oferir perfils UDP i TCP, i en una xarxa que bloqueja o degrada l'UDP aquesta segona opció és una via alternativa pràctica i no pas teòrica. El servidor ha de suportar el perfil que trieu, i canviar el número de port no converteix el túnel en HTTPS ni convenç un tallafoc perquè el permeti.
Transportar TCP dins de TCP també canvia el comportament amb pèrdues, perquè totes dues capes reintenten i reordenen de manera independent. Un perfil TCP que funciona en una xarxa restrictiva pot anar malament en una xarxa amb pèrdues, i és un motiu per mantenir tots dos perfils disponibles en lloc de declarar un de superior.
Després comproveu l'encaminament i la resolució de noms
AllowedIPs de WireGuard assigna rangs d'adreces als parells i actua com una decisió d'encaminament dins del protocol, i les eines del voltant fan servir aquests rangs quan instal·len rutes. OpenVPN envia rutes i opcions de DNS des del servidor. En tots dos casos el client pot aixecar-se mentre la política prevista només s'aplica a mitges.
ip route show
ip -6 route show
resolvectl status
wg showLlegiu la sortida abans de confiar en l'indicador de connectat. ip route show llista què ha instal·lat el client per a IPv4, i la variant IPv6 detecta un túnel que només porta una família. resolvectl status mostra quin resoledor consultarà realment el client, i wg show imprimeix les AllowedIPs que WireGuard creu que posseeix. Si el resoledor encara apunta a la xarxa local mentre les rutes afirmen una cobertura total, el DNS surt fora del túnel.
Després mesureu la tasca que us importa
Mantingueu el dispositiu, la xarxa i la destinació sense canvis, i anoteu els clients i els punts finals que heu fet servir. Si els dos serveis surten en ciutats diferents o funcionen en maquinari diferent, digueu-ho, perquè llavors el resultat descriu aquests serveis i no els protocols.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20Executeu les dues ordres dues vegades, una per cada parell de perfils, a la mateixa xarxa i al mateix dispositiu. iperf3 dona una xifra de cabal, i mtr dona el camí i on apareixen les pèrdues, cosa que una sola xifra de descàrrega no pot mostrar. Una xifra de descàrrega també passa per alt el que nota una trucada: latència afegida, fluctuació i quant triga una reconnexió. Anoteu-ho per separat, perquè un protocol que guanya en cabal encara pot perdre en la tasca que realment executeu.
Per a una connexió gestionada, la compatibilitat, el suport i l'esforç de renovació poden superar una petita diferència de referència. Per a una sortida personal, el registre i la jurisdicció de l'operador importen més que l'etiqueta del protocol. Tots dos protocols poden portar una bona connexió; el servei i la seva configuració decideixen què obteniu.
Anoteu el parell de perfils abans de provar
Trieu un perfil per protocol abans de mesurar i anoteu què ha de fer cadascun: només subxarxes privades, o tot el trànsit amb una sortida concreta. Una prova que compara un perfil de túnel dividit amb un de túnel complet mesura els perfils, no els protocols. Poseu el nom del client, la versió del client i la ubicació de sortida a la mateixa nota.
Després executeu la mateixa tasca en tots dos, a la mateixa xarxa, a la mateixa sessió. Si un no aconsegueix connectar-se gens, aquesta fallada és el resultat i pertany al registre amb el motiu. Guardeu el registre amb la documentació del servei perquè la propera persona compari el mateix parell en lloc de començar de nou.