Ինչու բաժանված թունելավորումը չի ընդգրկում ձեր հավելվածի թարմացումները

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

Առասպել՝ հավելվածը բացառելը բացառում է նրա տրաֆիկը

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

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

Գտեք փոխանցման սեփականատիրոջը

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

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

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

Ստուգումը վերապրում է երթուղու փոփոխությունը

Երթուղին փոխելը չի փոխարինում TLS-ին, հրատարակչի ինքնությանը կամ փաթեթի ստորագրության ստուգմանը։ Մի՛ անջատեք այդ ստուգումները, որովհետև ներբեռնումը հաջողվում է միայն անբացատրելի վկայագրի նախազգուշացումն անցնելուց հետո։ Զգուշացումը, որը հայտնվում է միայն բացառված ուղու վրա, բացահայտում է, ոչ թե խոչընդոտ։ Քննեք այն նախքան շրջանցումը լայնացնելը։

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

Փորձարկեք թարմացումը, ապա փաստաթղթավորեք սեփականատիրոջը

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

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