Рушій OpenVPN чи Tunnelblick: кому належить сеанс VPN на Mac?

Homebrew встановлює програму OpenVPN; Tunnelblick встановлює менеджер, який запускає один або кілька рушіїв. Це різні рівні, і корисне питання не в тому, чи подобається вам користуватися терміналом. А в тому, кому належать конфігурація, зміни DNS, запит облікових даних і очищення після завершення сеансу. Єдиний власник цих рівнів робить налаштування передбачуваним.

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

Перевірка перша: який бінарний файл OpenVPN справді працює

Виконайте pgrep -fl openvpn, поки з'єднання активне, і прочитайте весь командний рядок. Перший шлях — це рушій, який справді працює. На Apple Silicon встановлення Homebrew зазвичай розташоване в /opt/homebrew, Mac на Intel використовують /usr/local, а Tunnelblick запускає рушій зсередини власного пакета програми.

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

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

Перевірка друга: хто змінює DNS і маршрути

Рушій може виконувати власні директиви up і down OpenVPN, але менеджер може володіти тим самим життєвим циклом. Налаштування сервера імен Tunnelblick керують його стандартними скриптами підключення й відключення, і коли цю інтеграцію ввімкнено, конкуруючі директиви в профілі можуть ігноруватися.

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

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

Перевірка третя: звідки беруться облікові дані

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

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

Перевірка четверта: хто запускає, контролює та зупиняє процес

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

Якщо Tunnelblick залишається власником, використовуйте його підтримувані елементи керування замість запуску другого рушія. Бінарний файл Homebrew, отримавши скопійований профіль, відкриває незалежне з'єднання з власною конфігурацією й контекстом інтеграції, а не командує наявним сеансом Tunnelblick.

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

Перевірка п'ята: як перевіряється передача

Перевірте нового власника з вимкненим старим, а потім перевірте старий знову, якщо плануєте його залишити. Приватний ресурс, який відповідає в одному сценарії й не відповідає в іншому, — доказ про відсутню інтеграцію, а не про сервер.

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

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

Пакування не вирішує сумісність із сервером. Перевірте власні вимоги сервісу до клієнта й вибирайте рушій окремо лише тоді, коли збираєтеся забезпечити його керування.