Разделённый туннель: почему ссылка открывается вне настроенного вами VPN
Маршрутизация следует за процессом, который открывает сокет, а не за приложением, показавшим вам ссылку. Докажите, какая программа подключается, прежде чем расширять исключения.
Проведение приложения через туннель не переносит его маршрутизацию на всё, что это приложение запускает, хотя интерфейс намекает на обратное. Ссылка передаёт запрос другой программе, та программа открывает собственный сокет, и платформа применяет правила к новому процессу, а не к тому, который показал текст. Именно этот второй процесс и видит политика туннеля, и это не тот, который вы настроили.
Поэтому включённое приложение может открыть браузер, находящийся вне туннеля. Исключённый браузер может вернуть работу приложению, находящемуся внутри него. Оба направления этого сюрприза — обычное поведение.
Та часть рабочего процесса, которую никто не настроил
Политика для приложения пишется относительно идентичности исполняемого файла или пакета, и каждое соединение оценивается в момент его создания. Браузер, просмотрщик документов, медиаплеер и системный лист общего доступа несут каждый свою идентичность, и каждый получает свой вердикт. Глубокая ссылка несёт данные, а не политику.
Поэтому наблюдение кажется произвольным: один и тот же щелчок маршрутизируется двумя способами в зависимости от того, какой обработчик ответит. Почтовый клиент в туннеле открывает ссылку в браузере, живущем вне туннеля, и страница загружается с вашего домашнего адреса. Браузер вне туннеля открывает документ в просмотрщике, живущем внутри него, и файл приходит через выход. Ни один из двух результатов не является неисправностью клиента.
Уже работающий обработчик всё ухудшает. Если браузер уже открыт, ссылка становится сообщением существующему процессу, и этот процесс сохраняет маршрутизацию, которая была у него при запуске. Закрытие и повторное открытие обработчика меняет результат, и именно поэтому проблема никогда не воспроизводится по требованию.
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
Какой процесс на самом деле установил соединение
Измеряйте принимающую сторону вместо того, чтобы рассуждать о ней. Оставьте туннель включённым, щёлкните безобидную ссылку и посмотрите на сокеты, которые держит новая программа.
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
Первая команда называет процесс за каждым установленным сокетом в Linux, а вторая делает то же в Windows, разрешая идентификатор процесса-владельца. Сравните имя процесса с именами в вашей политике. Если имя — это браузер, а браузер исключён, щелчок покинул туннель по замыслу, а не из-за неисправности. Сопоставление правила политики с живым сокетом — это весь метод.
Повторите проверку при уже работающем обработчике, а затем при закрытом. Два результата могут различаться, и это различие объясняет большинство эпизодических отчётов о ссылках, уходящих из туннеля.
Покрытие — свойство рабочего процесса
Если задача должна оставаться в туннеле от начала до конца, каждый компонент, до которого она может дотянуться, должен быть внутри политики: средство запуска, обработчик, просмотрщик и любой посредник, который платформа вставляет между ними. Более широкое покрытие часто и есть честный ответ, и оно дешевле аудита каждой цели общего доступа.
Исключать системного посредника, чтобы починить одно приложение, — распространённая ошибка. Посредники являются общими, поэтому исключение распространяется на каждое другое приложение, использующее тот же путь, обычно без того, чтобы кто-то это заметил до отчёта через недели. Прочитайте, что ещё зависит от компонента, прежде чем исключать его.
Держите идентичность отдельно от маршрутизации. Ссылка может нести маркер сеанса или идентификатор учётной записи независимо от того, какой выход получает запрос. Правильно маршрутизированный щелчок всё равно может точно сообщить пункту назначения, кто по нему перешёл.
Документируйте рабочий процесс, а не первый флажок. Когда задача охватывает четыре программы, именно схема с четырьмя программами предсказывает, куда пойдёт трафик, а настройка одного приложения — лишь одна её строка.