Перейти к содержимомуОпределите, будет ли это полный переход или параллельный запуск
Первое решение простое, хотя последствия могут быть непростыми. Либо вы сразу заменяете OpenVPN везде, либо какое-то время запускаете WireGuard рядом с OpenVPN и переводите клиентов по одной группе за раз. Домашняя лаборатория с 2–3 пользователями часто может справиться с полным переходом за один вечер. Небольшой офис с удалёнными сотрудниками обычно — нет.
Полный переход означает одно окно изменений, одну новую конфигурацию клиента и один чёткий разрыв со старым туннелем. Это аккуратно. Но и безжалостно. Если DNS-сервер или маршрут настроены неверно, это сразу почувствуют все клиенты.
Параллельный запуск даёт больше пространства для манёвра. OpenVPN остаётся в работе, пока WireGuard тестируют на ноутбуке, телефоне или одном устройстве филиала. Это разумно для удалённых команд, где кому-то в другом часовом поясе нужен доступ к 9 утра, а не после выходных. Если вы читаете это потому, что вам нужно понять WireGuard или OpenVPN для приватности, держите это сравнение в уме, но не позволяйте ему отвлекать вас от механики миграции здесь.
Выбирайте схему по риску, а не по вкусу. Домашняя лаборатория может позволить себе час на исправление. Офис на 12 человек обычно нуждается в запасном пути. В этом и разница, когда речь идёт о переходе с OpenVPN на WireGuard.
Составьте перечень того, что сейчас делает ваша установка OpenVPN
Прежде чем трогать WireGuard, запишите все задачи, которые OpenVPN выполняет сегодня. Не «почти всё». Именно всё. Успех или провал миграции зависит от этого списка из 6 областей: подсети удалённого доступа, маршрутизация между клиентами, настройки DNS, раздельное туннелирование, проброс портов и исключения для отдельных устройств.
Подсети удалённого доступа проще всего забыть, потому что они кажутся очевидными. Один клиент видит 10.8.0.0/24, другой — сеть филиала, а третий получает доступ только к одному административному хосту. Этот сценарий должен сохраниться после перехода. Если принтер или сервер резервного копирования доступен только по очень конкретному маршруту, укажите точный префикс и имя устройства.
Маршрутизация между клиентами заслуживает отдельной строки. В некоторых установках OpenVPN один удалённый пользователь может обращаться к другому, в других этот трафик специально блокируется. То же самое относится и к раздельному туннелированию. Ноутбук отдела продаж может отправлять через туннель только внутренний трафик, а стриминг и обычный веб-сёрфинг остаются вне его. Если пропустить такую деталь, пользователь заметит это сразу.
Настройки DNS — тихая ловушка. Один сервер OpenVPN передаёт внутренний резолвер, другой раздаёт поисковый домен, третий делает и то и другое. Запишите IP сервера, суффикс поиска и любые специальные исключения для одной-двух машин. Один пропущенный DNS-правилo может создать впечатление, что миграция сломана, даже если сам туннель работает.
Проброс портов и исключения для устройств — последние элементы. Возможно, одной камере нужен входящий доступ через VPN. Возможно, старый Linux-хост игнорирует переданные маршруты, пока не получит специальный скрипт. Этот чек-лист — не инструкция по настройке. Это лист сопоставления. Если во время работы вам нужен более широкий ориентир по терминам, глоссарий VPN и прокси поможет не путаться в названиях.
Сопоставьте настройки OpenVPN с понятиями WireGuard
Это этап перевода. Конфигурация сервера OpenVPN становится конфигурацией интерфейса WireGuard. Профили клиентов OpenVPN превращаются в записи peers. Логика сертификатов и TLS у клиента исчезает, потому что WireGuard работает с ключами и списками allowed IPs. Это важно, потому что миграция — не операция копирования и вставки, и именно так обычно выглядит настройка WireGuard вместо OpenVPN.
Начните с серверной стороны. Адрес сервера OpenVPN становится адресом туннеля WireGuard и портом прослушивания на новом интерфейсе. Порт может остаться привычным, но смысл меняется. WireGuard не «пушит» параметры так, как это делает OpenVPN. Вы явно задаёте для каждой пары peer, что каждая сторона может отправлять и получать.
Allowed IPs — это место, где многие миграции ломаются. В OpenVPN вы могли полагаться на передаваемые маршруты или файлы CCD. В WireGuard allowed IPs определяют и маршрутизацию, и выбор peer. Если клиенту нужна только сеть 10.20.0.0/16, укажите ровно её. Если ему нужна ещё и подсеть туннеля, добавьте и её. Без догадок.
Endpoint address — это публичная сторона нового туннеля. Это может быть тот же hostname, который пользователи уже знают, или новый DNS-запись, если вы хотите чёткое разделение. Preshared keys необязательны, но если у вас чувствительный участок или требование комплаенса, зафиксируйте, где они хранятся и кто может их пересоздавать. Миграция с 14 клиентами и 1 забытым исключением всё равно считается провалом для этого одного человека.
Правила маршрутизации тоже нужно сопоставить напрямую. OpenVPN часто прячет обработку маршрутов за серверными директивами. WireGuard заставляет прописывать это явно. В первый день это раздражает, а на 30-й день оказывается полезным. Если перед тем как выбрать путь миграции вам нужен обзор протоколов, посмотрите как выбрать VPN.
Подготовьте сторону WireGuard до отключения OpenVPN
Не выключайте OpenVPN первым. Полностью соберите сторону WireGuard, пока OpenVPN всё ещё передаёт трафик. Создайте пары ключей, назначьте адреса туннеля, выберите порт прослушивания и заранее подготовьте записи peer для каждого существующего клиента OpenVPN. Так у вас будет рабочая цель до того, как пользователю предложат переключиться.
План адресов туннеля должен быть простым. Если сервер получает 10.50.0.1/24, назначьте каждому клиенту фиксированный адрес и один раз его запишите. Не переносите старые предположения из OpenVPN без проверки. Один ноутбук мог годами получать адрес динамически, но WireGuard любит явное сопоставление. Это не проблема, это факт.
Тщательно задокументируйте старые идентификаторы клиентов. Сопоставьте каждый сертификат или имя профиля OpenVPN с реальным устройством и человеком, который им пользуется. «alice-laptop» лучше, чем «client7». «Планшет склада» лучше, чем «tablet-2». Вы скажете себе спасибо, когда одному пользователю нужно будет восстановить доступ до обеда.
Предварительное создание записей peer также помогает рано обнаружить пропущенные устройства. Если телефон подрядчика всё ещё числится в списке OpenVPN, вы сможете решить, мигрировать его или убрать из эксплуатации. Если старый тестовый профиль всё ещё существует, удалите его сейчас. В WireGuard устаревшие записи легко заметить, и это полезно, хотя и довольно беспощадно.
Если вы всё ещё сравниваете конфигурации и хотите короткую заметку о поведении протоколов, статью WireGuard или OpenVPN для приватности можно прочитать отдельно. Для этого шага важно только одно: сторона WireGuard должна быть полностью готова до перехода первого пользователя.
Переводите клиентов небольшими группами и оставьте запасной путь
Переведите сначала одно доверенное устройство. Не три. Не ноутбук генерального директора. Выберите систему, до которой при необходимости можно добраться физически или через другой канал. Идеален доверенный админский ноутбук, потому что тестирующий сможет точно сказать, что сломалось, а не просто «что-то не так».
После того как первое устройство заработает, переведите небольшую группу. 2–5 клиентов — разумный ритм для небольшого офиса, особенно если они зависят от одного и того же маршрута или DNS-сервера. Оставляйте OpenVPN включённым, пока каждый перенесённый клиент не подтвердит подключение. Это правило не даёт плохому маршруту превратиться в лавину обращений в поддержку.
Запасной путь должен быть практичным. Если пользователь теряет доступ к файловому серверу из-за неверной записи allowed IP, вы должны быстро восстановить старый профиль OpenVPN. Откат, требующий новой правки firewall, сводит смысл на нет. Оставляйте старый сервис активным, пока новый клиент не доказал свою работоспособность в реальной работе, а не только на тестовом ping.
Следите и за порядком миграции. Сначала лучше переводить тех, кто работает в офисе, а уже потом тех, кто часто в разъездах, если офисная команда сможет помочь с диагностикой. Устройства, которые засыпают, перемещаются между сетями или часто меняют подключение, обычно быстрее выявляют проблемы. Это полезно. И именно поэтому поэтапная миграция экономит время позже.
Командам, которые занимаются удалённым администрированием, может помочь быстрый взгляд на как проверить, что ваш IP скрыт для контрольных проверок после переключения. Здесь речь не об анонимности. Речь о том, чтобы понимать, что видит сеть, когда клиент снова выходит в онлайн.
Проверяйте сложные моменты после каждого переключения
Каждому перенесённому клиенту нужны одни и те же немедленные проверки. Сначала проверьте рукопожатие. Затем доступ к внутреннему хосту. Потом DNS. Потом переподключение после сна. Порядок важен, потому что первая ошибка часто скрывает вторую.
Сам по себе успешный handshake мало что доказывает. Туннель может подняться, но при этом не иметь маршрута к бухгалтерскому серверу. Клиент может видеть одну подсеть и не видеть другую. Поэтому нужно проверять внутренние ресурсы и по имени, и по IP-адресу. Если имя работает, а IP нет, DNS настроен не так, как маршрут. Если не работает ни то ни другое, список allowed IP неверен или трафик всё ещё блокирует firewall.
Мобильные сети стоит проверять отдельно, потому что они меняют путь пакетов, поведение NAT и таймеры простоя. Ноутбук, который работает в офисном Wi‑Fi, может перестать работать в кафе через 3 минуты сна. Поведение после пробуждения — ещё один частый сюрприз. Одно устройство возвращается без проблем, другому нужно перезапустить туннель, прежде чем оно увидит что-то за пределами gateway.
Раздельное туннелирование заслуживает настоящей проверки, а не предположения. Откройте публичный сайт и внутренний хост одновременно. Если оба типа трафика идут через туннель, профиль клиента настроен неверно. Если внутренний трафик утекает наружу, список маршрутов неполный. Это разные неисправности, и исправляются они по-разному.
Для каждого перенесённого устройства используйте чек-лист. Укажите имя устройства. Зафиксируйте время. Отметьте проверенную подсеть. Немного дисциплины здесь экономит часы позже, особенно когда уже перенесено 8 устройств, а одно из них тихо маршрутизируется неверно.
Безопасно отключайте OpenVPN только после подтверждения, что всё работает
Не удаляйте OpenVPN в тот момент, когда WireGuard просто выглядит рабочим. Подождите, пока каждый перенесённый клиент не будет протестирован в обычной работе хотя бы в течение полного рабочего цикла, и ведите учёт устройств, которые всё ещё зависят от старого сервиса. Затем начинайте очистку в контролируемом порядке.
Сначала отзовите или выведите из эксплуатации старые клиентские профили OpenVPN. Если профиль принадлежал подрядчику, который ушёл в 2023 году, удалите его. Если сертификат использовался тестовым хостом, архивируйте его и пометьте как неиспользуемый. Затем удалите неиспользуемые правила firewall, записи сервиса и любые port forwarding, которые существовали только для OpenVPN. Это уменьшит путаницу в следующий раз, когда кто-то будет читать набор правил.
Сохраните старую конфигурацию в архив для аудита. Сохраните серверный файл, список клиентов и любые заметки об исключениях. Через месяц кто-то может спросить, почему одна подсеть маршрутизировалась иначе. Если ответ хранится только в памяти, он уже слабый.
Наконец, задокументируйте топологию WireGuard: имена, адреса и 1–2 особых случая, которые не вписываются в общую схему. Пишите просто. Укажите подсеть туннеля, порт прослушивания, имена peers и причину, по которой у какого-то peer ограничен доступ. Именно здесь будущая поддержка становится проще.
И если позже новый коллега спросит, как мигрировать с OpenVPN на WireGuard, ответ не должен начинаться с догадок. Он должен начинаться с файла топологии, сохранённых заметок о запасном пути и точного момента, когда OpenVPN был выведен из эксплуатации.