OpenVPN eller WireGuard? Avgör utifrån identitet och transport
Nycklar, inloggningsflöden och transport enbart över UDP formar valet långt före genomströmningen. Gör fyra kontroller och håll mätningen ärlig.
Att jämföra dessa två protokoll är bara användbart om det jämför det du faktiskt kommer att driva. WireGuard identifierar parter med en publik nyckel och bär sitt protokoll över UDP, medan OpenVPN erbjuder en bredare uppsättning autentiseringsmetoder och kan köras över UDP eller TCP när servern erbjuder båda. De skillnaderna formar etableringen och reservvägen långt innan de formar genomströmningen. Gör de fyra kontrollerna nedan i ordning; de två första avgör oftast valet, och de två sista säger om beslutet var rätt.
Börja med identitet, inte med chifferlistan
En WireGuard-part lagrar en privat nyckel och listar de publika nycklar den kan nå. En leverantör kan lägga en kontoportal runt det, men protokollet i sig har ingen utväxling av användarnamn och lösenord, så kontots livscykel lever i det som distribuerar nycklarna. OpenVPN kan använda certifikat, ett plugin mot en befintlig katalog eller ett verifieringsskript, och därför föredrar organisationer med ett identitetssystem det ofta. Ingen av de två konstruktionerna tar bort frågan om hur en förlorad enhet tas bort.
| 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 är inte samma sak som enkel etablering. Att ge en privat nyckel till flera personer gör senare borttagning tvetydig, eftersom återkallning tar bort alla på en gång. Skriv ned mappningen från person till nyckel eller certifikat innan du väljer, och protokollbeslutet blir betydligt enklare.
Titta sedan på vad transporten tillåter
WireGuard-protokollet använder UDP. OpenVPN-tjänster kan erbjuda både UDP- och TCP-profiler, och i ett nätverk som blockerar eller försämrar UDP är det andra alternativet en praktisk reservväg och inte en teoretisk. Servern måste stödja den profil du väljer, och ett ändrat portnummer gör inte tunneln till HTTPS eller övertygar en brandvägg att släppa igenom den.
Att bära TCP inuti TCP ändrar också beteendet vid förlust, eftersom båda lagren försöker igen och ordnar om oberoende av varandra. En TCP-profil som fungerar i ett restriktivt nätverk kan fortfarande prestera dåligt i ett förlustdrabbat nätverk, och det är ett skäl att hålla båda profilerna tillgängliga i stället för att utropa en som överlägsen.
Kontrollera sedan routning och namnmatchning
AllowedIPs i WireGuard mappar adressintervall till parter och fungerar som ett routningsbeslut inne i protokollet, och verktygen runt omkring använder dessa intervall när de installerar rutter. OpenVPN skjuter rutter och DNS-alternativ från servern. I båda fallen kan klienten komma upp medan den avsedda policyn bara är halvt tillämpad.
ip route show
ip -6 route show
resolvectl status
wg show
Läs utdata innan du litar på anslutningsindikatorn. ip route show listar vad klienten installerade för IPv4, och IPv6-varianten fångar en tunnel som bara bär en familj. resolvectl status visar vilken resolver klienten faktiskt kommer att fråga, och wg show skriver ut de AllowedIPs som WireGuard anser sig äga. Om resolvern fortfarande pekar på det lokala nätverket medan rutterna hävdar full täckning, lämnar DNS tunneln.
Mät sedan uppgiften du bryr dig om
Håll enheten, nätverket och målet oförändrade och notera de klienter och ändpunkter du använde. Om de två tjänsterna går ut i olika städer eller körs på olika hårdvara, säg det, eftersom resultatet då beskriver tjänsterna och inte protokollen.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20
Kör båda kommandona två gånger, en gång per profilpar, i samma nätverk och på samma enhet. iperf3 ger en genomströmningssiffra, och mtr ger vägen och var förlust uppträder, vilket en enda nedladdningssiffra inte kan visa. En nedladdningssiffra missar också det ett samtal märker: ökad latens, jitter och hur lång tid en återanslutning tar. Notera det separat, eftersom ett protokoll som vinner på genomströmning fortfarande kan förlora på uppgiften du faktiskt kör.
För en hanterad anslutning kan kompatibilitet, support och förnyelsearbete väga tyngre än en liten benchmark-skillnad. För en personlig utgång betyder leverantörens loggning och jurisdiktion mer än protokolletiketten. Båda protokollen kan bära en bra anslutning; tjänsten och dess konfiguration avgör vad du får.
Skriv ned profilparet innan du testar
Välj en profil per protokoll innan du mäter, och skriv ned vad var och en ska göra: bara privata subnät eller all trafik med en bestämd utgång. Ett test som jämför en splitt-tunnelprofil med en fulltunnelprofil mäter profilerna, inte protokollen. Sätt klientnamnet, klientversionen och utgångens placering i samma anteckning.
Kör sedan samma uppgift på båda, i samma nätverk, i samma session. Om en inte kan ansluta alls är det felet resultatet och hör hemma i anteckningen tillsammans med orsaken. Förvara anteckningen med tjänstens dokumentation så att nästa person jämför samma par i stället för att börja om.