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

Браузър на клон зад явно прокси отваря две връзки и те се провалят по различни причини. Първата е от браузъра към прокси слушателя, прехвърляна през 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: определете обхвата и планирайте резервния вариант

Решете какво се случва, когато проксито или тунелът е недостъпен, и кажете ясно кой трафик покрива този дизайн. Той пренася уеб достъп от клиенти, които спазват прокси настройката; не пренася поща, произволни протоколи на устройства или софтуер, който игнорира конфигурацията.

Проверете изискваната операция на браузъра и един изискван отказ по одобрен план, преди да разширите дизайна към повече клиенти.