Який протокол стоїть за збереженим профілем VPN на Mac?

Хтось називає з'єднання на Mac «офісним VPN», мітка переживає дві міграції сервера, і всі продовжують називати його офісним VPN ще довго після того, як протокол змінився. Назва — це прізвисько, збережене поряд із конфігурацією; воно не є доказом того, про що домовляється Mac. Читання заявленого типу потребує одного поля, а відокремлення збереженого типу від живого сеансу — ще одного кроку. Ось порядок, який уникає здогадів.

Мітка — це прізвисько, тип оголошує корисне навантаження

Служба VPN у macOS — це запис системної конфігурації з відображуваним ім'ям, клієнтом-власником і набором типізованих параметрів. Відображуване ім'я — вільний текст, який може змінити кожен, хто створив запис, і саме цю частину користувачі бачать у рядку меню. Параметри несуть факти: який тип з'єднання, який шлюз, яка схема автентифікації. Ніщо не тримає ці дві частини узгодженими, тому профіль із назвою «офіс L2TP» може бути службою IKEv2.

Для з'єднання, створеного особисто, ці параметри показує застосунок-власник або власна панель VPN системи. На керованому Mac профіль належить адміністратору, і правильний крок — попросити несекретний підсумок, а не редагувати кероване корисне навантаження. Обидва випадки виглядають однаково в рядку меню й поводяться зовсім по-різному під ним. Один ваш для огляду й зміни; інший розгорнутий і буде відновлений під час наступної перевірки.

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

Прочитайте VPNType перед усім іншим у корисному навантаженні

Схема керованого корисного навантаження VPN від Apple оголошує тип з'єднання в ключі VPNType, усередині словника, чий PayloadType — com.apple.vpn.managed. Значення — короткий токен, наприклад IKEv2, IPsec, L2TP або VPN, і все інше в корисному навантаженні інтерпретується згідно з цим токеном.

<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>VPNType</key>
<string>IKEv2</string>
<key>IKEv2</key>
<dict>
  <key>RemoteAddress</key>
  <string>vpn.head-office.example</string>
  <key>RemoteIdentifier</key>
  <string>ikev2.head-office.example</string>
</dict>

Цей фрагмент ілюстративний, а не встановлюваний: це один запис масиву корисного навантаження, позбавлений метаданих профілю й облікових даних, потрібних реальному розгортанню. Читайте його заради форми, а не змісту. Зверніть увагу й на те, що RemoteAddress і RemoteIdentifier — різні поля з різними завданнями, навіть коли розгортання дає їм однаковий рядок.

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

Власні типи потребують VPNSubType і застосунку-власника

Коли VPNType дорівнює VPN, корисне навантаження має також нести VPNSubType, який визначає плагін або постачальника Network Extension, що реалізує з'єднання. Саме цей ідентифікатор спрямовує з'єднання до конкретного клієнта, тому неправильний підтип дає профіль, який встановлюється і потім відмовляється запускатися.

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

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

Перелічіть, що Mac справді налаштував

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

scutil --nc list
scutil --nc show "Office VPN"

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

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

Тримайте збережені параметри окремо від живого сеансу

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

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

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