Հավելված առ հավելված VPN բացառությունները կոտրվում են, երբ ընդհանուր ծառայությունը տվյալներ է բերում
Ձեր բացառած պատուհանը միշտ չէ, որ այն գործընթացն է, որը բացում է կապը։ Գտեք իրական հարցում ուղարկողին նախքան հավելված առ հավելված VPN կանոնին օգնական ավելացնելը։
Դուք բացառում եք մեկ հավելված VPN-ից, և նրան անհրաժեշտ ներբեռնումը դեռ ձախողվում է, կամ ավելի վատ՝ սկսում է աշխատել, և ինչ-որ անկապ բան կանգ է առնում։ Տեսանելի պատուհանը պարտադիր չէ, որ լինի այն գործընթացը, որը բացում է յուրաքանչյուր կապ. հավելվածը կարող է աշխատանքը հանձնել օգնականի, ֆոնային փոխանցման ծառայության կամ բոլորովին այլ փաթեթի։ Ուստի հավելված առ հավելված կանոնին անհրաժեշտ է հարթակի իրական ինքնության մոդելը, այլ ոչ թե ծանոթ գործարկիչի ֆայլանուն։ Ստորև բերված ստուգումները սկսվում են դիտարկումից և վերադառնում են նրան, ով իրականում ուղարկել է հարցումը։
Այս տոմսերում սովորաբար միաժամանակ երկու բան է սխալվում. բացառվում է սխալ բաղադրիչը, և բացառությունը հետո երբեք չի նեղացվում։
Գտեք գործընթացը, ոչ թե պատուհանը
Վերարտադրեք ձախողված գործողությունը և բացահայտեք այն գործընթացը կամ փաթեթը, որին պատկանում է կապը դրա ընթացքում։ Windows-ում սա այլ հարց է, քան այն, թե որ պատուհանն ունի ֆոկուս, քանի որ ֆոնային փոխանցումը կարող է միջնորդվել ծառայության կողմից, որն աշխատում է իր իսկ ինքնությամբ։ Linux-ում և macOS-ում նույն բաժանումը երևում է որպես օգնական գործընթացներ և համակարգային դեմոններ։
Գրի առեք երեք մանրամասն. կատարվող ֆայլի կամ փաթեթի ինքնությունը, նպատակակետը, որի հետ կապի մեջ էր, և աշխատանքային հոսքի այն պահը, երբ դա տեղի ունեցավ։ Սկզբում ձախողվող ներբեռնումը հաճախ այլ բաղադրիչի կողմից մետատվյալների ստացում է, քան կիսատ ձախողվող ներբեռնումը։ Միայն այս տարբերությունը սովորաբար բավարար է ճիշտ ինքնություն ընտրելու համար նախքան կանոնին դիպչելը։ Եթե ինքնությունը պարզվում է, որ ծառայություն է, այլ ոչ հավելված, ապա այդ մեկ փաստը փոխում է ամբողջ կանոնը, ուստի նախ հաստատեք այն։
Եթե չեք կարող դիտարկել գործընթացը, քանի որ գործողությունը չափազանց կարճ է, կրկնեք այն ավելի մեծ ծանրաբեռնվածությամբ կամ ավելի դանդաղ նպատակակետով։ Նպատակը մեկ կրկնելի դիտարկումն է, ոչ թե տեսություն այն մասին, թե որ օգնականն է ներգրավված։
DNS-ը դիտարկեք որպես առանձին ուղի
Համակարգի անունների լուծումը կարող է բացառված հավելվածին ընդհանրապես չհետևել, դրա համար էլ բացառված դիտարկիչը դեռ կարող է ձախողվել մասնավոր հոսթանունի վրա, մինչ իր երթևեկությունը ճիշտ է թունելից դուրս։ Դիտարկիչը բացառված էր, լուծիչը՝ ոչ։
Ստուգեք, թե հարթակն ինչ է անում DNS-ի հետ, երբ գործում է հավելված առ հավելված կանոնը, և ստուգեք դա առանձին HTTP հարցումից։ Եթե լուծիչը ընդհանուր ծառայություն է, այն սպասարկում է սարքի յուրաքանչյուր հավելված, ուստի ձեր քննարկած բացառությունն ունի շատ ավելի լայն լսարան, քան փորձարկվածը։
Արձանագրեք, թե որ լուծիչը պատասխանեց և որ ինտերֆեյսով։ Այդ մեկ դիտարկումը լուծում է «հավելվածը բացառված է, բայց անունը չի լուծվում» հաշվետվությունների մեծ մասը, ուստի պահեք այն տոմսի հետ։
Չընդլայնեք ընդհանուր օգնականը
Ընդհանուր ծառայությունը աշխատանք է կատարում մի քանի հավելվածների համար, ուստի այն բացառելը՝ մեկ աշխատանքային հոսք վերանորոգելու համար, փոխում է նաև անկապ երթևեկությունը։ Windows-ի Background Intelligent Transfer Service-ը այդ ձևի լավ օրինակ է. այն ենթակառուցվածք է, որից կարող են օգտվել շատ հավելվածներ, և նրա ինքնությունը փոխանցումը պահանջած հավելվածի ինքնությունը չէ։
Նախքան այդ բացառությունն ավելացնելը ստուգեք հաճախորդի աջակցվող կանոնի մոդելը և կազմակերպության պահանջները։ Հարցրեք, թե էլ ինչ է օգտագործում բաղադրիչը, և արդյոք ձեր գրելիք կանոնը կարող է արտահայտվել նպատակակետերի նկատմամբ, այլ ոչ թե ընդհանուր գործընթացի նկատմամբ։
Եթե պահանջը բոլորովին չի կարող արտահայտվել որպես հավելվածի սահման, նպատակակետերի վրա հիմնված քաղաքականությունը կամ մեկ այլ հաստատված ձևավորում կարող է ավելի հասկանալի և անվտանգ լինել, քան օգնականների բացառությունների աճող ցանկը։
Փորձարկեք ամբողջ աշխատանքային հոսքը, ոչ թե ձախողված քայլը
Աջակցվող փոփոխությունից հետո գործարկեք նախատեսված առաջադրանքը թարմ հարցումով սկզբից մինչև վերջ։ Ապա գործարկեք ևս մեկ աշխատանքային հոսք, որն օգտագործում է ընդհանուր բաղադրիչը, քանի որ հենց այնտեղ է լայն շրջանցումն իրեն հայտարարում։ Ուղղումը, որը վերանորոգում է առաջինը և լուռ կոտրում երկրորդը, ուղղում չէ։ Պահեք երկու արդյունքներն էլ տոմսում և հստակ նշեք երկրորդ աշխատանքային հոսքի անունը, որպեսզի գրախոսը կարողանա կրկնել այն։
Փորձարկումը պահեք փոքր և կրկնելի. նույն նպատակակետը, նույն հաշիվը, նույն պայմանները։ Եթե երկրորդ աշխատանքային հոսքը փաստաթղթավորված չէ, նախքան փոփոխությունը անվտանգ համարելը հարցրեք դրա սեփականատիրոջը, թե ինչից է այն կախված։
Թողեք պատճառ, ոչ թե անունների ցանկ
Փաստաթղթավորեք բաղադրիչը, այն աշխատանքային հոսքը, որին այն ծառայում է, և դրա բացառման պատճառը։ Առանց կապված նպատակի օգնական անունների ցանկը երկու թողարկման ցիկլի ընթացքում դառնում է անկառավարելի, և հաջորդ ինժեները մաքրելիս հեռացնում է սխալ գրառումը։
Մեկ տող յուրաքանչյուր բացառության համար բավական է. ինչ է կոտրվում առանց դրա, ով է տիրապետում այդ աշխատանքային հոսքին, և երբ է այն վերջին անգամ ստուգվել։ Այս երեք դաշտերը առեղծվածային ցանկը վերածում են քաղաքականության, որը ինչ-որ մեկը կարող է պաշտպանել։