OpenVPN чи WireGuard? Вирішіть за ідентичністю і транспортом
Ключі, сценарії входу та транспорт лише через UDP формують вибір задовго до пропускної здатності. Проведіть чотири перевірки й збережіть вимірювання чесним.
Порівнювати ці два протоколи корисно лише тоді, коли порівняння стосується того, чим ви справді керуватимете. WireGuard визначає партнерів за відкритим ключем і передає свій протокол через UDP, тоді як OpenVPN пропонує ширший набір способів автентифікації і може працювати через UDP або TCP, коли сервер надає обидва. Ці відмінності формують розгортання та резервний шлях значно раніше, ніж формують пропускну здатність. Проведіть чотири перевірки нижче по порядку; перші дві зазвичай вирішують вибір, а останні дві кажуть, чи було рішення правильним.
Почніть з ідентичності, а не зі списку шифрів
Партнер WireGuard зберігає один закритий ключ і перелічує відкриті ключі, до яких може дістатися. Провайдер може обгорнути це порталом облікового запису, але сам протокол не має обміну іменем користувача й паролем, тому життєвий цикл облікового запису живе в тому, що роздає ключі. OpenVPN може використовувати сертифікати, плагін до наявного каталогу або скрипт перевірки, і саме тому організації із системою ідентичності часто віддають йому перевагу. Жодне з двох рішень не прибирає питання, як видаляється втрачений пристрій.
| 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 |
Коротка конфігурація — не те саме, що просте розгортання. Якщо один закритий ключ видають кільком людям, подальше видалення стає неоднозначним, бо відкликання ключа видаляє всіх одразу. Запишіть відповідність людини ключу або сертифікату до вибору, і рішення щодо протоколу стане значно простішим.
Потім подивіться, що дозволяє транспорт
Протокол WireGuard використовує UDP. Сервіси OpenVPN можуть пропонувати профілі і через UDP, і через TCP, а в мережі, яка блокує або погіршує UDP, другий варіант виявляється практичним резервним шляхом, а не теоретичним. Сервер має підтримувати вибраний профіль, і зміна номера порту не перетворює тунель на HTTPS і не переконує міжмережевий екран пропустити його.
Передача TCP усередині TCP також змінює поведінку за втрат, бо обидва рівні незалежно повторюють спроби й перевпорядковують. Профіль TCP, який працює в обмежувальній мережі, усе одно може показувати погані результати в мережі з втратами, і це причина тримати обидва профілі доступними, а не оголошувати один кращим.
Потім перевірте маршрутизацію та розв'язання імен
AllowedIPs у WireGuard зіставляє діапазони адрес із партнерами й діє як рішення про маршрутизацію всередині протоколу, а навколишні інструменти використовують ці діапазони, коли встановлюють маршрути. OpenVPN передає маршрути й параметри DNS із сервера. В обох випадках клієнт може піднятися, тоді як потрібна політика застосована лише наполовину.
ip route show
ip -6 route show
resolvectl status
wg show
Прочитайте вивід, перш ніж довіряти індикатору підключення. ip route show перелічує, що клієнт встановив для IPv4, а варіант IPv6 ловить тунель, який несе лише одну родину. resolvectl status показує, до якого розпізнавача клієнт справді звернеться, а wg show друкує AllowedIPs, які WireGuard вважає своїми. Якщо розпізнавач досі вказує на локальну мережу, поки маршрути заявляють повне покриття, DNS виходить за межі тунелю.
Потім виміряйте завдання, яке вам важливе
Тримайте пристрій, мережу й пункт призначення незмінними та запишіть використані клієнти й кінцеві точки. Якщо два сервіси виходять у різних містах або працюють на різному обладнанні, скажіть про це, бо тоді результат описує ці сервіси, а не протоколи.
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20
Запустіть обидві команди двічі, по одному разу на кожну пару профілів, у тій самій мережі й на тому самому пристрої. iperf3 дає цифру пропускної здатності, а mtr дає шлях і місце, де з'являються втрати, чого одна цифра завантаження показати не може. Цифра завантаження також оминає те, що помічає виклик: додану затримку, дрижання і скільки триває перепідключення. Записуйте це окремо, бо протокол, який виграє за пропускною здатністю, усе одно може програти в завданні, яке ви справді виконуєте.
Для керованого з'єднання сумісність, підтримка й зусилля на поновлення можуть переважити невелику різницю у вимірюванні. Для особистого виходу ведення журналів і юрисдикція оператора важливіші за ярлик протоколу. Обидва протоколи здатні нести добре з'єднання; сервіс і його конфігурація вирішують, що ви отримаєте.
Запишіть пару профілів до тесту
Виберіть по одному профілю на протокол до вимірювання й запишіть, що має робити кожен: лише приватні підмережі або весь трафік із певним виходом. Тест, який порівнює профіль роздільного тунелю з профілем повного тунелю, вимірює профілі, а не протоколи. Помістіть ім'я клієнта, версію клієнта й розташування виходу в ту саму нотатку.
Потім виконайте те саме завдання на обох, у тій самій мережі, у тій самій сесії. Якщо один узагалі не може підключитися, цей збій і є результат, і він разом із причиною належить запису. Зберігайте запис разом із документацією сервісу, щоб наступна людина порівняла ту саму пару, а не починала заново.