Два VPN на iPhone одночасно: який із них несе ваш трафік?

Дві програми VPN обидві показують Connected, і припускається, що трафік тепер іде через обидві, одна всередині іншої. Зазвичай це не так. У iOS є певна модель співіснування, і це не ланцюжок. Один клас конфігурації обмежений одним увімкненим екземпляром, інший може працювати поруч, а пріоритет маршрутів вирішує конфлікти. Два ввімкнені перемикачі — не два стрибки. Модель задокументована, тобто шлях можна передбачити, а не вгадувати зі значків.

Міф: два підключені VPN — це ланцюжок

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

Якщо вам потрібне вкладення, проєктуйте його як вкладення. Не виводьте його з двох індикаторів з’єднання. Ця відмінність економить багато налагодження.

Документована модель за цим міфом

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

Тут Personal VPN — це термін API для вбудованої реалізації IPsec або IKEv2, якою керує NEVPNManager. NETunnelProviderManager — це модель постачальника тунелю. Споживча програма може використовувати модель постачальника, тому назва продукту зі словом personal його не класифікує.

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

Міф: особистий VPN отримує трафік перегляду

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

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

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

Пріоритет маршрутів із робочим профілем розділеного тунелю

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

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

Запишіть два потоки й перевірте кожен

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

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