Два VPN на одному телефоні: обирайте схему, а не кількість застосунків

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

Три схеми, одне питання

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

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

Перемикання в одному контексті користувача

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

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

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

Розділення за профілем

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

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

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

Ланцюг, де порядок і є рішенням

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

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

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

Найважливіше: ланцюг не зливає дві приватні мережі. Маршрути, перекривані префікси, розв'язання DNS і правила доступу залишаються окремими рішеннями, і маршрутизатор, що несе один VPN, поки телефон несе інший, не дає телефону обидва адресні простори.

Перевірте схему, перш ніж її налагоджувати

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

adb shell ip -br addr
adb shell ip route get 10.20.0.8
adb shell dumpsys connectivity | grep -i vpn

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