OpenVPN vagy WireGuard? Döntsön az identitás és a szállítás alapján

E két protokoll összehasonlítása csak akkor hasznos, ha azt hasonlítja össze, amit valóban üzemeltetni fog. A WireGuard nyilvános kulccsal azonosítja a partnereket, és UDP-n szállítja a protokollját, míg OpenVPN szélesebb hitelesítési megoldáskészletet kínál, és UDP-n vagy TCP-n is futhat, ha a szerver mindkettőt kínálja. Ezek a különbségek jóval korábban alakítják a kiépítést és a tartalék útvonalat, mint az átbocsátóképességet. Végezze el az alábbi négy ellenőrzést sorrendben; az első kettő általában eldönti a választást, az utolsó kettő pedig megmondja, helyes volt-e a döntés.

Az identitással kezdje, ne a titkosítási listával

Egy WireGuard-partner egy privát kulcsot tárol, és felsorolja azokat a nyilvános kulcsokat, amelyeket elérhet. Egy szolgáltató körbeveheti ezt egy fiókportállal, de maga a protokoll nem tartalmaz felhasználónév- és jelszóváltást, ezért a fiók életciklusa abban él, ami a kulcsokat kiosztja. Az OpenVPN használhat tanúsítványokat, egy meglévő könyvtár elleni bővítményt vagy ellenőrző szkriptet, és ezért az identitásrendszerrel rendelkező szervezetek gyakran előnyben részesítik. Egyik megoldás sem szünteti meg azt a kérdést, hogyan távolítják el az elveszett eszközt.

A rövid konfiguráció nem ugyanaz, mint az egyszerű kiépítés. Ha egy privát kulcsot több embernek adnak, a későbbi eltávolítás kétértelművé válik, mert a visszavonás mindenkit egyszerre távolít el. Választás előtt írja fel a személy és a kulcs vagy tanúsítvány közötti megfeleltetést, és a protokollról szóló döntés sokkal könnyebb lesz.

Ezután nézze meg, mit enged a szállítás

A WireGuard protokollja UDP-t használ. Az OpenVPN-szolgáltatások UDP- és TCP-profilokat is kínálhatnak, és egy UDP-t blokkoló vagy rontó hálózaton ez a második lehetőség gyakorlati tartalék útvonal, nem elméleti. A szervernek támogatnia kell a választott profilt, és a portszám módosítása nem teszi a csatornát HTTPS-sé, és nem győz meg egy tűzfalat az engedélyezéséről.

A TCP TCP-ben való szállítása a veszteség melletti viselkedést is megváltoztatja, mert mindkét réteg egymástól függetlenül próbálkozik újra és rendez át. Egy restriktív hálózaton működő TCP-profil veszteséges hálózaton még mindig gyengén teljesíthet, és ez ok arra, hogy mindkét profil elérhető maradjon, ahelyett hogy az egyiket jobbnak nyilvánítanák.

Ezután ellenőrizze az útválasztást és a névfeloldást

A WireGuard AllowedIPs-e címtartományokat rendel a partnerekhez, és útválasztási döntésként működik a protokollon belül, a környező eszközök pedig ezeket a tartományokat használják az útvonalak telepítésekor. Az OpenVPN a szerverről tolja az útvonalakat és a DNS-beállításokat. Mindkét esetben a kliens feljöhet, miközben a szándékolt szabályzat csak félig érvényesül.

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

Olvassa el a kimenetet, mielőtt megbízik a csatlakoztatva jelzőben. A ip route show felsorolja, mit telepített a kliens IPv4-hez, az IPv6-os változat pedig elkapja az egyetlen családot szállító csatornát. A resolvectl status megmutatja, melyik feloldót kérdezi majd a kliens valójában, a wg show pedig kiírja azokat az AllowedIPs-eket, amelyeket a WireGuard a sajátjának hisz. Ha a feloldó továbbra is a helyi hálózatra mutat, miközben az útvonalak teljes lefedettséget állítanak, a DNS kikerül a csatornán kívülre.

Ezután mérje meg a számára fontos feladatot

Tartsa változatlanul az eszközt, a hálózatot és a célt, és jegyezze fel a használt klienseket és végpontokat. Ha a két szolgáltatás különböző városokban lép ki, vagy különböző hardveren fut, mondja meg, mert akkor az eredmény ezeket a szolgáltatásokat írja le, nem a protokollokat.

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

Futtassa mindkét parancsot kétszer, profilonként egyszer, ugyanazon a hálózaton és eszközön. A iperf3 átbocsátóképességi számot ad, a mtr pedig az útvonalat és azt, hogy hol jelenik meg veszteség, amit egyetlen letöltési szám nem tud megmutatni. A letöltési szám azt is kihagyja, amit egy hívás észlel: a hozzáadott késleltetést, a remegést és azt, mennyi ideig tart az újracsatlakozás. Ezeket külön jegyezze fel, mert egy átbocsátóképességben nyerő protokoll még veszíthet azon a feladaton, amelyet valóban futtat.

Kezelt kapcsolatnál a kompatibilitás, a támogatás és a megújítási erőfeszítés felülmúlhat egy kis mérési különbséget. Személyes kilépésnél az üzemeltető naplózása és joghatósága fontosabb, mint a protokoll címkéje. Mindkét protokoll szállíthat jó kapcsolatot; a szolgáltatás és annak konfigurációja dönti el, mit kap.

Írja fel a profilpárt a teszt előtt

Mérés előtt válasszon egy profilt protokollonként, és írja fel, mit kell tennie mindegyiknek: csak privát alhálózatok, vagy minden forgalom egy adott kilépéssel. Az a teszt, amely egy megosztott csatornás profilt egy teljes csatornás profillal hasonlít össze, a profilokat méri, nem a protokollokat. Tegye ugyanabba a feljegyzésbe a kliens nevét, a kliens verzióját és a kilépés helyét.

Ezután futtassa ugyanazt a feladatot mindkettőn, ugyanazon a hálózaton, ugyanabban a munkamenetben. Ha az egyik egyáltalán nem tud csatlakozni, az a kudarc az eredmény, és az okkal együtt a feljegyzésbe tartozik. Tartsa a feljegyzést a szolgáltatás dokumentációjával, hogy a következő ember ugyanazt a párt hasonlítsa össze, ne kezdje elölről.