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

Два разговора, два удостоверения

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

HTTP 407 это сигнал о том, что клиент должен аутентифицироваться для запроса прокси, передаваемого в Proxy-Authenticate, с ответом, ожидаемым в Proxy-Authorization. Это не логин целевого веб-сайта, и их смешивание является наиболее распространенной причиной путаницы.

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

Проверьте 1: какой прокси на самом деле выбран

Начните с выбора, потому что браузер, который игнорирует настройки вашего прокси-сервера, вообще никогда не справится с этой задачей. В Chrome это флаг --proxy-server=proxy.example:3128 с --proxy-bypass-list для исключений, а Selenium предоставляет то же самое через параметры браузера. Файл PAC — это другой механизм со своими режимами сбоя.

Затем подтвердите действие изнутри среды работающего браузера, а не из вашей оболочки. Независимым зондом с тем же прокси-сервером является curl -x http://proxy.example:3128 -v https://example.com, и его подробный вывод показывает, удалось ли CONNECT, какой Proxy-Authenticate вернулся и был ли возвращен 407. Если Curl получает 407 и браузер зависает, проблема заключается в пути учетных данных, а не в сети. Если закручивание завершается успешно, а браузер — нет, значит, браузер не использует тот прокси-сервер, который, по вашему мнению, используется.

Проверьте 2: кто отвечает на 407

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

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

Проверьте 3: путь к учетным данным

Именно учетные данные — это то место, где происходит сбой большинства автоматических установок. Selenium может установить хост и порт прокси-сервера, но аутентификация прокси-сервера HTTP не является переносимой частью этой конфигурации, а учетные данные в URL-адресе прокси не являются механизмом, на который можно положиться в разных браузерах и версиях драйверов. Поддерживаемые параметры — это те, которые являются вашими фактическими документами стека: расширение браузера, которое отвечает на запрос, локальный прокси-сервер пересылки, который добавляет заголовок и доступен только из задания, или прокси-сервер, который аутентифицирует рабочую нагрузку другими способами. Выберите один сознательно и сравните его с точными версиями браузера, драйвера и Selenium, которые вы будете использовать.

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

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

Проверьте 4: собственный сетевой контекст процесса браузера

Это проверка, которую люди пропускают. Браузер, запущенный работником, контейнером или удаленным узлом Selenium Grid, использует сеть этой среды, поэтому VPN-соединение вашего ноутбука и переменные прокси-сервера вашей оболочки описывают путь, который браузер может никогда не коснуться.

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

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

Похожие статьи