OpenVPN eller WireGuard? Bestem ut fra identitet og transport
Nøkler, innloggingsflyter og transport bare over UDP former valget lenge før gjennomstrømningen. Gjør fire kontroller og hold målingen ærlig.
Å sammenligne disse to protokollene er bare nyttig hvis sammenligningen gjelder det du faktisk skal drifte. WireGuard identifiserer parter med offentlig nøkkel og bærer protokollen sin over UDP, mens OpenVPN tilbyr et bredere sett autentiseringsordninger og kan kjøre over UDP eller TCP når serveren tilbyr begge. Forskjellene former klargjøringen og reserveveien lenge før de former gjennomstrømningen. Gjør de fire kontrollene nedenfor i rekkefølge; de to første avgjør vanligvis valget, og de to siste sier om beslutningen var riktig.
Start med identitet, ikke med chifferlisten
En WireGuard-part lagrer én privat nøkkel og lister opp de offentlige nøklene den kan nå. En leverandør kan legge en kontoportal rundt det, men protokollen selv har ingen utveksling av brukernavn og passord, så kontolivssyklusen lever i det som distribuerer nøklene. OpenVPN kan bruke sertifikater, en plugin mot en eksisterende katalog eller et verifikasjonsskript, og derfor foretrekker organisasjoner med et identitetssystem det ofte. Ingen av de to designene fjerner spørsmålet om hvordan en mistet enhet 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 konfigurasjon er ikke det samme som enkel klargjøring. Å gi én privat nøkkel til flere personer gjør senere fjerning tvetydig, fordi tilbakekalling fjerner alle på én gang. Skriv ned koblingen fra person til nøkkel eller sertifikat før du velger, og protokollbeslutningen blir betydelig enklere.
Se deretter på hva transporten tillater
WireGuard-protokollen bruker UDP. OpenVPN-tjenester kan tilby både UDP- og TCP-profiler, og på et nettverk som blokkerer eller forringer UDP er det andre alternativet en praktisk reservevei og ikke en teoretisk. Serveren må støtte profilen du velger, og et endret portnummer gjør ikke tunnelen til HTTPS eller overbeviser en brannmur om å tillate den.
Å bære TCP inne i TCP endrer også oppførselen ved tap, fordi begge lagene prøver på nytt og omordner uavhengig. En TCP-profil som virker på et restriktivt nettverk kan fortsatt gjøre det dårlig på et tapende nettverk, og det er grunn til å holde begge profilene tilgjengelige i stedet for å erklære den ene overlegen.
Kontroller deretter ruting og navneoppslag
WireGuards AllowedIPs kobler adresseområder til parter og virker som en rutingsbeslutning inne i protokollen, og verktøyene rundt bruker disse områdene når de installerer ruter. OpenVPN skyver ruter og DNS-alternativer fra serveren. I begge tilfeller kan klienten komme opp mens den tiltenkte policyen bare er halvveis anvendt.
ip route show
ip -6 route show
resolvectl status
wg show
Les utdataene før du stoler på tilkoblingsindikatoren. ip route show lister opp hva klienten installerte for IPv4, og IPv6-varianten fanger en tunnel som bare bærer én familie. resolvectl status viser hvilken resolver klienten faktisk vil spørre, og wg show skriver ut AllowedIPs som WireGuard mener den eier. Hvis resolveren fortsatt peker på det lokale nettverket mens rutene hevder full dekning, forlater DNS tunnelen.
Mål deretter oppgaven du bryr deg om
Hold enheten, nettverket og målet fast, og noter klientene og endepunktene du brukte. Hvis de to tjenestene går ut i forskjellige byer eller kjører på forskjellig maskinvare, si det, fordi resultatet da beskriver tjenestene og ikke protokollene.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20
Kjør begge kommandoene to ganger, én gang per profilpar, på samme nettverk og enhet. iperf3 gir et gjennomstrømningstall, og mtr gir ruten og hvor tap oppstår, noe et enkelt nedlastingstall ikke kan vise. Et nedlastingstall overser også det en samtale merker: økt latens, jitter og hvor lang tid en gjenoppkobling tar. Noter det separat, fordi en protokoll som vinner på gjennomstrømning fortsatt kan tape på oppgaven du faktisk kjører.
For en administrert tilkobling kan kompatibilitet, støtte og fornyelsesarbeid veie tyngre enn en liten benchmarkforskjell. For en personlig utgang betyr leverandørens logging og jurisdiksjon mer enn protokolletiketten. Begge protokollene kan bære en god tilkobling; tjenesten og konfigurasjonen avgjør hva du får.
Skriv ned profilparet før du tester
Velg én profil per protokoll før du måler, og skriv ned hva hver skal gjøre: bare private subnett eller all trafikk med en bestemt utgang. En test som sammenligner en splitt-tunnelprofil med en fulltunnelprofil, måler profilene og ikke protokollene. Sett klientnavnet, klientversjonen og utgangsplasseringen i samme notat.
Kjør deretter samme oppgave på begge, på samme nettverk, i samme økt. Hvis én ikke får tilkobling i det hele tatt, er den feilen resultatet og hører hjemme i notatet sammen med årsaken. Oppbevar notatet sammen med tjenestedokumentasjonen, så neste person sammenligner samme par i stedet for å begynne på nytt.