Браузер філії за явним проксі відкриває два з’єднання, і вони зазнають невдачі з різних причин. Перше — від браузера до прослуховувача проксі, яке проходить через 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: визначте обсяг і сплануйте резерв

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

Перевірте потрібну операцію браузера і одну потрібну відмову за затвердженим планом, перш ніж розширювати схему на більше клієнтів.

Схожі статті