Браузер филиала к прокси: два подключения, два маршрута

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

Шаг 1: запишите оба потока

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

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

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

Шаг 2: дайте браузеру путь к прослушивателю

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

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

Шаг 3: настройте браузер, а не только таблицу маршрутов

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

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

Шаг 4: докажите исходящее подключение прокси

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

Для HTTPS CONNECT открывает туннель к запрошенному пункту назначения. Обычная пересылка не передаёт прокси расшифрованную страницу, и отключение проверки сертификата ради импровизированного контроля не является решением.

Шаг 5: различайте четыре неисправности

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

Сообщайте о наблюдаемой границе, а не о выводе, что VPN отказал.

Шаг 6: определите область и спланируйте резерв

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

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