Проксито за отстранување грешки ослепува кога ќе се поврзе корпоративниот 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 и автоматското откривање по услуга, потоа ракувањето со прокси во самата апликација. Запрете кај првото што се разликува од вашата претпоставка.

Секој случај овде е проблем со приоритет на конфигурацијата. Ниту еден не е тунелот што ја расипува вашата алатка.