VPN на запит на iPhone підключається до Wi-Fi офісу, а не до стільникової мережі

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

Список читається згори, і перемагає перший збіг

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

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

Запис відключення робить дві справи

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

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

Збережіть обидві умови у виключенні

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

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

Коли проба перемагає ім'я

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

Правила на основі домену — окрема форма: NEEvaluateConnectionRule зіставляє запитані домени й може підключатися, коли ім'я шукається. Його підстановчий знак приймається лише як найлівіша мітка, тому *.example.com дійсний, а example.*.com — ні. Якщо профіль не використовує ні умов інтерфейсу, ні проб доступності, перевірте, чи не використовує він натомість той тип правила.

Чим не керують правила на запит

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

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

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