Исключения VPN для отдельных приложений ломаются, когда общая служба загружает данные
Окно, которое вы исключили, не всегда является процессом, открывающим соединение. Найдите настоящего заявителя, прежде чем добавлять помощник в правило VPN для отдельного приложения.
Вы исключаете одно приложение из VPN, а нужная ему загрузка по-прежнему не работает, или, что хуже, начинает работать, и что-то постороннее останавливается. Видимое окно не обязательно является процессом, который открывает каждое соединение: приложение может передать работу помощнику, службе передачи в фоновом режиме или совсем другому пакету. Поэтому правилу для отдельного приложения нужна настоящая модель идентичности платформы, а не знакомое имя файла запуска. Приведённые ниже проверки начинаются с наблюдения и возвращаются к тому, кто на самом деле отправил запрос.
В этих заявках обычно две вещи ломаются вместе: исключается неверный компонент, а исключение потом никогда не сужается.
Найдите процесс, а не окно
Воспроизведите неудачную операцию и определите процесс или пакет, которому принадлежит соединение, пока она выполняется. В Windows это другой вопрос, чем то, какое окно в фокусе, потому что передачей в фоне может управлять служба, работающая под собственной идентичностью. В Linux и macOS то же разделение проявляется как вспомогательные процессы и системные демоны.
Запишите три детали: идентичность исполняемого файла или пакета, адрес назначения, с которым он связывался, и момент в рабочем процессе, когда это произошло. Загрузка, которая не удаётся в начале, часто является получением метаданных другим компонентом, а не загрузкой, которая не удаётся на середине. Одного этого различия обычно достаточно, чтобы выбрать правильную идентичность до того, как трогать правило. Если идентичность окажется службой, а не приложением, этот единственный факт меняет всё правило, поэтому установите его первым.
Если вы не можете наблюдать процесс, потому что операция слишком коротка, повторите её с большим объёмом данных или более медленным назначением. Цель — одно воспроизводимое наблюдение, а не теория о том, какой помощник задействован.
Относитесь к DNS как к отдельному пути
Системное разрешение имён может вообще не следовать за исключённым приложением, поэтому исключённый браузер всё ещё может терпеть неудачу на частном имени хоста, хотя его трафик корректно находится вне туннеля. Браузер был исключён; распознаватель — нет.
Проверьте, что платформа делает с DNS, когда действует правило для отдельного приложения, и проверьте это отдельно от запроса HTTP. Если распознаватель является общей службой, он обслуживает каждое приложение на устройстве, поэтому рассматриваемое исключение имеет гораздо более широкую аудиторию, чем проверенное.
Запишите, какой распознаватель ответил и через какой интерфейс. Это единственное наблюдение решает значительную часть отчётов «приложение исключено, но имя не разрешается», поэтому сохраняйте его вместе с заявкой.
Не расширяйте общий помощник
Общая служба выполняет работу для нескольких приложений, поэтому её исключение ради починки одного рабочего процесса меняет и посторонний трафик. Background Intelligent Transfer Service в Windows — хороший пример такой формы: это инфраструктура, которой могут пользоваться многие приложения, и её идентичность не совпадает с идентичностью приложения, запросившего передачу.
Проверьте поддерживаемую клиентом модель правил и требования организации, прежде чем добавлять это исключение. Спросите, что ещё использует компонент, и можно ли выразить правило, которое вы собираетесь написать, в отношении адресов назначения, а не общего процесса.
Если требование вообще нельзя выразить как границу приложения, политика на основе адресов назначения или другой утверждённый проект могут быть понятнее и безопаснее, чем растущий список исключений для помощников.
Проверяйте весь рабочий процесс, а не неудачный шаг
После поддерживаемого изменения выполните намеченную задачу с новым запросом от начала до конца. Затем выполните другой рабочий процесс, использующий общий компонент, потому что именно там широкий обход заявляет о себе. Исправление, которое чинит первый и молча ломает второй, не является исправлением. Сохраняйте оба результата в заявке и явно назовите второй рабочий процесс, чтобы проверяющий мог его повторить.
Держите тест небольшим и повторяемым: то же назначение, та же учётная запись, те же условия. Если второй рабочий процесс не документирован, спросите его владельца, от чего он зависит, прежде чем решать, что изменение безопасно.
Оставьте причину, а не список имён
Задокументируйте компонент, рабочий процесс, которому он служит, и причину его исключения. Список имён помощников без привязанной цели становится неподдерживаемым за два цикла выпуска, и следующий инженер удаляет неверную запись, пока наводит порядок.
Одной строки на каждое исключение достаточно: что ломается без него, кому принадлежит этот рабочий процесс и когда он проверялся в последний раз. Эти три поля превращают загадочный список в политику, которую кто-то может защитить.