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