Прокси за отстраняване на грешки ослепява, когато се свърже корпоративният 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

Използвайте истинското име на услугата, а не догадка. Лаптоп с безжична мрежа и 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 и автоматичното откриване за услугата, после собствената обработка на прокси от приложението. Спрете на първото, което се различава от предположението ви.

Всеки случай тук е проблем с приоритета на конфигурацията. Нито един не е тунелът, който чупи инструмента ви.