VPN-ը աշխատում է, բայց մեկ հավելված ինտերնետ չունի՞ Ստուգեք դրա փրոքսին

Ձեր թունելը բարձրացված է, կարգավիճակի էջը ցույց է տալիս առողջ ձեռքսեղմում, բայց մեկ հավելված դեռ ոչինչ չի բեռնում։ Այդ հավելվածը, հավանաբար, դեռ իր հարցումներն ուղարկում է ավելի հին միջնորդի՝ համակարգի փրոքսի, ընդլայնման, սարքերի կառավարման կողմից մղվող կոնֆիգուրացիայի ֆայլի կամ փրոքսի փոփոխականի, որը կարդում է միայն իր իսկ գործընթացը։ VPN սերվերը փոխելը չի դիպչի այդ կարգավորմանը, և դա բացատրում է այն օրինաչափությունը, երբ նույն մեքենայից այլ հավելվածներ աշխատում են։ Աշխատեք ձախողվող հավելվածից դեպի դուրս և թունելը հանգիստ թողեք, մինչև փրոքսիի հարցը լուծվի։

Փրոքսիի կարգավորումը որ շերտինն է

Չորս տեղ կարող են հավակնել իշխանությանը հավելվածի հարցումների վրա, և սովորաբար հաղթում է ամենանեղը։ Օպերացիոն համակարգը պահում է գլոբալ փրոքսի և ընտրովի ավտոմատ կարգավորման URL, բրաուզերը կարող է հետևել դրան, վերացնել այն կամ վերահսկողությունը տալ ընդլայնմանը, հրամանի տողի գործիքը կարդում է իր միջավայրը, և կառավարվող քաղաքականությունը կարող է փոփոխությունից հետո նորից ամրացնել վերոնշյալներից որևէ մեկը։ Որոշեք, թե որ շերտն է պատասխանատու, նախքան որևէ բան խմբագրելը, քանի որ սխալ շերտը մաքրելը նման է հաջող վերանորոգման, որը վերադառնում է հաջորդ մուտքի պահին։

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

Կարդացեք այն արժեքը, որն իրականում օգտագործում է յուրաքանչյուր գործիք

Տպեք կոնֆիգուրացիան նախքան փոխելը և պատճենեք ճշգրիտ փրոքսի տողը մի տեղ, որտեղից կարող եք վերականգնել այն։ Shell-ի փոփոխականները հրամանի տողի գործիքների ամենաարագ ստուգումն են, քանի որ VPN հաճախորդը սովորաբար դրանք անձեռնմխելի է թողնում։

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Գործարկեք միայն ձեր առջևի հարթակին համապատասխան տողը, ապա կարդացեք ելքը հյուրընկալողի, պորտի և հավատարմագրերի համար։ Այնպիսի արժեք, ինչպիսին http://proxy.corp.example:8080 նշանակում է, որ գործիքը յուրաքանչյուր հարցման համար հարցնում է այդ հյուրընկալողին, մինչդեռ դատարկ արդյունքը նշանակում է, որ այն գնում է ուղիղ, և իրական խափանումը այլ տեղ է։ Թաքցրեք օգտատիրոջ և գաղտնաբառի մասը նախքան ելքը տոմսի մեջ տեղադրելը, քանի որ այդ տողերը շատ ավելի հաճախ կենդանի հավատարմագրեր են, քան մարդիկ ենթադրում են։

Սեփական փրոքսի շարժիչով գործիքներին պետք են սեփական ապացույցներ։ Curl-ը հայտնում է իր կայացրած որոշումը, երբ բարձրացնում եք մանրամասնությունը, ինչը լավ է միջավայրից գուշակելուց, և նույն դրոշը ցույց է տալիս՝ անվան լուծումը տեղի է ունեցել տեղում, թե փրոքսիում։

Մաքրեք վերագրանցումը և նորից փորձեք նույն հարցումը

Փոխեք մեկ շերտ, ապա կրկնեք հենց այն հարցումը, որը ձախողվել էր, քանի որ այլ URL ոչինչ չի ապացուցում։ Նախ մաքրեք ընթացիկ shell-ի միջավայրի փոփոխականները, քանի որ այդ խմբագրումը շրջելի է և չի կարող կոտրել թունելը:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Եթե մանրամասն ելքը դեռ պնդում է փրոքսի մասին, ապա միջավայրը իշխանությունը չէր։ Բարձրացեք մեկ մակարդակ, փոխարենը ավելի շատ վերագրանցումներ կուտակելու։

macOS-ում ստուգեք, որ ավտոմատ կոնֆիգուրացիայի ֆայլը չի տրամադրում արժեքը, ապա անջատեք ծառայության փրոքսին և հաստատեք փոփոխությունը։ Windows-ում հիշեք, որ WinHTTP կարգավորումը և յուրաքանչյուր օգտատիրոջ բրաուզերի կարգավորումը տարբեր օբյեկտներ են, այնպես որ մաքուր հրամանի տողի գործիքը կարող է գոյակցել բրաուզերի հետ, որը դեռ ցույց է տալիս հին սերվերին։ Ընդլայնումները նույն կասկածին արժանի են, քանի որ փրոքսի ընդլայնումը կարող է վերաշարադրել հարցումները միայն մեկ պրոֆիլի համար, և դա հենց այն ձախողման ձևն է, որն ազդում է մեկ բրաուզերի վրա և ուրիշ ոչնչի։

Ստուգեք, որ ուղղումը գոյատևում է վերագործարկումից

Կարգավորումը, որն աշխատում է միայն ձեր խմբագրած տերմինալում, ուղղված չէ։ Կրկին բացեք հավելվածը աշխատասեղանի գործարկիչից, դուրս եկեք և նորից մուտք գործեք, և հետևեք՝ արդյոք հին փրոքսին վերադառնում է։

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

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Եթե հին արժեքը վերադառնում է վերագործարկումից հետո, աղբյուրը կառավարվող քաղաքականություն կամ պրոֆիլ է, որը նորից կիրառում է այն, և այդ քաղաքականության տերը պետք է հեռացնի բացառությունը։ Սերտիֆիկատների ստուգումը թողեք միացված ամբողջ ընթացքում, քանի որ երթևեկությունը գաղտնալսող փրոքսին հակառակ դեպքում լուծված կթվա հենց որ անջատեք ստուգումները։ Ավարտեք՝ հեռացված արժեքը և ամսաթիվը գրելով ձեր նշումներում, որպեսզի հաջորդ մարդը կարողանա տարբերել դիտավորյալ փրոքսին մոռացվածից։