Обработка сбоя DNS внутри правила PAC

Выделите неудачному PAC-запросу DNS собственную ветвь политики вместо того, чтобы считать его подтверждённым адресом вне локальной сети.

Неудачный запрос не доказывает, что назначение находится вне вашей частной сети. Он доказывает лишь то, что это вычисление PAC не получило нужный адрес.

Эта разница важна, когда dnsResolve() передаёт значение правилу isInNet(). Реализация PAC в Chromium возвращает null, если разрешение не удалось. Не стройте ветвь ошибки на воспоминании о том, что результат всегда пустая строка.

function FindProxyForURL(url, host) {
    var address = dnsResolve(host);
    if (!address) {
        return "PROXY proxy.example:8080";
    }
    if (isInNet(address, "10.40.0.0", "255.255.0.0")) {
        return "DIRECT";
    }
    return "PROXY proxy.example:8080";
}

Этот пример отправляет неразрешённые имена через прокси. Это выбор политики, а не универсально безопасное значение по умолчанию. Он может быть полезен, когда у прокси есть резолвер или представление о сети, которых нет у клиента. Сеть, требующая локального разрешения, нуждается в другом явном результате.

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

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

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

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