OpenVPN of WireGuard? Besluit op grond van identiteit en transport
Sleutels, aanmeldvloeie en transport wat net UDP gebruik, bepaal die keuse lank voordat deurset dit doen. Voer vier kontroles uit en hou die meting eerlik.
Die vergelyking van hierdie twee protokolle is net nuttig as dit vergelyk wat jy werklik gaan bedryf. WireGuard identifiseer eweknieë aan die hand van 'n publieke sleutel en dra sy protokol oor UDP, terwyl OpenVPN 'n wyer verskeidenheid verifikasie-reëlings bied en oor UDP of TCP kan loop wanneer die bediener albei verskaf. Daardie verskille bepaal die inrigting en die terugvaloplossing lank voordat hulle die deurset bepaal. Voer die vier kontroles hieronder in volgorde uit; die eerste twee beslis gewoonlik die keuse, en die laaste twee sê of die besluit reg was.
Begin met identiteit, nie met die syferlys nie
'n WireGuard-eweknie hou een private sleutel en lys die publieke sleutels wat dit mag bereik. 'n Verskaffer kan 'n rekeningportaal daarom bou, maar die protokol self het geen gebruikersnaam-en-wagwoord-uitruiling nie, so die rekeninglewensiklus woon in wat die sleutels versprei. OpenVPN kan sertifikate, 'n inprop teen 'n bestaande gids, of 'n verifikasiesskrip gebruik, en daarom verkies organisasies met 'n identiteitstelsel dit dikwels. Nie een van die twee ontwerpe verwyder die vraag hoe 'n verlore toestel verwyder word nie.
| 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 |
'n Kort konfigurasie is nie dieselfde as eenvoudige inrigting nie. Om een private sleutel aan verskeie mense te gee, maak latere verwydering dubbelsinnig, want die intrekking daarvan verwyder almal gelyk. Skryf die kartering van persoon na sleutel of sertifikaat neer voordat jy kies, en die protokolbesluit word aansienlik makliker.
Kyk dan na wat die transport toelaat
WireGuard se protokol gebruik UDP. OpenVPN-dienste kan beide UDP- en TCP-profiele bied, en op 'n netwerk wat UDP blokkeer of degradeer is daardie tweede opsie 'n praktiese terugval eerder as 'n teoretiese een. Die bediener moet die profiel ondersteun wat jy kies, en 'n poortnommer verander maak nie die tonnel HTTPS nie en oortuig nie 'n firewall om dit toe te laat nie.
Om TCP binne TCP te dra verander ook die gedrag onder verlies, want albei lae probeer weer en herorden onafhanklik. 'n TCP-profiel wat op 'n beperkende netwerk werk, kan steeds swak presteer op 'n verliesryke een, en dit is 'n rede om albei profiele beskikbaar te hou eerder as om een as meerderwaardig te verklaar.
Kontroleer dan roetebepaling en naamoplossing
WireGuard se AllowedIPs karteer adresreekse na eweknieë en dien as 'n roetebesluit binne die protokol, en die omliggende gereedskap gebruik daardie reekse wanneer dit roetes installeer. OpenVPN stoot roetes en DNS-opsies vanaf die bediener. In albei gevalle kan die kliënt opkom terwyl die beoogde beleid net halfpad toegepas is.
ip route show
ip -6 route show
resolvectl status
wg showLees die uitset voordat jy die gekoppelde-aanwyser vertrou. ip route show lys wat die kliënt vir IPv4 geïnstalleer het, en die IPv6-variant vang 'n tonnel wat net een familie dra. resolvectl status wys watter oplosser die kliënt werklik sal navraag doen, en wg show druk die AllowedIPs wat WireGuard meen dit besit. As die oplosser steeds na die plaaslike netwerk wys terwyl die roetes volle dekking beweer, verlaat DNS buite die tonnel.
Meet dan die taak waaroor jy omgee
Hou die toestel, die netwerk en die bestemming bestendig, en teken die kliënte en eindpunte aan wat jy gebruik het. As die twee dienste in verskillende stede uitgaan of op verskillende hardeware loop, sê so, want die resultaat beskryf dan daardie dienste eerder as die protokolle.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20Voer albei opdragte twee keer uit, een keer per profielpaar, op dieselfde netwerk en toestel. iperf3 gee 'n deursetsyfer, en mtr gee die pad en waar verlies voorkom, wat 'n enkele aflaaisyfer nie kan wys nie. 'n Aflaaisyfer mis ook wat 'n oproep opmerk: bykomende latensie, jitter en hoe lank 'n herverbinding neem. Teken dit afsonderlik aan, want 'n protokol wat op deurset wen, kan steeds verloor op die taak wat jy werklik uitvoer.
Vir 'n bestuurde verbinding kan versoenbaarheid, ondersteuning en hernuwingswerk 'n klein maatstafverskil oortref. Vir 'n persoonlike uitgang maak die operateur se logboeke en jurisdiksie meer saak as die protokoletiket. Albei protokolle kan 'n goeie verbinding dra; die diens en sy konfigurasie bepaal wat jy kry.
Skryf die profielpaar neer voordat jy toets
Kies een profiel per protokol voordat jy meet, en skryf neer wat elkeen veronderstel is om te doen: net private subnetwerke, of alle verkeer met 'n spesifieke uitgang. 'n Toets wat 'n split-tonnelprofiel met 'n voltonnelprofiel vergelyk, meet die profiele, nie die protokolle nie. Sit die kliënt se naam, die kliëntweergawe en die uitgangslokasie in dieselfde nota.
Voer dan dieselfde taak op albei uit, op dieselfde netwerk, in dieselfde sessie. As een glad nie kan koppel nie, is daardie mislukking die resultaat en hoort dit saam met die rede in die rekord. Hou die rekord by die diensdokumentasie sodat die volgende persoon dieselfde paar vergelyk eerder as om oor te begin.