PAC Request Policy для согласованной маршрутизации

Proxy Auto-Config, обычно сокращенно PAC, задает браузеру политику выбора сетевого маршрута. Решение принимается в сетевом слое браузера, поэтому одна политика может охватывать навигацию, перенаправления, подресурсы и запросы, которыми управляет сам браузер, и не зависит от фреймворка для работы со страницами.

Такое расположение полезно, когда развертывание использует несколько утвержденных прокси-маршрутов. Региональная навигация, тестирование внутренних приложений, проверка медиа и нагрузки с несколькими контекстами могут требовать разных семейств маршрутов. PAC-политика держит эти решения рядом с профилем браузера и конфигурацией запуска.

BotBrowser поддерживает стандартную PAC-маршрутизацию через --proxy-pac-url и, для утвержденных корпоративных профилей, дополнительный callback запросов в том же PAC-скрипте. Стандартный PAC остается моделью по умолчанию. Callback является необязательным слоем, который помогает авторизованным командам сохранять единообразную обработку запросов, пока PAC-источник, перечень прокси и профиль проверяются вместе.

TL;DR

• Оставляйте PAC-маршрутизацию в сетевом слое браузера и делайте FindProxyForURL(url, host) проверяемым.
• Записывайте proxy, direct или blocked и храните policyVersion для отката.
• BotBrowser применяет утвержденные возможности PAC, но не исправляет прокси и не утверждает целевой сервер.

Contents

• Почему маршрутизацией должен управлять браузер
• Операционная модель и callback запросов
• Подходящие сценарии PAC Request Policy
• Защита развертывания и проверка по результату
• Ответственность, развертывание и записи
• Восстановление и сопровождение
• Practical conclusion

Почему маршрутизацией должен управлять браузер

Сохраняйте FindProxyForURL(url, host) и возврат DIRECT в записи политики.

Для простого сеанса статического прокси часто достаточно. Он становится менее подходящим, когда одному рабочему процессу браузера нужно несколько утвержденных путей. Перенос выбора маршрута в обработчики фреймворка может также привести к разному поведению Playwright, Puppeteer, чистого CDP и трафика, которым управляет браузер, а перехват на уровне автоматизации в некоторых процессах может нарушать непрерывность соединений и потоков HTTP/2.

PAC дает браузеру единую политику маршрутизации. Код автоматизации управляет страницей, а выбор сетевого пути остается за браузером. Поскольку политика не привязана к фреймворку, одна и та же политика может обслуживать разные средства автоматизации. Такое разделение упрощает проверку развертывания, потому что у профиля, перечня прокси и политики маршрутизации четко определены обязанности. О том, как распределяется ответственность за каждый сетевой уровень в крупных развертываниях, см. Сетевые границы корпоративного браузера: ответственность.

Подход также помогает сохранять согласованность с точки зрения приватности. Профиль браузера может задавать регион, язык, часовой пояс и семейство устройств, но эти настройки теряют смысл, если трафик идет по несвязанному сетевому пути. Когда политика маршрутов находится рядом с профилем, уменьшается расхождение конфигурации между настройками профиля и утвержденным выходом.

Когда достаточно статического прокси

PAC нужен не каждому развертыванию. Выбирайте статический прокси, когда весь трафик должен идти по одному маршруту и нет политики по классам запросов, которую нужно поддерживать. Контексту с единственным маршрутом PAC не нужен, а меньшая конфигурация проще в эксплуатации и содержит меньше подвижных частей.

Используйте PAC, когда выбор маршрута действительно является требованием на уровне браузера. Не добавляйте его только ради копирования логики фреймворка, у которой уже есть единый стабильный маршрут. Политика должна снижать операционную сложность, а не переносить ту же сложность в другой файл.

Операционная модель и callback запросов

Сопровождаемое развертывание разделяет четыре зоны ответственности:

1. Профиль браузера определяет предполагаемые настройки браузера.
2. Перечень прокси определяет утвержденные сетевые пути.
3. PAC-политика выбирает путь для каждого значимого класса запросов.
4. Рабочий процесс автоматизации выполняет авторизованную задачу в браузере.

Такая схема не позволяет копировать правила маршрутизации в каждый скрипт. Она также дает службам поддержки и приватности постоянное место для проверки изменения маршрута без чтения кода автоматизации страниц. Используйте понятные названия политик и делайте каждую политику сфокусированной на одной цели развертывания, потому что задача региональной проверки, тест внутреннего приложения и медиапроцесс не должны делить одну большую политику только потому, что работают на одном узле. Небольшие политики проще проверять, версионировать и откатывать.

Стандартные PAC-скрипты продолжают использовать FindProxyForURL(url, host) для обычного выбора прокси. Для утвержденных профилей ENT Tier3 тот же доверенный PAC-скрипт может также определять BotBrowserFindProxyForRequest, callback BotBrowser, который получает URL запроса, хост, метод, заголовки и состояние тела. Callback не заменяет стандартный PAC. Если он возвращает CONTINUE или не возвращает допустимого результата, маршрутизация возвращается к стандартной функции. Callback может выполнять следующие действия:

• Продолжить запрос и сохранить стандартный PAC-маршрут.
• Заблокировать запрос.
• Записать короткую помеченную запись захвата по утвержденному абсолютному пути.
• Направить только текущий запрос по другому стандартному PAC-результату, например DIRECT, HTTPS или SOCKS5.
• Завершить запрос контролируемым синтетическим ответом.

Результаты можно объединять точкой с запятой. Запись захвата выполняется первой. Затем контролируемый ответ завершает запрос и имеет приоритет над блокировкой и маршрутизацией, а без ответа блокировка имеет приоритет над маршрутом. Некорректный, слишком большой, небезопасный или неподдерживаемый вход для ответа приводит к безопасному отказу и никогда не отправляется ни целевому серверу, ни прокси.

Callback доступен только для утвержденных профилей и явно заданных PAC-источников: PAC-файлов file:, PAC URL data:, loopback HTTP(S) PAC-сервисов и удаленных HTTP(S) PAC-сервисов, которые контролирует ваша команда. Автоопределение PAC и WPAD остаются допустимыми для стандартной PAC-маршрутизации, но callback не получают. Для локальных узлов предпочитайте источники file: или loopback, а для удаленного источника используйте HTTPS.

Для контролируемых ответов действует более узкая политика источников, чем для самого callback. Они ограничены утвержденными профилями, которые загружают PAC-источник file: или data:. PAC-источник по HTTP(S) по-прежнему может маршрутизировать, захватывать и блокировать запросы, но не может возвращать контролируемый ответ. Администраторам следует держать политику под теми же средствами контроля доступа, что и пакет профиля, и отклонять непроверенные пути доставки.

Контролируемые ответы подходят для конечных точек и тестовых ресурсов, которыми владеет само развертывание, например для результата проверки готовности, стабильного тестового ресурса или детерминированного ответа в авторизованном процессе контроля качества. Держите собственные тестовые ресурсы отдельно от трафика к реальным серверам. Они должны поддерживать воспроизводимое тестирование и эксплуатационные проверки, а не заменять обычную навигацию к сторонним сервисам.

Подходящие сценарии PAC Request Policy

Региональная согласованность маршрутов

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

Внутренние и внешние пути приложений

Корпоративный тест может сочетать внутренний сервис с общедоступными веб-зависимостями. Небольшая PAC-политика может оставлять внутренний трафик на предусмотренном приватном пути, а внешний направлять через утвержденный прокси-маршрут.

Многоконтекстные рабочие узлы

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

Воспроизводимый контроль качества

Собственные тестовые ресурсы позволяют убрать лишнюю сетевую изменчивость на выбранном тестовом пути. С утвержденным локальным источником политики контролируемые ответы могут поддерживать именно этот узкий сценарий, а остальная часть страницы работает по стандартной сетевой логике браузера.

Защита развертывания и проверка по результату

Записывайте proxy, direct и blocked как три ожидаемых результата для каждого URL.

Рассматривайте PAC-источник, профиль браузера и перечень прокси как один проверенный релизный набор.

• Ограничьте круг лиц, которые могут изменять источник политики.
• Явно указывайте утвержденную ссылку на политику в конфигурации развертывания.
• Используйте систему контроля версий для стабильных файлов политик.
• Проверяйте принадлежность маршрутов до смены учетных данных прокси или регионов.
• Запускайте новый сеанс браузера при изменении конфигурации задания.
• Держите контролируемые тестовые ресурсы под теми же средствами контроля доступа, что и тестовый процесс.
• Предпочитайте небольшой список разрешенных классов запросов широкой универсальной политике.

Доставка удаленной политики требует той же проверки транспорта и доступа, что и другая производственная конфигурация. Более широкую доступность источников для стандартной PAC-маршрутизации не следует путать с разрешением использовать контролируемые ответы.

Проверка должна подтверждать результат развертывания, не собирая лишних данных страниц. Начните с плана маршрутов. Зафиксируйте, какие классы запросов должны идти по каждому утвержденному маршруту, а какие должны оставаться на стандартном поведении PAC. Запустите обычный авторизованный рабочий процесс и сравните наблюдаемый сетевой результат с этим планом.

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

Для собственного контролируемого тестового ресурса подтверждайте ожидаемое поведение приложения обычными проверками приложения. Рассматривайте вместе идентификатор действующей политики, назначение профиля, запись доступа и результат в браузере. Эти наблюдения показывают, соответствует ли развертывание утвержденному плану маршрутов. Приложите результат к той же релизной записи, которая используется для решений о развертывании и откате.

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

Ответственность, развертывание и записи

Храните policyVersion, effectiveAt, owner и rollbackTarget при каждом развертывании.

Политика маршрутизации влияет на трафик браузера раньше, чем автоматизация страниц оценит результат. Назначьте каждой политике ответственного, который понимает управляемые ею пути приложений. Он должен уметь объяснить, зачем существует каждый класс маршрутов, какие семейства профилей его используют и какая команда утверждает изменения. Эксплуатация прокси может оставаться отдельной зоной ответственности, но границу между выбором маршрута и его доступностью необходимо зафиксировать письменно.

Проверяйте политику как элемент производственной конфигурации. Полезная запись проверки содержит название политики, ее ревизию, затронутые группы развертывания, назначенные ей семейства профилей и ожидаемый результат для каждого утвержденного класса маршрутов. В ней также должны быть указаны ревизия для отката и лицо, отвечающее за это решение. Этого контекста достаточно, чтобы оператор мог действовать, не копируя политику в тикет и не раскрывая сведения, которым не место в операционной записи.

Избегайте неформального обмена политиками между заданиями. Политика, работающая для одного приложения, может содержать допущения о регионах, закрытых сервисах или принадлежности прокси, которые не применимы в другом месте. Создавайте отдельную проверенную политику, когда цель меняется. Дополнительная запись обходится дешевле, чем расследование необъяснимого маршрута после того, как два развертывания эволюционировали независимо.

Учетные данные не следует встраивать в текст политики, который копируется в тикеты или в автоматизацию браузера. Используйте обычный для развертывания путь управления секретами и ограничьте доступ учетными записями служб, выполняющих утвержденное задание. Если платформа позволяет, меняйте учетные данные независимо от логики маршрутизации, а затем выполняйте те же авторизованные проверки приложения, что и при обычном релизе. Более подробно эта практика описана в руководстве по аутентификации прокси и гигиене учетных данных.

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

Сравнивайте поэтапно развернутую группу с неизменной группой за тот же период. Полезные наблюдения: успешное завершение приложения, статус запуска и завершения браузера, доступность прокси, результат по семейству маршрутов и число заданий, возвращенных в очередь. Сохраняйте сопоставимыми набор страниц и состав заданий. Если одновременно меняется несколько входных данных, сравнение не покажет, помогла ли политика или просто совпала с другой нагрузкой.

Расширяйте развертывание по группам, а не меняйте все рабочие узлы сразу. Приостанавливайте развертывание, когда результат приложения, стабильность браузера или запись о принадлежности маршрутов перестают соответствовать плану релиза. Прежде чем пробовать второе изменение, восстановите предыдущую проверенную политику. Так откат остается предсказуемым, а для следующего сравнения сохраняется понятная базовая линия.

Долгоживущие рабочие узлы должны получать изменения политики по тому же жизненному циклу, что и обновления профиля и браузера. Завершите или остановите назначенную работу по обычным правилам остановки приложения, затем начните новый сеанс браузера с новым релизным набором. Если смешивать старый сеанс браузера с новым назначением политики, записи поддержки становится трудно интерпретировать.

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

Применяйте к этим записям обычный график хранения, принятый в организации. Краткосрочной записи тестовой среды может хватить окна релиза, а регулируемому производственному процессу может потребоваться более длинный журнал аудита. Ответственный за развертывание должен определить срок до запуска и зафиксировать, кто может читать или экспортировать запись. Не допускайте, чтобы журналы браузера превращались в неуправляемую копию сетевой истории. Записи захвата, которые пишет callback, подчиняются тому же правилу, поэтому их путь, метка и срок хранения должны входить в проверенную политику.

Проверки доступа должны охватывать и редактирование политики, и ее назначение. Тот, кто не может изменить текст политики, все же может привязать существующую политику к неверной группе развертывания. Проверяйте эти права вместе. Удаляйте назначения, у которых больше нет активного владельца, и выводите из обращения ревизии политик, недоступные для отката.

Восстановление и сопровождение

Используйте lastKnownGood, errorCode и retryAt, чтобы отделить восстановление от нового развертывания.

Когда авторизованный процесс дает неожиданный результат по маршруту, прекратите отправлять новую работу в затронутую группу развертывания. Сохраните доступными последнюю успешную ревизию политики и релизную запись. Убедитесь, что назначенное семейство профилей, версия браузера, перечень прокси и ревизия политики соответствуют утвержденному изменению. Это первое сравнение часто выявляет дрейф конфигурации без исследования на уровне страниц.

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

Во время восстановления меняйте по одному компоненту релиза за раз. Если одновременно с возвратом предыдущей политики менять пакет профиля, версию браузера и регион прокси, базовая линия будет потеряна. Сначала вернитесь к последнему проверенному набору. Когда обычные проверки приложения пройдут, вводите следующее изменение через поэтапное развертывание.

Запись об инциденте должна содержать видимый пользователю результат, затронутые группы развертывания, последнюю известную исправную ревизию, корректирующее действие и результат проверки релиза. Описывайте наблюдаемое поведение, а не храните данные страниц по каждому запросу. Такая более узкая запись поддерживает подотчетность и уважает границы приватности сеанса просмотра.

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

Проверяйте, что ссылки на документацию указывают на актуальный выпуск продукта, а шаблоны развертывания ссылаются на действующую ревизию политики. Тестируйте материалы для отката, пока они еще действительны. Ревизия, существующая только в старом тикете, не является надежным вариантом восстановления, если ее перечень прокси или назначение профиля уже выведены из эксплуатации.

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

Частые ошибки конфигурации

• Считать все источники политики равноценными. Требования к источнику зависят от возможности, поэтому выбирайте документированный утвержденный источник для нужного процесса и пересматривайте этот выбор при изменении браузера или пакета политик.
• Распределять принадлежность маршрутизации между слоями. Когда маршруты выбирают PAC, обработчики фреймворка и внешний сервис пересылки, итоговый путь трудно объяснить, поэтому назначьте одного владельца для каждого решения.
• Повторно использовать политику для несвязанных профилей. Политика, созданная для одного региона или семейства браузеров, может не подходить другому, поэтому пересматривайте ее при смене семейства профиля, региона прокси или роли узла.
• Использовать контролируемые ответы для реального веб-трафика. Они предназначены для собственных тестовых ресурсов и авторизованных тестовых путей, а обычный трафик к серверам назначения должен идти через стандартную сетевую логику браузера.

Что поддерживает BotBrowser и где проходит граница

BotBrowser поддерживает стандартный --proxy-pac-url и callback для утвержденных ENT Tier3, но не может сделать прокси доступным или утвердить политику организации.

В утвержденных профилях ENT Tier3 callback принимает URL, метод и состояние заголовков, после чего возвращает продолжение, блокировку или маршрут. Ограничивайте ответы из источников file: и data: собственными тестовыми ресурсами; BotBrowser не утверждает политику организации и не проверяет владельца целевого сервера.

Поддерживаемые источники, возвращаемые значения и эксплуатационные требования описаны в документации по callback запросов PAC, а лежащие в основе варианты прокси разобраны в руководстве по настройке прокси. Статья о настройке прокси объясняет, как эти варианты сочетаются.

Открытые источники

• MDN: файл Proxy Auto-Configuration (PAC)
• Документация BotBrowser PAC-Like Request Callback

Practical conclusion

Храните в одной записи источник PAC, список утвержденных прокси, профиль и ревизию для отката. Проверяйте результат маршрута до выпуска рабочего процесса в производственный трафик.