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 даёт путь и место, где появляются потери, чего одна цифра загрузки показать не может. Цифра загрузки также упускает то, что замечает звонок: добавленную задержку, дрожание и сколько занимает переподключение. Записывайте это отдельно, потому что протокол, выигрывающий по пропускной способности, всё равно может проиграть в задаче, которую вы действительно выполняете.
Для управляемого подключения совместимость, поддержка и усилия на продление могут перевесить небольшую разницу в измерении. Для личного выхода ведение журналов и юрисдикция оператора важнее ярлыка протокола. Оба протокола способны нести хорошее подключение; сервис и его конфигурация решают, что вы получите.
Запишите пару профилей до теста
Выберите по одному профилю на протокол до измерения и запишите, что должен делать каждый: только частные подсети или весь трафик с определённым выходом. Тест, который сравнивает профиль раздельного туннеля с профилем полного туннеля, измеряет профили, а не протоколы. Поместите имя клиента, версию клиента и расположение выхода в одну и ту же заметку.
Затем выполните ту же задачу на обоих, в одной и той же сети, в одной и той же сессии. Если один вообще не может подключиться, этот сбой и есть результат, и он вместе с причиной принадлежит записи. Храните запись вместе с документацией сервиса, чтобы следующий человек сравнил ту же пару, а не начинал заново.