Як вибрати клієнт VPN для Mac до наявного шлюзу

На сторінці завантаження з'являються шість застосунків VPN для Mac, і жоден не каже, який прийме шлюз вашого роботодавця. Це не прогалина в магазині, а прогалина в передачі. Один SSL VPN — це родина продуктів, а не протокол, тому два шлюзи з однаковим екраном входу можуть вимагати різних клієнтів. Ось порядок, якого я дотримуюся, коли мені передають Mac і адресу сервера: з'ясуйте, чим говорить шлюз, виберіть відповідний клієнт, а потім перевірте маршрути та DNS, перш ніж довіряти тунелю роботу.

Почніть зі шлюзу, а не з магазину застосунків

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

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

• Режим доступу: портал у браузері, доступ до вибраного застосунку або повний мережевий тунель. Це вирішує, чи потрібен вам клієнт узагалі.

• Родина шлюзу та підтримуваний випуск: продукт, увімкнена служба та версія клієнта, яка все ще підтримує вашу збірку macOS і ваше обладнання Mac.

• Автентифікація: пароль з MFA, вхід через браузер, сертифікат пристрою або перевірка стану. Клієнт без схваленого сценарію підключиться і потім буде відхилений.

• Власність: довірене джерело завантаження чи керування, передбачений профіль і той, хто підтримує його, коли він ламається.

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

SSL VPN — це ярлик родини, а не протокол

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

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

У профілю OpenVPN те саме обмеження з іншого боку: це формат імпорту для розгортання, сумісного з OpenVPN. Спільний TLS як будівельний блок не робить його файлом конфігурації для довільного корпоративного шлюзу. Тому робочий вхід через браузер — хибне спрацювання: доступ до порталу може вдатися, коли тунелю немає, а піднятий тунель згодом усе одно може бути відхилений перевіркою стану.

Узгодьте клієнт із тим, чим говорить шлюз

Коли родина відома, вибір швидко звужується. Це таблиця відповідності, яку я перевіряю першою, і останній стовпець важливіший за будь-який рейтинг застосунку.

Два рядки заслуговують на попередження. Вбудований клієнт macOS — справжня реалізація IKEv2, а не універсальний клієнт SSL VPN: служба, розрахована на нього, потребує правильного профілю, очікуваної ідентичності сервера й облікових даних, а на керованій машині цей профіль може бути заблокований. OpenConnect покриває кілька протоколів виробників з одного бінарника, але сам проєкт не заявляє підтримки виробників; сканування хоста, правила роздільного тунелю, які надсилає шлюз, або певний сценарій SSO можуть існувати лише в клієнті виробника.

WireGuard має ту саму форму. Служба дає вузли, клієнт дає тунель, а профіль OpenVPN не замінює його. Одна складка macOS: клієнт з App Store тримає свої тунелі всередині мережевого розширення, тому wg show з інструментів Homebrew може нічого не показувати, поки інтерфейс піднятий. Перевіряйте натомість маршрутами й трафіком.

Налаштуйте, а потім перевірте у фіксованому порядку

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

scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dns

Підключіться з наданим профілем і повторіть ті самі команди. За повного тунелю маршрут за замовчуванням має вказувати на інтерфейс utun; за роздільного тунелю маршрутизуватися мають лише внутрішні префікси, а публічний вихід має виглядати незмінним. DNS — та половина, яка зазвичай лишається зламаною: scutil --dns перелічує резолвери в тому порядку, у якому система їх використовуватиме, і внутрішній резолвер нижче публічного відправить внутрішні імена не тому серверу.

Для служби OpenVPN Tunnelblick — розумний безкоштовний клієнт, і його власний посібник прямо говорить про відсутню половину: він не надає послугу VPN. Двічі клацніть .ovpn, який вам видали, дайте Tunnelblick встановити його, і звірте випуск із вашою версією macOS, перш ніж покладатися на нього.

Для шлюзу виробника я часто перевіряю через OpenConnect з командного рядка:

brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.com

Інструмент друкує отриманий сертифікат і чекає, перш ніж довіряти незнайомому ланцюгу; це запрошення — функція, і закріплення через --servercert pin-sha256:... краще, ніж прийняти попередження, яке ви не прочитали. Ctrl-C розриває тунель, бо openconnect на передньому плані не має ні аварійного перемикача, ні логіки перепідключення. Це годиться для діагностичного сеансу і погано як типове значення для щоденної роботи.

Коли немає шлюзу, під який можна підлаштуватися

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

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

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

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

Короткий контрольний список перед першим справжнім сеансом

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

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