Ваш скрипт запускає VPN, але не готує його

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

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

З чим насправді розмовляє команда запуску

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

Тому збій з'являється на новому обладнанні, а не на ноутбуці адміністратора. Ноутбук підготували місяці тому, і людина, яка це робила, згодом про це забула. Уявіть команду запуску як дверний дзвінок, до якого хтось протягнув дроти минулого кварталу. Натиснути на нього — не те саме, що прокласти проводку.

Три власники конфігурації VPN

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

Власна особиста конфігурація VPN створюється через Network Extension API від Apple, який охоплює вбудовані протоколи IPsec і IKEv2. Це інтерфейс застосунку з кроком збереження й схваленням користувача, а не команда оболонки, яка мовчки створює будь-який тип тунелю, який постачає виробник.

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

Власна підготовка має збереження й схвалення

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

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

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

Що може припускати повторювана команда запуску

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

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

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

Дві перевірки приймання

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

Друга перевірка — сеанс: підключіться, досягніть дозволеного ресурсу й чисто відключіться. Тепер кожен збій має власника, і це практична користь від розділення двох робіт. Відсутній профіль — проблема доставки, помилка збереження — проблема схвалення, відхилений вхід — проблема автентифікації, а тайм-аут після успішного запуску — рівень сеансу. Жоден із них не «скрипт зламаний».