Два облікові записи Mac не розділяють трафік VPN

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

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

Почніть із трафіку, а не зі списку облікових записів

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

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

Канал профілю та охоплення трафіку — різні речі

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

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

Гостьова система — справжня межа зі справжніми обмеженнями

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

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

Проксі вужчий за обліковий запис користувача

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

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

Доведіть межу двома тестами

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

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