Перейти до змістуВирішіть, чи це буде повний перехід, чи паралельне впровадження
Перше рішення просте, хоча наслідки — ні. Ви або одразу повністю замінюєте OpenVPN, або певний час запускаєте WireGuard поруч із OpenVPN і переносите клієнтів групами по одному. Домашня лабораторія з 2 чи 3 користувачами часто може впоратися з повним переходом за один вечір. Невеликий офіс із віддаленими співробітниками зазвичай — ні.
Повний перехід означає одне вікно змін, одну нову конфігурацію клієнта і один чистий відрив від старого тунелю. Це акуратно. Але й безжально. Якщо DNS-сервер або маршрут налаштовані неправильно, це одразу відчує кожен клієнт.
Паралельне впровадження дає більше простору для маневру. OpenVPN залишається активним, поки WireGuard тестують на ноутбуці, телефоні або одному пристрої філії. Це доречно для віддалених команд, де комусь в іншому часовому поясі потрібен доступ о 9-й ранку, а не після вихідних. Якщо ви читаєте це, бо хочете зрозуміти WireGuard чи OpenVPN приватність, тримайте це порівняння в голові, але не дозволяйте йому відволікати вас від механіки міграції.
Обирайте підхід за ризиком, а не за смаком. Домашня лабораторія може пережити годину на виправлення помилок. Офіс на 12 людей зазвичай потребує запасний шлях. У цьому й різниця.
Інвентаризуйте, що зараз робить ваше розгортання OpenVPN
Перш ніж торкатися WireGuard, запишіть усі завдання, які сьогодні виконує OpenVPN. Не “більшість”. Усі. Міграція з OpenVPN на WireGuard залежить від цього списку з 6 сфер: підмережі віддаленого доступу, маршрутизація між клієнтами, налаштування DNS, роздільне тунелювання, перенаправлення портів і винятки для окремих пристроїв.
Підмережі віддаленого доступу найпростіше забути, бо вони здаються очевидними. Один клієнт дістається до 10.8.0.0/24, інший — до мережі філії, а третій має доступ лише до одного адмін-хоста. Цей шаблон має зберегтися після переходу. Якщо принтер або сервер резервного копіювання доступний лише через дуже специфічний маршрут, занотуйте точний префікс і назву пристрою.
Маршрутизація між клієнтами заслуговує на окремий рядок. Деякі розгортання OpenVPN дозволяють одному віддаленому користувачу дістатися до іншого; інші навмисно блокують такий трафік. Те саме стосується і роздільного тунелювання. Ноутбук відділу продажів може відправляти через тунель лише внутрішній трафік, а потокове відео й звичайний вебперегляд залишатимуться поза ним. Якщо пропустити цю деталь, користувач помітить це миттєво.
Налаштування DNS — це тихий підступ. Один сервер OpenVPN підсовує внутрішній резолвер; інший видає домен для пошуку; третій включає і те, і те. Запишіть IP сервера, суфікс пошуку та будь-які особливі винятки для однієї-двох машин. Один пропущений DNS-правило може створити враження, що вся міграція зламана, навіть якщо сам тунель працює.
Перенаправлення портів і винятки для пристроїв — це останні елементи. Можливо, одній камері потрібен вхідний доступ через VPN. Можливо, старий Linux-хост ігнорує маршрути, якщо не отримує спеціальний скрипт. Цей чекліст — не інструкція з налаштування. Це таблиця відповідностей. Якщо під час роботи вам потрібен ширший довідник термінів, глосарій VPN і проксі допоможе не плутати назви.
Співставте налаштування OpenVPN із поняттями WireGuard
Це етап перекладу. Конфігурація сервера OpenVPN перетворюється на конфігурацію інтерфейсу WireGuard. Профілі клієнтів OpenVPN стають записами peer. Сертифікат клієнта та логіка TLS зникають, бо WireGuard працює з ключами та allowed IPs. Це важливо, бо міграція — не проста операція копіювання-вставлення.
Почніть із серверної частини. Адреса сервера OpenVPN стає адресою тунелю WireGuard і портом прослуховування на новому інтерфейсі. Порт може залишитися знайомим, але зміст змінюється. WireGuard не “пушить” параметри так, як це робить OpenVPN. Ви явно визначаєте для кожного peer, що саме кожна сторона може надсилати й отримувати. Саме тому потрібне чітке налаштування WireGuard після OpenVPN.
Allowed IPs — це місце, де багато міграцій ідуть не так. В OpenVPN ви могли покладатися на маршрути, що передаються сервером, або на CCD-файли. У WireGuard allowed IPs визначають і маршрутизацію, і вибір peer. Якщо клієнту потрібен доступ до 10.20.0.0/16 і більше нічого, вкажіть саме це. Якщо йому також потрібна підмережа тунелю, додайте й її. Жодних здогадок.
Адреса endpoint — це публічна сторона нового тунелю. Це може бути той самий хостнейм, який користувачі вже знають, або новий запис, якщо ви хочете чітко відокремити старе від нового. Preshared keys — опційні, але якщо у вас чутлива локація або вимога комплаєнсу, задокументуйте, де вони зберігаються і хто може їх перевипустити. Міграція з 14 клієнтами і 1 забутим винятком усе одно є невдалою міграцією для тієї людини.
Правила маршрутизації також потрібно зіставити напряму. OpenVPN часто приховує обробку маршрутів за директивами сервера. WireGuard змушує прописати це явно. У перший день це дратує, а на 30-й — дуже корисно. Якщо перед вибором шляху міграції вам потрібне свіже нагадування про варіанти протоколів, дивіться як обрати VPN.
Підготуйте сторону WireGuard до вимкнення OpenVPN
Не вимикайте OpenVPN першим. Повністю зберіть сторону WireGuard, поки OpenVPN ще переносить трафік. Створіть пари ключів, призначте IP-адреси тунелю, оберіть порт прослуховування та заздалегідь підготуйте записи peer для кожного наявного клієнта OpenVPN. Так у вас буде робоча ціль ще до того, як когось попросять перейти.
Тримайте план IP-адрес тунелю простим. Якщо сервер отримує 10.50.0.1/24, призначте кожному клієнту фіксовану адресу і запишіть її один раз. Не повторюйте старі припущення OpenVPN, не перевіривши їх. Один ноутбук міг роками отримувати адресу динамічно, але WireGuard любить явне зіставлення. Це не проблема; це факт.
Уважно задокументуйте старі ідентичності клієнтів. Зіставте кожен сертифікат або назву профілю OpenVPN із реальним пристроєм та людиною, яка ним користується. “alice-laptop” краще за “client7”. “Планшет складу” краще за “tablet-2”. Ви подякуєте собі, коли один користувач скаже, що доступ треба відновити до обіду.
Попереднє створення записів peer також допомагає раніше виявити відсутні пристрої. Якщо телефон підрядника все ще був у списку OpenVPN, ви можете вирішити, чи його потрібно переносити, чи вже списати. Якщо старий тестовий профіль досі є, видаліть його зараз. WireGuard робить застарілі записи помітними, а це корисно, хоч і трохи безкомпромісно.
Якщо ви досі порівнюєте конфігурації й хочете окрему нотатку про поведінку протоколів, статтю про WireGuard чи OpenVPN приватність можна прочитати окремо. Для цього етапу важливо лише одне: щоб сторона WireGuard була повністю готова до переходу першого користувача.
Переносьте клієнтів невеликими групами і зберігайте шлях відкату
Спочатку перенесіть один довірений пристрій. Не три. Не ноутбук CEO. Візьміть систему, до якої можна дістатися фізично або іншим каналом, якщо знадобиться. Ідеально підійде довірений адмінський ноутбук, бо той, хто його тестує, зможе точно сказати, що зламалося, а не просто “щось не так”.
Після того як перший пристрій запрацює, перенесіть невелику партію. Два–5 клієнтів — нормальний темп для невеликого офісу, особливо якщо вони залежать від одного маршруту або DNS-сервера. Тримайте OpenVPN увімкненим, доки кожен перенесений клієнт не підтвердить з’єднання. Одне це правило рятує від того, щоб поганий маршрут перетворився на лавину звернень у підтримку.
Шлях відкату має бути практичним. Якщо користувач втратив доступ до файлового сервера через неправильний запис allowed IP, ви повинні швидко відновити старий профіль OpenVPN. Відкат, який потребує нової зміни в брандмауері, зводить сенс нанівець. Тримайте старий сервіс живим, доки новий клієнт не буде перевірено в реальній роботі, а не лише тестовим ping.
Стежте й за порядком міграції. Людей, які подорожують, краще переносити після офісних пристроїв, якщо офісна команда може допомогти з усуненням неполадок. Пристрої, що засинають, роумлять або часто змінюють мережі, зазвичай швидше виявляють проблеми. Це корисно. І саме тому поетапна міграція економить час пізніше.
Для команд, які покладаються на віддалене адміністрування, короткий погляд на як перевірити, якою є ваша IP-адреса може допомогти з перевірками після перемикання. Суть тут не в анонімності. Суть у тому, щоб знати, що бачить мережа, коли клієнт знову виходить в онлайн.
Перевіряйте складні моменти після кожного перемикання
Кожен перенесений клієнт має пройти ті самі негайні тести. Спочатку перевірте handshake. Потім дістайтеся до внутрішнього хоста. Потім протестуйте DNS. Потім перепідключіться після сну. Порядок важливий, бо перша помилка часто приховує другу.
Сам по собі успішний handshake мало що доводить. Тунель може піднятися й усе одно не мати маршруту до бухгалтерського сервера. Клієнт може дістатися до однієї підмережі й провалитися на іншій. Саме тому ви тестуєте внутрішні ресурси і за ім’ям, і за IP-адресою. Якщо ім’я працює, а IP — ні, проблема не в тому ж, що й маршрут. Якщо не працює ні те, ні інше, список allowed IPs неправильний або трафік досі блокує брандмауер.
Мобільні мережі варто перевіряти, бо вони змінюють шлях пакетів, поведінку NAT і таймери простою. Ноутбук, який добре працює на офісному Wi‑Fi, може збоїти на хотспоті в кав’ярні після 3 хвилин сну. Поведінка після пробудження — ще один поширений сюрприз. Один пристрій відновлюється без проблем; іншому треба перезапустити тунель, перш ніж він побачить щось за межами шлюзу.
Роздільне тунелювання потрібно тестувати по-справжньому, а не вгадувати. Відкрийте одночасно публічний сайт і внутрішній хост. Якщо обидва типи трафіку заходять у тунель, профіль клієнта неправильний. Якщо внутрішній трафік витікає назовні, список маршрутів неповний. Це різні несправності, і виправляються вони по-різному.
Ведіть чекліст для кожного перенесеного пристрою. Запишіть назву пристрою. Зафіксуйте час. Вкажіть протестовану підмережу. Трохи дисципліни тут зекономить години пізніше, особливо коли вже перенесено 8 пристроїв і один із них тихо маршрутизується неправильно.
Безпечно виведіть OpenVPN з експлуатації, коли все підтверджено
Не прибирайте OpenVPN у момент, коли WireGuard лише здається здоровим. Зачекайте, доки кожен перенесений клієнт не буде перевірено в нормальній роботі принаймні протягом одного повного робочого циклу, і зберігайте записи про те, які пристрої ще залежать від старого сервісу. Потім починайте очищення в контрольованому порядку.
Спочатку відкличте або виведіть з ужитку старі профілі клієнтів OpenVPN. Якщо профіль належав підряднику, який пішов у 2023 році, видаліть його. Якщо сертифікат використовувався тестовим хостом, заархівуйте його й позначте як невикористаний. Потім приберіть невживані правила брандмауера, записи сервісів і всі перенаправлення портів, які існували лише для OpenVPN. Це зменшить плутанину, коли хтось наступного разу читатиме набір правил.
Заархівуйте стару конфігурацію для аудиту. Збережіть файл сервера, список клієнтів і будь-які нотатки про винятки. За місяць хтось може запитати, чому одна підмережа маршрутизувалася інакше. Якщо відповідь лишилась у пам’яті, така відповідь уже слабка.
Нарешті, задокументуйте топологію WireGuard з назвами, адресами та 1 чи 2 особливими випадками, які не вписуються в шаблон. Пишіть просто. Вкажіть підмережу тунелю, порт прослуховування, назви peer і причину, чому будь-який peer має обмежений доступ. Саме тут майбутнє обслуговування стає простішим.
І якщо згодом новий колега запитає, як перейти з OpenVPN на WireGuard, відповідь не повинна починатися з припущень. Вона має починатися з файлу топології, збережених нотаток про відкат і точного моменту, коли OpenVPN було виведено з експлуатації.