Srovnávat tyto dva protokoly má smysl jen tehdy, když srovnáváte to, co budete skutečně provozovat. WireGuard identifikuje protějšky veřejným klíčem a nese svůj protokol přes UDP, zatímco OpenVPN nabízí širší soubor způsobů autentizace a umí běžet přes UDP i TCP, když server nabízí obojí. Tyto rozdíly formují přípravu a záložní cestu mnohem dřív, než formují propustnost. Proveďte čtyři níže uvedené kontroly v pořadí; první dvě obvykle rozhodnou volbu a poslední dvě řeknou, zda bylo rozhodnutí správné.

Začněte identitou, ne seznamem šifer

Protějšek WireGuardu ukládá jeden soukromý klíč a vypisuje veřejné klíče, na které dosáhne. Poskytovatel kolem toho může postavit portál účtu, ale protokol sám nemá výměnu uživatelského jména a hesla, takže životní cyklus účtu žije v tom, co klíče distribuuje. OpenVPN může použít certifikáty, plugin proti existujícímu adresáři nebo ověřovací skript, a proto jej organizace se systémem identity často preferují. Ani jeden návrh neodstraňuje otázku, jak se odstraní ztracené zařízení.

DecisionOpenVPNWireGuard
IdentityCertificates, plugins or scripts against an existing directoryOne private key per peer, public keys listed for the peers it may reach
TransportUDP or TCP profiles when the server offers bothUDP only in the native protocol
Routing and DNSServer pushes routes and DNS optionsAllowedIPs maps ranges to peers, and tooling installs the routes
Where it usually breaksProfile mismatch, expired certificate, failing pluginBlocked UDP, wrong AllowedIPs, key not installed

Krátká konfigurace není totéž co jednoduchá příprava. Předání jednoho soukromého klíče několika lidem činí pozdější odebrání nejednoznačným, protože jeho odvolání odebere všechny najednou. Zapište mapování osoby na klíč nebo certifikát ještě před volbou a rozhodnutí o protokolu bude podstatně snazší.

Pak se podívejte, co transport dovoluje

Protokol WireGuard používá UDP. Služby OpenVPN mohou nabízet profily UDP i TCP a v síti, která UDP blokuje nebo zhoršuje, je druhá možnost praktickou záložní cestou, nikoli teoretickou. Server musí vybraný profil podporovat a změna čísla portu nepřemění tunel na HTTPS ani nepřesvědčí firewall, aby jej povolil.

Přenášení TCP uvnitř TCP také mění chování při ztrátách, protože obě vrstvy nezávisle opakují pokusy a přeuspořádávají. Profil TCP, který funguje v restriktivní síti, může v síti se ztrátami podávat špatné výsledky, a to je důvod držet oba profily dostupné, místo abyste jeden prohlásili za lepší.

Pak zkontrolujte směrování a překlad jmen

AllowedIPs ve WireGuardu mapuje rozsahy adres na protějšky a působí jako rozhodnutí o směrování uvnitř protokolu, a okolní nástroje tyto rozsahy používají, když instalují trasy. OpenVPN tlačí trasy a možnosti DNS ze serveru. V obou případech může klient naběhnout, zatímco zamýšlená politika je aplikována jen napůl.

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

Přečtěte si výstup, než uvěříte indikátoru připojení. ip route show vypisuje, co klient nainstaloval pro IPv4, a varianta IPv6 zachytí tunel, který nese jen jednu rodinu. resolvectl status ukazuje, který resolver se klient skutečně zeptá, a wg show vypisuje AllowedIPs, o nichž se WireGuard domnívá, že je vlastní. Pokud resolver stále ukazuje na lokální síť, zatímco trasy tvrdí plné pokrytí, DNS vychází mimo tunel.

Pak změřte úlohu, na které vám záleží

Držte zařízení, síť a cíl beze změny a zapište klienty a koncové body, které jste použili. Pokud obě služby vycházejí v různých městech nebo běží na jiném hardwaru, řekněte to, protože výsledek pak popisuje tyto služby, a ne protokoly.

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

Spusťte oba příkazy dvakrát, jednou pro každou dvojici profilů, ve stejné síti a na stejném zařízení. iperf3 dává číslo propustnosti a mtr dává cestu a místo, kde se objevují ztráty, což jediné číslo stahování ukázat nedokáže. Číslo stahování také pomíjí to, co postřehne hovor: přidanou latenci, kolísání a jak dlouho trvá opětovné připojení. Zapisujte to zvlášť, protože protokol, který vyhrává v propustnosti, může stále prohrát v úloze, kterou skutečně provozujete.

U spravovaného připojení mohou kompatibilita, podpora a úsilí o obnovu převážit malý rozdíl v měření. U osobního výstupu záleží na protokolování a jurisdikci provozovatele víc než na označení protokolu. Oba protokoly unesou dobré připojení; služba a její konfigurace rozhodují, co dostanete.

Zapište dvojici profilů před testem

Před měřením zvolte jeden profil na protokol a zapište, co má každý dělat: jen soukromé podsítě, nebo veškerý provoz s konkrétním výstupem. Test, který srovnává profil rozděleného tunelu s profilem plného tunelu, měří profily, ne protokoly. Dejte jméno klienta, verzi klienta a umístění výstupu do stejné poznámky.

Pak spusťte stejnou úlohu na obou, ve stejné síti, ve stejné relaci. Pokud se jeden vůbec nepřipojí, to selhání je výsledek a patří do záznamu i s důvodem. Uchovávejte záznam s dokumentací služby, aby příští člověk srovnal stejnou dvojici, místo aby začínal znovu.

Související články