Проксі для налагодження сліпне, коли підключається корпоративний VPN

У вашому проксі нічого не змінилося. Запис тунелю несе власні налаштування, керований PAC може повернутися, а деякі клієнти взагалі не читають системний проксі.

Інструмент запису працює весь ранок, тунель підключається — і він замовкає. Відключите — і він знову працює. Перша думка: VPN зламав проксі, але в конфігурації проксі насправді нічого не змінилося. Змінилося те, яку конфігурацію тепер читають програми: запис тунелю може нести власні налаштування проксі, керований профіль може знову ввімкнути автоматичну конфігурацію, а деякі середовища виконання читають лише частину того, що пропонує операційна система. Прочитайте значення для конкретного підключення, перш ніж чіпати глобальне.

Windows тримає проксі для кожного підключення

У властивостях Інтернету є два шари, які в діалозі виглядають однаково. Параметри локальної мережі застосовуються до звичайного локального підключення, а запис комутованого або VPN-підключення тримає власну копію в HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, збережену як двійкове значення. Запис відомих глобальних значень реєстру цю копію не оновлює.

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

Підтримуваний спосіб змінити один запис — API параметрів підключення WinINET: заповніть INTERNET_PER_CONN_OPTION_LIST назвою підключення, прапорцями, проксі-сервером і списком винятків, застосуйте його, а потім оновіть. Для швидкої перевірки відкрийте власний діалог налаштувань запису тунелю та порівняйте його панель проксі з панеллю локальної мережі; різниця зазвичай очевидна, щойно знаєш, куди дивитися.

Керований PAC може сам знову ввімкнутися

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

Перевірте і, якщо маєте повноваження, вимкніть ці два перемикачі для служби, що несе трафік:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

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

Спрямуйте інструмент на справжній висхідний вузол

Якщо сценарій містить корпоративний проксі, прочитайте його і введіть ту саму адресу як зовнішній проксі всередині інструмента запису. Тоді інструмент передає на справжній висхідний вузол, чого й чекає корпоративний проксі, і залишається в шляху запиту, замість воювати з політикою.

Це той крок, який утримує вас у налагодженні, а не в переконфігуруванні.

Запхніть проксі в тунель

Клієнт на основі OpenVPN може приймати параметри проксі, що діють після підняття тунелю, що зручно, коли маршрути належать клієнту:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

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

Деякі клієнти ніколи не читають системний проксі

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

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

Читайте конфігурацію, а не перемикач

Працюйте в такому порядку: власне значення проксі запису тунелю, стан PAC і автовиявлення для служби, потім обробка проксі самою програмою. Зупиніться на першому, що відрізняється від вашого припущення.

Кожен випадок тут — проблема пріоритету конфігурації. Жоден із них не є тунелем, що ламає ваш інструмент.

Схожі статті