Миграция с одного VPN-протокола на другой без даунтайма

MAATRIX

Рано или поздно любой VPN-сервер, который живёт больше года-двух, упирается в вопрос смены протокола: OpenVPN начинает казаться медленным и тяжёлым для мобильных клиентов, Shadowsocks — недостаточно быстрым для десятка одновременных пользователей, а WireGuard или VLESS выглядят современнее и проще в поддержке. Проблема в том, что просто взять и переключить сервер нельзя — у вас есть работающие клиенты, которым нужен доступ прямо сейчас, а не после того, как вы разберётесь с новой конфигурацией. Решение — держать оба протокола на одном сервере параллельно, пока последний пользователь не перейдёт на новый, и только потом гасить старый.

Почему это работает: два протокола — это просто два сервиса

VPN-протоколы почти никогда не конкурируют за одни и те же ресурсы сервера напрямую. OpenVPN слушает свой порт (обычно 1194/UDP), WireGuard — свой (например, 51820/UDP), Shadowsocks или Outline — ещё один. Это независимые процессы (или systemd-юниты), каждый со своим сетевым интерфейсом (tun0 у OpenVPN, wg0 у WireGuard) и своей подсетью для клиентов. Единственное, что их объединяет — сетевой стек хоста и правила iptables/nftables, которые пробрасывают трафик из VPN-подсети в интернет через NAT.

Отсюда и вся стратегия миграции:

1. Поднять новый протокол рядом со старым, на отдельном порту и в отдельной подсети.
2. Прописать NAT-правила для новой подсети, не трогая правила старой.
3. Постепенно выдавать конфиги новому протоколу активным пользователям.
4. Следить, когда трафик на старом протоколе перестанет идти.
5. Отключить старый сервис только после того, как убедились, что на него никто не полагается.

Ниже — рабочий пример на связке OpenVPN → WireGuard, самой частой в 2026 году, но принцип идентичен для любой другой пары: Shadowsocks → Outline, WireGuard → VLESS, SoftEther → WireGuard и так далее. Если нужен фон по самим протоколам, вот сравнение WireGuard и OpenVPN.

Готовим сервер: порты, интерфейсы, изоляция подсетей

Прежде чем разворачивать второй протокол, зафиксируйте адресацию, чтобы подсети не пересекались и NAT-правила не путались.

Пример распределения для сервера, где уже работает OpenVPN на 10.8.0.0/24:

Проверьте, что порт для нового протокола свободен и открыт в firewall:

sudo ss -tulnp | grep -E '1194|51820'
sudo ufw allow 51820/udp comment 'wireguard migration'
sudo ufw status numbered

Если сервер стоит за облачным firewall (Security Group у провайдера, отдельный NAT-фильтр), правило нужно продублировать и там — иначе локальный ufw/iptables пропустит пакет, а до сервера он просто не дойдёт.

Включите IP-форвардинг, если он ещё не включён (обычно уже включён ради OpenVPN, но проверить не лишнее):

sysctl net.ipv4.ip_forward
# если 0 — включаем
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Поднимаем новый протокол рядом со старым

Разворачиваем WireGuard стандартным способом — пошагово это описано в статье про установку WireGuard на VPS, здесь только ключевые моменты, специфичные для миграции.

Конфиг сервера /etc/wireguard/wg0.conf:

[Interface]
Address = 10.9.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key>
# NAT только для НОВОЙ подсети — не трогаем правила OpenVPN
PostUp = iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

[Peer]
# первый мигрирующий клиент
PublicKey = <client_public_key>
AllowedIPs = 10.9.0.2/32

Обратите внимание на два момента, которые часто ломают параллельный запуск:

• PostUp/PostDown должны фильтровать по подсети -s 10.9.0.0/24, а не по интерфейсу целиком — иначе при чистке правил можно случайно снести NAT для OpenVPN, если оба скрипта используют одинаковые метки цепочек.
• DNS и маршруты у клиента не должны конфликтовать с уже установленным OpenVPN-туннелем на том же устройстве, если тестируете миграцию, не отключая старое подключение — два активных туннеля на одном устройстве почти всегда спорят за маршрут по умолчанию.

Запускаем и проверяем:

sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0
sudo wg show

openvpn@server при этом продолжает работать как ни в чём не бывало — второй systemctl status openvpn@server должен показывать active (running) точно так же, как до начала работ.

Поэтапный перевод пользователей

Здесь главная ошибка — разослать всем новые конфиги одним письмом и попросить переключиться «когда удобно». Так вы теряете видимость, кто уже перешёл, а кто просто забыл. Лучше вести миграцию волнами и фиксировать статус явно, например в простой таблице (google-таблица или файл — не так важно):

1. Волна 1 — вы сами и 1-2 технически подкованных пользователя. Проверяете, что конфиг рабочий, скорость и стабильность устраивают, DNS не подтекает (см. проверку DNS leak).
2. Волна 2 — активные пользователи, у которых нет критичных ограничений (не корпоративный firewall, который блокирует нестандартные UDP-порты, не устройство с проблемной поддержкой WireGuard).
3. Волна 3 — оставшиеся, включая тех, кому нужно ручное сопровождение (созвон, помощь с установкой клиента).

На каждого клиента для нового протокола заводите отдельную пару ключей — не пытайтесь переиспользовать старые OpenVPN-сертификаты для WireGuard, это разные криптосистемы. Добавление нового пира в WireGuard не требует перезапуска интерфейса:

wg set wg0 peer <new_client_public_key> allowed-ips 10.9.0.5/32
wg-quick save wg0

Пользователям, которые пока остаются на старом протоколе, ничего менять не нужно — их сертификаты и конфиги продолжают работать без изменений, потому что вы не трогали OpenVPN-сервис вообще.

Как понять, что старый протокол пора отключать

Отключать OpenVPN «на глазок» рискованно — всегда находится тот самый клиент, который не читал письма. Прежде чем гасить сервис, соберите данные за 1-2 недели.

Проверка активных подключений на старом сервере:

# OpenVPN: список текущих клиентов
sudo cat /etc/openvpn/openvpn-status.log

# либо через journalctl за период
sudo journalctl -u openvpn@server --since "7 days ago" | grep -i "peer connection initiated"

Если статус-лог пуст или в нём только тестовые подключения от вас самих — можно переходить к отключению. Дополнительно стоит:

• Снизить TTL до минимума заранее не получится (в отличие от DNS), поэтому лучше просто заранее предупредить оставшихся пользователей о дате отключения — например, за 3-5 дней.
• Отключать не сразу физически, а сначала «мягко»: закрыть порт 1194/UDP в firewall, оставив сервис запущенным ещё сутки-двое. Если кто-то жалуется — открываете обратно, разбираетесь, кого забыли перевести.

sudo ufw delete allow 1194/udp
sudo ufw status

Только после этого — окончательное отключение сервиса:

sudo systemctl disable --now openvpn@server

Конфиги и сертификаты стоит не удалять сразу, а архивировать на пару недель — на случай, если понадобится откатиться. Если у вас есть резервный сервер или схема автопереключения, логика перехода на нём аналогична описанной в статье про резервный VPN-сервер и автопереключение.

Типичные проблемы при переходе

• Оба протокола NAT'ят через один и тот же внешний IP, и провайдер режет суммарную полосу. Если сервер маломощный, два активных туннеля одновременно могут упереться в CPU (шифрование) или в сетевой лимит тарифа — на переходный период стоит временно взять план с запасом или вовсе перенести миграцию на отдельный сервер, а после завершения — вернуться на прежний тариф.
• Клиенты держат оба туннеля одновременно на одном устройстве и получают конфликт маршрутов по умолчанию — обычно проявляется как «интернет пропал, хотя VPN подключен». Решение — явно объяснять пользователям, что тестировать новый конфиг нужно с отключённым старым, либо использовать split-tunneling с разными диапазонами адресов.
• Забытые автозапуски и systemd-таймеры, которые переподключают старый клиент на телефоне или роутере после перезагрузки — человек думает, что перешёл на WireGuard, а на самом деле роутер по расписанию снова поднимает OpenVPN. Стоит явно попросить пользователей удалить старый профиль после успешного перехода, а не просто оставить его «на всякий случай».
• Разные MTU у протоколов. WireGuard обычно требует MTU около 1420, у OpenVPN он часто иной. Если оба туннеля идут через одну и ту же внешнюю сеть с дополнительной инкапсуляцией (например, вы сами сидите за корпоративным VPN), стоит проверить фрагментацию отдельно для каждого протокола — не переносить старые значения MTU бездумно.
• Пользователи с ограничениями сети (гостиничный Wi-Fi, мобильный оператор с блокировкой нестандартных UDP-портов) могут обнаружить, что новый протокол у них просто не проходит, хотя у остальных всё работает. Для таких случаев держите план Б — протокол, который сложнее детектировать и блокировать точечно, и который можно временно выдать этим пользователям отдельно.

Частые вопросы