OpenVPN of WireGuard? Beslis op basis van identiteit en transport

Deze twee protocollen vergelijken is alleen nuttig als het vergelijkt wat u daadwerkelijk gaat beheren. WireGuard identificeert peers met een publieke sleutel en draagt zijn protocol over UDP, terwijl OpenVPN een breder scala aan authenticatiemethoden biedt en over UDP of TCP kan werken wanneer de server beide biedt. Die verschillen bepalen de inrichting en de terugvalroute veel eerder dan de doorvoer. Voer de vier controles hieronder in volgorde uit; de eerste twee bepalen meestal de keuze, en de laatste twee zeggen of de beslissing juist was.

Begin met identiteit, niet met de cijferlijst

Een WireGuard-peer bewaart één privésleutel en somt de publieke sleutels op die hij kan bereiken. Een provider kan daar een accountportaal omheen bouwen, maar het protocol zelf kent geen uitwisseling van gebruikersnaam en wachtwoord, dus de levenscyclus van het account leeft in wat de sleutels distribueert. OpenVPN kan certificaten, een plug-in tegen een bestaande directory of een verificatiescript gebruiken, en daarom geven organisaties met een identiteitssysteem er vaak de voorkeur aan. Geen van beide ontwerpen haalt de vraag weg hoe een verloren apparaat wordt verwijderd.

Een korte configuratie is niet hetzelfde als eenvoudige inrichting. Eén privésleutel aan meerdere mensen geven maakt latere verwijdering dubbelzinnig, omdat intrekking iedereen tegelijk verwijdert. Schrijf de koppeling van persoon naar sleutel of certificaat op voordat u kiest, en de protocolbeslissing wordt aanzienlijk eenvoudiger.

Kijk dan wat het transport toestaat

Het protocol van WireGuard gebruikt UDP. OpenVPN-diensten kunnen zowel UDP- als TCP-profielen bieden, en op een netwerk dat UDP blokkeert of verslechtert is die tweede optie een praktische terugvalroute en geen theoretische. De server moet het profiel ondersteunen dat u kiest, en een ander poortnummer maakt de tunnel niet HTTPS en overtuigt geen firewall om hem door te laten.

TCP in TCP dragen verandert ook het gedrag bij verlies, omdat beide lagen onafhankelijk opnieuw proberen en herordenen. Een TCP-profiel dat op een restrictief netwerk werkt, kan op een netwerk met verlies nog steeds slecht presteren, en dat is een reden om beide profielen beschikbaar te houden in plaats van er één superieur te verklaren.

Controleer dan routering en naamresolutie

AllowedIPs van WireGuard koppelt adresbereiken aan peers en fungeert als een routeringsbeslissing binnen het protocol, en de omringende tools gebruiken die bereiken wanneer ze routes installeren. OpenVPN duwt routes en DNS-opties vanaf de server. In beide gevallen kan de client omhoog komen terwijl het beoogde beleid slechts half is toegepast.

ip route show
ip -6 route show
resolvectl status
wg show

Lees de uitvoer voordat u de verbonden-indicator vertrouwt. ip route show somt op wat de client voor IPv4 heeft geïnstalleerd, en de IPv6-variant vangt een tunnel die maar één familie draagt. resolvectl status toont welke resolver de client werkelijk zal vragen, en wg show drukt de AllowedIPs af die WireGuard denkt te bezitten. Als de resolver nog naar het lokale netwerk wijst terwijl de routes volledige dekking claimen, verlaat DNS de tunnel.

Meet dan de taak die u belangrijk vindt

Houd het apparaat, het netwerk en de bestemming vast, en noteer de clients en eindpunten die u gebruikte. Als de twee diensten in verschillende steden uitgaan of op verschillende hardware draaien, zeg dat dan, want dan beschrijft het resultaat die diensten en niet de protocollen.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

Voer beide opdrachten twee keer uit, één keer per profielpaar, op hetzelfde netwerk en hetzelfde apparaat. iperf3 geeft een doorvoercijfer, en mtr geeft het pad en waar verlies optreedt, wat één downloadcijfer niet kan tonen. Een downloadcijfer mist ook wat een gesprek merkt: extra latentie, jitter en hoe lang een herverbinding duurt. Noteer dat apart, want een protocol dat wint op doorvoer kan nog steeds verliezen op de taak die u werkelijk uitvoert.

Bij een beheerde verbinding kunnen compatibiliteit, ondersteuning en vernieuwingsinspanning zwaarder wegen dan een klein benchmarkverschil. Bij een persoonlijke uitgang tellen logging en jurisdictie van de aanbieder meer dan het protocollabel. Beide protocollen kunnen een goede verbinding dragen; de dienst en zijn configuratie bepalen wat u krijgt.

Schrijf het profielpaar op voordat u test

Kies één profiel per protocol voordat u meet, en schrijf op wat elk hoort te doen: alleen privésubnetten of al het verkeer met een specifieke uitgang. Een test die een split-tunnelprofiel met een volledig tunnelprofiel vergelijkt, meet de profielen en niet de protocollen. Zet de clientnaam, de clientversie en de locatie van de uitgang in dezelfde notitie.

Voer daarna dezelfde taak op beide uit, op hetzelfde netwerk, in dezelfde sessie. Als één helemaal geen verbinding krijgt, is die fout het resultaat en hoort die met de reden in het verslag. Bewaar het verslag bij de dienstdocumentatie, zodat de volgende persoon hetzelfde paar vergelijkt in plaats van opnieuw te beginnen.