Mac Mail, два облікові записи й одне правило VPN, яке не може їх розділити
Правило на рівні застосунку називає Mail, а не один із його записів. Розділіть застосунок, сервер і вхід, перш ніж вимагати тунель, що йде за робочою поштою.
Mail відкривається, робоча скринька синхронізується, а особиста починає виходити за межі часу. Або обидві синхронізуються, але робочий сервер відповідає лише поки піднято тунель, і Mail не знає, який запис який. Симптом завжди має одну форму: один застосунок, два записи й правило, яке ідентифікує застосунок. Виправлення починається з визнання, що застосунок — це контейнер, а не межа.
Тут задіяні три селектори, і вони не взаємозамінні. Один — це процес, що встановлює з'єднання, другий — хост, якого він досягає, а третій — ідентичність, яка використовується для входу через цей хост. Який із них ваша політика може назвати, та й є межа, яку ви справді можете збудувати.
Чому застосунок — неправильна одиниця
Mail — це один процес, що обслуговує кожен налаштований запис. Правило, написане проти застосунку, перехоплює всі його з'єднання, тож особистий запис успадковує робочий тунель і його маршрут за замовчуванням. Це може бути прийнятно, але це рішення, а не побічний ефект, який можна залишити неперевіреним.
Перевірте, на що користувач насправді скаржиться, перш ніж щось виправляти. Скринька, яка синхронізується, але не може надсилати, зазвичай указує на сервер надсилання, а не на вхідні, і обидва можуть бути за різними адресами в одному приватному діапазоні. Запитайте, у чому збій: у прийманні, надсиланні чи в обох. Відповідь визначає, яку кінцеву точку має покривати ваше правило, і економить один похід до адміністратора сервера.
Коли два записи використовують різні сервери
Якщо робоча пошта спілкується з хостом у корпоративному діапазоні, а особиста — з публічним провайдером, схема на основі призначення може виразити вимогу. Їй потрібні реальні адреси поштових серверів, DNS, що їх розв'язує, і будь-які кінцеві точки надсилання чи автентифікації, що йдуть із тією ж службою. Зберіть усі три перед написанням політики, бо правило, що покриває лише вхідні, зазнає невдачі при першому надсиланні.
Використовуйте адреси, а не частину після знака @. Домен у поштовій адресі не є заявою про маршрутизацію, і трактування його як такої дає правило, що спрацьовує для неправильного хоста або не спрацьовує ніколи. Підтвердьте фактичні кінцеві точки в налаштуваннях запису або в адміністратора.
Коли обидва записи ділять один сервер
Два записи на одній адресі хоста повністю знецінюють вибір за призначенням. Маршрут на цю адресу обслуговує кожного, хто підключається, і не може перевірити, яка скринька ввійде згодом. Переміщення маршруту переміщує шлях для обох записів, і це саме той результат, якого користувач прагнув уникнути.
У цей момент чесні варіанти — політика з урахуванням запису, якщо платформа й клієнт її підтримують, окремий схвалений поштовий клієнт для робочого запису, щоб межа застосунку стала реальною, або прийняття того, що обидва записи подорожують разом. Виберіть один усвідомлено і скажіть, який.
Запустити тунель — не те саме, що покрити його
Корисне навантаження App Layer VPN від Apple документує налаштування MailDomains: перелічені домени змушують Mail запускати VPN-з'єднання в підтримуваних керованих розгортаннях. Це корисна можливість, і вона вужча, ніж звучить. Вона запускає тунель, коли Mail спілкується з цими доменами; вона не описує кожен маршрут, кожен зв'язок застосунку чи те, що відбувається, поки тунель опущений.
Це також керована функція, а не прапорець для кожного запису в інтерфейсі Mail. Якщо розгортання не кероване, налаштування вам недоступне, і жодне редагування профілів його не створить.
Перевіряйте свіжою синхронізацією, а не кешованою скринькою
Приймальний тест — це свіжа синхронізація для кожного запису за передбаченою політикою плюс недоступний стан для захищеного. Кешована скринька нічого не доводить щодо наступного запиту, а значок підключеного VPN говорить лише про те, що якийсь тунель існує.
Передайте адміністратору кінцеві точки робочого запису й бажану поведінку для особистої пошти, потім запитайте, яка підтримувана політика з урахуванням запису, домену чи застосунку це реалізує. Спостереження за синхронізацією обох записів за кожної умови — єдиний доказ того, що спроєктована вами межа є межею, яку нав'язує машина.