Два 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-приложение их не примирит. Документация об управляемых профилях охватывает правила разделения, если вам нужна деталь политики, а не маршрутизации.