Робочий VPN в ОАЕ: що підтвердити насамперед

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

Що насправді охоплює задокументований сценарій використання

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

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

Прив’яжіть роботу до конкретного шлюзу

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

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

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

Що профіль робить з рештою вашого трафіку

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

ip -4 route
ip -4 route get 10.20.4.10
nmcli connection show --active

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

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

Підготуйте шлях відмови до вильоту

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

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

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

Зберігайте запис і перевіряйте його знову

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

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