Վրիպազերծման պրոքսին կուրանում է, երբ միանում է կորպորատիվ VPN-ը

Որսիչ գործիքը աշխատում է ամբողջ առավոտ, թունելը միանում է, և այն լռում է։ Անջատեք, և այն նորից սկսում է։ Առաջին միտքն այն է, թե VPN-ը կոտրել է պրոքսին, բայց պրոքսիի կարգավորումներում իրականում ոչինչ չի փոխվել։ Փոխվել է այն, թե որ կարգավորումներն են հիմա կարդում հավելվածները. թունելի գրառումը կարող է կրել իր պրոքսիի կարգավորումները, կառավարվող պրոֆիլը կարող է նորից միացնել ավտոմատ կարգավորումը, և որոշ կատարողական միջավայրեր կարդում են միայն այն, ինչ առաջարկում է օպերացիոն համակարգի մի մասը։ Կարդացեք մեկ կապի արժեքը նախքան գլոբալին դիպչելը։

Windows-ը պրոքսի է պահում յուրաքանչյուր կապի համար

Ինտերնետի ընտրանքներում կա երկու շերտ, որոնք երկխոսության մեջ նույնն են թվում։ Տեղական ցանցի կարգավորումները վերաբերում են սովորական տեղական կապին, մինչդեռ հավաքման կամ VPN-ի գրառումը պահում է իր պատճենը HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections-ի ներքո՝ որպես երկուական արժեք։ Հայտնի գլոբալ ռեեստրի արժեքները գրելը չի թարմացնում այդ պատճենը։

Հենց այսպես է գործիքը ճիշտ աշխատում միանալուց առաջ և սխալ՝ հետո, առանց իր կարգավորումներում տեսանելի փոփոխության։ Երկխոսությունը, որին նայում էիք, տեղական ցանցի վահանակն էր։ Այն ճիշտ էր և անտեղի էր։ Այն գրառումը, որն իրականում օգտագործում էր Windows-ը, թունելի համար ստեղծվածն էր։

Մեկ գրառում փոխելու աջակցվող եղանակը WinINET միացման ընտրանքների API-ն է. լրացրեք 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-ի և ավտոմատ հայտնաբերման վիճակը, ապա հավելվածի սեփական պրոքսիի մշակումը։ Կանգ առեք առաջինի վրա, որը տարբերվում է ձեր ենթադրությունից։

Այստեղ յուրաքանչյուր դեպք կարգավորման առաջնահերթության խնդիր է։ Դրանցից ոչ մեկը թունելը չէ, որ կոտրում է ձեր գործիքը։