OpenVPN чи IKEv2: чотири перевірки перед вибором протоколу

Вибір між OpenVPN і IKEv2 зазвичай обговорюють як питання протоколу, і таке формулювання марнує рішення. Вирішує те, чи підтримують сервер і пристрої той самий повний профіль і чи витримує цей профіль те, як ви переміщуєтеся між мережами. Два стеки не перекладаються один в одного: файл OVPN не є профілем IKEv2 з іншим синтаксисом. Чотири перевірки, виконані по порядку, відповідають на питання швидше за будь-яку таблицю можливостей.

Відсутній клієнт завершує суперечку

Windows і macOS постачаються з клієнтом IKEv2, тому профіль IKEv2 там нічого додатково не коштує під час розгортання і успадковує параметри підготовки, які система вже надає. OpenVPN на тих самих машинах означає сторонній клієнт, який треба встановити, оновлювати й підтримувати, і цей клієнт має приймати кожен параметр, який використовує профіль. Порахуйте платформи, які треба охопити, перш ніж порівнювати щось інше, бо платформа без робочого клієнта взагалі не є точкою порівняння.

У Windows одна команда перелічує наявні профілі й показує, якого типу кожен із них. Ім'я, яке вона виводить, — це ім'я, яке використовують подальші перевірки.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Запит на встановлення клієнта — це справжня відповідь для стовпця OpenVPN на цих платформах, і це завдання розгортання, а не обмеження протоколу. Жоден варіант не усуває перевірки довіри, перевірку особи або обслуговування. Запитайте, як поширюються профілі, як оновлюються облікові дані та як видаляється втрачений пристрій, перш ніж брати зобов'язання. Просте встановлення все ще може приховувати процедуру відновлення, яку ніхто не хоче запускати на вихідних.

Мобільність — це спільне налаштування, а не обіцянка протоколу

IKEv2 може використовувати MOBIKE, коли обидві сторони його підтримують і вмикають, що дозволяє клієнту зберігати тунель, поки його адреса змінюється. RFC 4555 визначає це розширення, і умовне формулювання важливе: сервер, який ігнорує цю можливість, натомість проводить повторні переговори. Результат може виглядати однаково під час передавання файлу і зовсім інакше під час живого виклику.

Перевірте той перехід, який вам справді важливий, при чомусь працюючому, за чим можна спостерігати. Залиште ping -t <internal-host> працювати у Windows або простий ping в іншому місці, потім перемкніться з Wi-Fi на мобільну мережу й стежте за розривами. Збій MOBIKE в журналі клієнта виглядає як повна повторна автентифікація, а не як тихе оновлення адреси. Ви вимірюєте, чи переживає тунель зміну, а не чи рекламує протокол підтримку.

Клієнти OpenVPN перепідключаються відповідно до поведінки своєї платформи та таймерів профілю, тому той самий тест може дати іншу форму перерви. Порівнюйте подію, важливу для ваших користувачів, а не ярлик на протоколі.

Облікові дані належать сервісу, а не стеку

Сертифікати та інші схеми входу належать сервісу, який завершує з'єднання. Запит пароля в одному клієнті нічого не говорить про сумісність з іншим, а профіль, що працює з іншим шлюзом, нічого не говорить про цей. Зберігайте правила ідентичності сервера незмінними, поки порівнюєте два стеки. Зміна протоколів до виявлення збою зазвичай дає другий несумісний профіль.

Перевірте облікові дані, які клієнт пред'явить, перш ніж звинувачувати будь-який протокол, бо прострочений або неправильно виданий сертифікат зазнає невдачі однаково в обох випадках. Вивід нижче показує суб'єкт, видавця та дати чинності, не читаючи закритий ключ.

openssl x509 -in client.crt -noout -subject -issuer -dates

Для корпоративного підключення використовуйте метод, який публікує компанія, і перестаньте ставитися до порівняння як до експерименту. Якщо ви порівнюєте обидва варіанти самі, спершу перевірте, чи обидва закінчуються на одному шлюзі, бо ця єдина деталь вирішує, наскільки ваш результат стосується протоколу. Відмова, у якій названо облікові дані, — це проблема облікових даних, і жодна зміна протоколу її не виправить.

Перевірте, що тунель насправді маршрутизує

Після підключення підтвердьте, що потрібний маршрут існує і що імена розв'язуються. Профіль, що існує для внутрішніх ресурсів, може навмисно залишати звичайний перегляд на локальному шляху, і це рішення політики, а не несправність. Важливо, чи доступні через тунель призначення, якими користується ваша команда.

У Windows дві команди охоплюють маршрут і пошук імен. Відповідники в Linux — ip route show default і resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Тунель, що піднімається і нічого корисного не маршрутизує, — частий результат, коли профіль скопіювали між сервісами, і загальний тест зв'язності цього не покаже, бо інтерфейс піднято. Перевіряйте ресурс, який ваші користувачі відкривають першим, а не публічну адресу, доступну будь-якому шляху. Якщо ім'я розв'язується в публічну адресу, а маршрут вказує всередину тунелю, відповідь DNS і маршрут належать різним рішенням, і обидва треба виправити.

Після перевірок зважте обслуговування

Жоден протокол не є зручнішим в обслуговуванні в абстрактному сенсі. Обслуговування залежить від того, хто керує шлюзом, як профілі потрапляють на пристрої і як швидко втрачений пристрій втрачає доступ. Простий клієнт на боці користувача може стояти перед складнішим в обслуговуванні сервером, і буває навпаки. Запитайте, який із двох ваша команда зможе підтримувати після того, як людина, що його створила, піде.

Виберіть підтримуване підключення, що покриває роботу, потім перевірте його на тому доступі, який вам справді потрібен, а не на списку можливостей. Запишіть, на якому шлюзі закінчується кожен варіант, бо два різні шлюзи роблять порівняння однаково питанням маршрутів, як і протоколів. Повторіть чотири перевірки на пристрої, який ви справді носитимете, і залиште профіль, що проходить на ньому.