Отладочный прокси слепнет, когда подключается корпоративный VPN

Инструмент записи работает всё утро, туннель подключается — и он замолкает. Отключаете — и он снова работает. Первая мысль: 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 и автообнаружения для службы, затем обработка прокси самим приложением. Остановитесь на первом, которое отличается от вашего предположения.

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