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

Քայլ 1. գրեք երկու հոսքերը

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

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

Տարբեր աղբյուրներ, տարբեր ուղիներ, տարբեր թույլտվություններ։ Պահեք ուրվագիծը փոփոխության գրառման մեջ, քանի որ յուրաքանչյուր հետագա ստուգում վերաբերում է նրա երկու կեսերից մեկին։

Քայլ 2. դիտարկիչին տվեք ճանապարհ դեպի լսողը

Գրանցեք պրոքսիի հոսթի անունը, լսողի պորտը, նույնականացման պահանջները և թույլատրված մասնաճյուղի աղբյուրները։ Այդ ցանկը առաջին հոսքի ընդունման չափանիշն է և պետք է ներառի ինչպես ներքին անվանումների լուծումը, այնպես էլ թունելի ուղին։

Կիրառեք նեղ ցանցային կանոն նախատեսված ծառայության համար՝ ինտերնետում անսահմանափակ պրոքսի հրապարակելու փոխարեն։ Պրոքսին կարող է մնալ ներքին ցանցում, երբ նրա նախատեսված հաճախորդներն ունեն աջակցվող ուղի դեպի այն։

Քայլ 3. կարգավորեք դիտարկիչը, ոչ միայն երթուղիների աղյուսակը

Օգտագործեք դիտարկիչի պրոքսի կարգավորումը, PAC ֆայլը կամ կազմակերպության կառավարվող հայտնաբերման մեխանիզմը։ Սովորական կայքի փաթեթները երթուղիով պրոքսիի հասցեին ուղարկելը չի ստիպում դիտարկիչին խոսել պրոքսի արձանագրությամբ. դա թափանցիկ ընդհատում է և պատկանում է այլ դարպասի նախագծի։

Գրեք, թե որ հավելվածներն են հարգում կարգավորումը։ Փոստի հաճախորդները, թարմացնողները և խաղերը հաճախ չեն անում դա և կշարունակեն օգտագործել պարզ ուղին։

Քայլ 4. ապացուցեք պրոքսիի ելքային կապը

Պրոքսիին անհրաժեշտ են սեփական resolver և թույլատրված ուղի դեպի կայք, ինչպես նաև ցանկացած firewall կամ թարգմանության քաղաքականություն, որը պահանջում է նրա ինտերնետ սահմանը։ Լսողին հասնող դիտարկիչը դրանից ոչինչ չի ապացուցում։ Ստուգեք երկրորդ հոսքը հենց պրոքսիից, օգտատիրոջ հաղորդած նույն նպատակակետով և պորտով։

HTTPS-ի համար CONNECT-ը թունել է բացում դեպի պահանջված նպատակակետը։ Սովորական փոխանցումը պրոքսիին չի տալիս վերծանված էջը, և վկայագրի վավերացումն անջատելը՝ ստուգումը իմպրովիզացնելու համար, լուծում չէ։

Քայլ 5. տարբերեք չորս խափանում

Պրոքսիի նույնականացման մարտահրավերը 407 է լսողից։ Մերժված CONNECT-ը քաղաքականության որոշում է պրոքսիում, սովորաբար իր կարգավիճակով և մատյանային տողով։ Ձախողված ելքային կապը նման է ժամկետի լրանալու կամ վերակայման, որը պրոքսին գրանցում է նպատակակետի դեմ։ Կայքի պատասխանը նշանակում է, որ երկու կապերն էլ աշխատել են, և խնդիրը սկզբնաղբյուրում է։

Հաղորդեք ձեր դիտած սահմանը, ոչ թե այն ամփոփումը, թե VPN-ը ձախողվել է։

Քայլ 6. սահմանեք ծավալը և պլանավորեք պահուստը

Որոշեք, թե ինչ է լինում, երբ պրոքսին կամ թունելը հասանելի չեն, և հստակ ասեք, թե որ տրաֆիկն է ծածկում այս նախագիծը։ Այն կրում է վեբ հասանելիություն այն հաճախորդներից, որոնք հարգում են պրոքսիի կարգավորումը. այն չի կրում փոստ, կամայական սարքի արձանագրություններ կամ ծրագրակազմ, որն անտեսում է կոնֆիգուրացիան։

Վավերացրեք պահանջվող դիտարկիչի գործողությունը և մեկ պահանջվող մերժումը հաստատված պլանի համաձայն՝ նախքան նախագիծը ավելի շատ հաճախորդների ընդլայնելը։

Առնչվող հոդվածներ