OpenVPN czy WireGuard? Zdecyduj na podstawie tożsamości i transportu
Klucze, przebiegi logowania i transport wyłącznie przez UDP kształtują wybór znacznie wcześniej niż przepustowość. Wykonaj cztery kontrole i utrzymaj pomiar uczciwie.
Porównywanie tych dwóch protokołów ma sens tylko wtedy, gdy porównuje to, czym naprawdę będziesz zarządzać. WireGuard identyfikuje partnerów kluczem publicznym i przenosi swój protokół przez UDP, podczas gdy OpenVPN oferuje szerszy zestaw metod uwierzytelniania i może działać przez UDP lub TCP, gdy serwer udostępnia oba. Te różnice kształtują wdrożenie i drogę zapasową znacznie wcześniej, niż kształtują przepustowość. Wykonaj cztery kontrole poniżej po kolei; pierwsze dwie zwykle rozstrzygają wybór, a dwie ostatnie mówią, czy decyzja była trafna.
Zacznij od tożsamości, nie od listy szyfrów
Partner WireGuard przechowuje jeden klucz prywatny i wymienia klucze publiczne, do których może dotrzeć. Dostawca może opakować to portalem konta, ale sam protokół nie ma wymiany nazwy użytkownika i hasła, więc cykl życia konta żyje w tym, co rozdaje klucze. OpenVPN może używać certyfikatów, wtyczki wobec istniejącego katalogu lub skryptu weryfikacji, i dlatego organizacje z systemem tożsamości często go wybierają. Żadna z obu konstrukcji nie usuwa pytania, jak usunąć utracone urządzenie.
| 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 |
Krótka konfiguracja to nie to samo co proste wdrożenie. Przekazanie jednego klucza prywatnego kilku osobom sprawia, że późniejsze usunięcie jest niejednoznaczne, bo jego odwołanie usuwa wszystkich naraz. Zapisz mapowanie osoby na klucz lub certyfikat przed wyborem, a decyzja o protokole stanie się znacznie łatwiejsza.
Potem sprawdź, na co pozwala transport
Protokół WireGuard używa UDP. Usługi OpenVPN mogą oferować profile UDP i TCP, a w sieci, która blokuje lub pogarsza UDP, druga opcja jest praktyczną drogą zapasową, a nie teoretyczną. Serwer musi obsługiwać wybrany profil, a zmiana numeru portu nie zamienia tunelu w HTTPS ani nie przekonuje zapory, by go przepuściła.
Przenoszenie TCP wewnątrz TCP zmienia też zachowanie przy stratach, ponieważ obie warstwy niezależnie ponawiają próby i zmieniają kolejność. Profil TCP działający w sieci restrykcyjnej nadal może wypadać słabo w sieci ze stratami, i to jest powód, by trzymać oba profile dostępne, zamiast ogłaszać jeden lepszym.
Następnie sprawdź trasowanie i rozwiązywanie nazw
AllowedIPs w WireGuard mapuje zakresy adresów na partnerów i działa jako decyzja o trasowaniu wewnątrz protokołu, a otaczające narzędzia używają tych zakresów, gdy instalują trasy. OpenVPN wypycha trasy i opcje DNS z serwera. W obu przypadkach klient może wstać, gdy zamierzona polityka jest zastosowana tylko połowicznie.
ip route show
ip -6 route show
resolvectl status
wg show
Przeczytaj wynik, zanim zaufasz wskaźnikowi połączenia. ip route show wymienia, co klient zainstalował dla IPv4, a wariant IPv6 wyłapuje tunel, który niesie tylko jedną rodzinę. resolvectl status pokazuje, którego resolvera klient naprawdę zapyta, a wg show wypisuje AllowedIPs, które WireGuard uważa za swoje. Jeśli resolver nadal wskazuje sieć lokalną, gdy trasy twierdzą, że pokrycie jest pełne, DNS wychodzi poza tunel.
Następnie zmierz zadanie, na którym ci zależy
Utrzymuj urządzenie, sieć i cel bez zmian i zapisz użyte klienty oraz punkty końcowe. Jeśli dwie usługi wychodzą w różnych miastach albo działają na innym sprzęcie, powiedz to, bo wtedy wynik opisuje te usługi, a nie protokoły.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20
Uruchom oba polecenia dwa razy, raz na każdą parę profili, w tej samej sieci i na tym samym urządzeniu. iperf3 daje liczbę przepustowości, a mtr daje ścieżkę i miejsce, w którym pojawiają się straty, czego jedna liczba pobierania nie pokaże. Liczba pobierania pomija też to, co zauważa rozmowa: dodane opóźnienie, jitter i czas ponownego połączenia. Zapisuj je osobno, bo protokół wygrywający na przepustowości nadal może przegrać w zadaniu, które naprawdę wykonujesz.
W połączeniu zarządzanym zgodność, wsparcie i nakład na odnawianie mogą przeważyć niewielką różnicę w pomiarze. W wyjściu osobistym rejestrowanie i jurysdykcja operatora liczą się bardziej niż etykieta protokołu. Oba protokoły potrafią nieść dobre połączenie; usługa i jej konfiguracja decydują, co otrzymujesz.
Zapisz parę profili przed testem
Przed pomiarem wybierz jeden profil na protokół i zapisz, co każdy ma robić: tylko prywatne podsieci albo cały ruch z konkretnym wyjściem. Test, który porównuje profil z dzielonym tunelem z profilem pełnego tunelu, mierzy profile, a nie protokoły. Umieść nazwę klienta, wersję klienta i lokalizację wyjścia w tej samej notatce.
Następnie uruchom to samo zadanie na obu, w tej samej sieci, w tej samej sesji. Jeśli jeden w ogóle nie potrafi się połączyć, ta porażka jest wynikiem i należy do zapisu wraz z przyczyną. Przechowuj zapis razem z dokumentacją usługi, aby następna osoba porównała tę samą parę, zamiast zaczynać od nowa.