OpenVPN eller WireGuard? Beslut ud fra identitet og transport
Nøgler, loginforløb og transport kun over UDP former valget længe før gennemstrømningen. Kør fire kontroller, og hold målingen ærlig.
Sammenligning af disse to protokoller er kun nyttig, hvis den sammenligner det, du faktisk kommer til at drive. WireGuard identificerer parter via offentlig nøgle og bærer sin protokol over UDP, mens OpenVPN tilbyder et bredere sæt godkendelsesordninger og kan køre over UDP eller TCP, når serveren tilbyder begge. De forskelle former klargøringen og fallbacken længe før de former gennemstrømningen. Kør de fire kontroller nedenfor i rækkefølge; de to første afgør som regel valget, og de to sidste fortæller, om beslutningen var rigtig.
Start med identitet, ikke med cipher-listen
En WireGuard-part gemmer én privat nøgle og oplister de offentlige nøgler, den kan nå. En udbyder kan lægge en kontoportal uden om, men protokollen selv har ingen udveksling af brugernavn og adgangskode, så kontolivscyklussen lever i det, der distribuerer nøglerne. OpenVPN kan bruge certifikater, et plugin mod en eksisterende mappe eller et verifikationsscript, og derfor foretrækker organisationer med et identitetssystem det ofte. Ingen af de to design fjerner spørgsmålet om, hvordan en mistet enhed fjernes.
| 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 |
En kort konfiguration er ikke det samme som enkel klargøring. At give én privat nøgle til flere personer gør senere fjernelse tvetydig, fordi tilbagekaldelse fjerner alle på én gang. Skriv mappingen fra person til nøgle eller certifikat ned, før du vælger, og protokolbeslutningen bliver betydeligt lettere.
Se derefter på, hvad transporten tillader
WireGuard-protokollen bruger UDP. OpenVPN-tjenester kan tilbyde både UDP- og TCP-profiler, og på et netværk, der blokerer eller forringer UDP, er den anden mulighed en praktisk fallback snarere end en teoretisk. Serveren skal understøtte den profil, du vælger, og et ændret portnummer gør ikke tunnelen til HTTPS eller overbeviser en firewall om at tillade den.
At bære TCP inde i TCP ændrer også adfærden ved tab, fordi begge lag gentager og omordner uafhængigt. En TCP-profil, der virker på et restriktivt netværk, kan stadig klare sig dårligt på et tabende netværk, og det er en grund til at holde begge profiler tilgængelige i stedet for at erklære den ene overlegen.
Kontroller derefter routing og navneopløsning
WireGuards AllowedIPs mapper adresseområder til parter og fungerer som en routingbeslutning inde i protokollen, og værktøjerne omkring bruger de områder, når de installerer ruter. OpenVPN skubber ruter og DNS-muligheder fra serveren. I begge tilfælde kan klienten komme op, mens den tilsigtede politik kun er halvt anvendt.
ip route show
ip -6 route show
resolvectl status
wg showLæs outputtet, før du stoler på tilslutningsindikatoren. ip route show oplister, hvad klienten har installeret til IPv4, og IPv6-varianten fanger en tunnel, der kun bærer én familie. resolvectl status viser, hvilken resolver klienten faktisk vil spørge, og wg show udskriver de AllowedIPs, som WireGuard mener at eje. Hvis resolveren stadig peger på det lokale netværk, mens ruterne hævder fuld dækning, forlader DNS tunnelen.
Mål derefter den opgave, du har brug for
Hold enheden, netværket og destinationen fast, og noter de klienter og endepunkter, du brugte. Hvis de to tjenester udgår i forskellige byer eller kører på forskelligt hardware, så sig det, for så beskriver resultatet de tjenester snarere end protokollerne.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20Kør begge kommandoer to gange, én gang pr. profilpar, på det samme netværk og den samme enhed. iperf3 giver et gennemstrømningstal, og mtr giver ruten og hvor tab opstår, hvilket et enkelt downloadtal ikke kan vise. Et downloadtal overser også det, en samtale bemærker: øget latenstid, jitter og hvor lang tid en genopkobling tager. Noter det separat, fordi en protokol, der vinder på gennemstrømning, stadig kan tabe på den opgave, du faktisk kører.
For en administreret forbindelse kan kompatibilitet, support og fornyelsesarbejde veje tungere end en lille benchmarkforskel. For en personlig udgang betyder operatørens logning og jurisdiktion mere end protokolmærket. Begge protokoller kan bære en god forbindelse; tjenesten og dens konfiguration afgør, hvad du får.
Skriv profilparret ned, før du tester
Vælg én profil pr. protokol, før du måler, og skriv ned, hvad hver skal gøre: kun private subnets eller al trafik med en bestemt udgang. En test, der sammenligner en split-tunnelprofil med en fuldtunnelprofil, måler profilerne, ikke protokollerne. Sæt klientnavnet, klientversionen og udgangsplaceringen i samme note.
Kør derefter den samme opgave på begge, på det samme netværk, i den samme session. Hvis en slet ikke kan oprette forbindelse, er den fejl resultatet og hører i notatet sammen med årsagen. Gem notatet sammen med tjenestens dokumentation, så den næste sammenligner det samme par i stedet for at begynde forfra.