Արդյո՞ք ձեր անջատիչը կարգելափակի այն հավելվածը, որը դուք հանել եք թունելից։
Բացառված հավելվածը կարող է դիտավորյալ ուղիղ գնալ, իսկ պաշտպանվածը պետք է ձախողվի փակ վիճակում։ Նախ գրեք քաղաքականությունը յուրաքանչյուր հավելվածի համար, ապա ստուգեք, թե ինչ է պարտադրում հաճախորդը։
Անջատիչը միացված է, հավելվածը դիտավորյալ բացառված է թունելից, և երկու պահանջներն այժմ հակասում են միմյանց։ Մեկն ասում է, որ ոչինչ չի կարող դուրս գալ բացի թունելից, մյուսն ասում է, որ այս ծրագիրը պետք է գնա ուղիղ։ Յուրաքանչյուր հաճախորդ լուծում է այդ հակասությունը տարբեր կերպ, և կարգավորումների էջը հազվադեպ է բացատրում, թե որ կանոնն է հաղթում։ Գրեք քաղաքականությունը յուրաքանչյուր հավելվածի համար, նախքան որևէ պիտակի վստահելը։
Երկու քաղաքականություն, մեկ մեքենա
Անջատիչը ձախողման մասին խոստում է. երբ թունելը չի պաշտպանում երթևեկությունը, երթևեկությունը կանգ է առնում։ Բաժանված թունելը ընտրության մասին խոստում է. այս ծրագրերը կամ նպատակակետերը օգտագործում են թունելը, իսկ մյուսները՝ ոչ։ Երկրորդ խոստումը ստեղծում է երթևեկություն, որի մասին առաջինը պետք է որոշում կայացնի։ Ոչ մի խոստում սխալ չէ. դրանք պարզապես գրել են տարբեր մարդիկ տարբեր սպառնալիքների համար։
Հնարավոր է երեք արդյունք, և դրանցից միայն մեկն է այն, ինչ նախատեսել էր տեղակայումը։ Բացառված հավելվածը կարող է խափանման ընթացքում մնալ ուղիղ, ինչը հարգում է բաժանումը և կոտրում անջատիչը։ Այն կարող է արգելափակվել մնացած ամեն ինչի հետ, ինչը հարգում է անջատիչը և կոտրում բաժանումը։ Կամ այն կարող է արգելափակվել միայն երբեմն՝ կախված նրանից, թե ինչպես է հարթակը գնահատում կանոնը ինտերֆեյսի անհետանալուց հետո։ Հենց վերջին դեպքն է առաջացնում դիմումներ։
Նախ գրեք հավելվածների ցանկը, հետո կանոնը
Թվարկեք այն ծրագրերը, որոնք պետք է օգտագործեն թունելը, նրանք, որոնք պետք է գնան ուղիղ, և այն անունները կամ նպատակակետերը, որոնք երբեք չպետք է հայտնվեն ոչ մի ցանկում։ Առանձին նշեք լուծիչի վարքը և IPv6 կողմը, քանի որ երկուսն էլ կարող են հետևել էջերի երթևեկությունից տարբերվող քաղաքականության։
Յուրաքանչյուր հավելվածի կանոնները սովորաբար համապատասխանում են գործարկվող ֆայլին կամ փաթեթին, ոչ նրա ներսի պրոֆիլին։ Դիտարկիչի պրոֆիլը, գաղտնի պատուհանը և ընդլայնումը սեփական ցանցային ինքնություն չեն կրում, ուստի ժառանգում են այն, ինչ ստացել է գործընթացը։ Այդ դիտարկիչի գործարկած օժանդակ գործընթացը կարող է ընդհանրապես չժառանգել նույն կանոնը։
Անհրաժեշտ է երկու ցանկ, ոչ թե մեկ. ինչ պետք է կրի թունելը, և ինչը ոչ մի պատճառով չպետք է ճանապարհորդի դրանից դուրս։ Հավելվածը, որը հայտնվում է երկուսում էլ, պահանջների հակասություն է, ոչ թե ներդրման մանրամասնություն, և այն պետք է լուծվի նախքան հաճախորդի կարգավորումը։
Ինչ է անում հաճախորդը խափանման ընթացքում
Որոշ ներդրումներ արգելափակում են բացառված հավելվածները խափանման ընթացքում և վերականգնում դրանց հասանելիությունը վերամիացման ժամանակ։ Մյուսները պահպանում են ուղիղ ուղին ողջ ընթացքում, ինչը համահունչ է բաժանմանը և ավելի թույլ է որպես անվտանգության հատկություն։ Հարթակի մակարդակի կողպումը կարող է ամբողջությամբ վերացնել հաճախորդի սեփական ընտրությունը յուրաքանչյուր հավելվածի համար։ Այդ տարբերությունը կոսմետիկ չէ, քանի որ այն որոշում է՝ բացառված հավելվածը քաղաքականության բացառությո՞ւն է, թե՞ անցք։
Android-ի մշտապես միացված VPN-ը՝ առանց VPN-ի միացումներն արգելափակելու ընտրանքով, ամենապարզ դեպքն է, քանի որ կողպումը պարտադրում է հարթակը, ոչ թե հաճախորդը, և բացառված փաթեթը արգելափակվում է մնացած ամեն ինչի հետ, քանի դեռ թունելը անջատված է։ Սեղանադիր հաճախորդը, որը կիրառում է յուրաքանչյուր հավելվածի բացառություններն իր սեփական դրայվերում, սովորաբար բացառված գործընթացը թողնում է ֆիզիկական ինտերֆեյսի վրա, քանի որ սկզբից չի տիրապետել այդ գործընթացի երթևեկությանը։ Երկու վարքագծերն էլ պաշտպանելի են, և դրանցից միայն մեկն է համապատասխանում պահանջին, որ բացառված հավելվածը պետք է մնա օգտագործելի։ Հարցրեք, թե որ բաղադրիչն է պարտադրում կանոնը, նախքան արդյունքը մեկնաբանելը։
Կարդացեք ձեր առջևի օպերացիոն համակարգի վարքը, ոչ թե այլ տեղ նույն անունով կարգավորումը։ Կիրառման API-ները տարբեր են, և մեկ նշատուփը կարող է սեղանադիր համակարգչում և հեռախոսում բացարձակապես տարբեր բաներ նշանակել։ Տարբերակը նույնպես կարևոր է, քանի որ կողպման կառավարումը Android-ի թողարկումների ընթացքում տեղափոխվել է էկրանների միջև, և հաճախորդի կողմի բացառությունների ցանկը նույն կառավարումը չէ, ինչ հարթակի կողպումը։
Երեք պահ՝ թունելը միացված, թունելը անջատված, վերամիացում
Օգտագործեք անվնաս հարցումներ երեք պահի՝ մինչ թունելը աշխատում է, ձեզ հետաքրքրող խափանման ընթացքում և վերամիացումից հետո։ Մեկ դիտարկիչի արդյունքը չի կարող հաստատել բացառված հավելվածի վարքը։
curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com
Ելքի հասցեն ցույց է տալիս, թե որ ուղին է ընտրվել, իսկ բացահայտ ինտերֆեյսի թեստը ցույց է տալիս, թե ինչ է լինում, երբ թունելը միակ հասանելի ելքն է։ Յուրաքանչյուր տողի կողքին գրեք սպասվող արդյունքը, նախքան դրանցից որևէ մեկը գործարկելը, հակառակ դեպքում ելքը կմեկնաբանվի հետո։
Եթե բացառված հավելվածը դուրս է մնում ցանցից, ստուգեք քաղաքականության առաջնահերթությունը՝ նախքան լայն հրդեհապատի թույլտվություն ավելացնելը, քանի որ այդ ուղղումը ոչնչացնում է ձեր փորձարկած տարբերությունը։ Եթե այն մնում է ուղիղ, հաստատեք, որ դա փաստաթղթավորված բացառությունն էր, ոչ թե պատահական հետընթաց։ Ամբողջ սարքի համար խիստ պահանջի դեպքում կրճատեք բացառությունների ցանկը, մինչև այն ձեռքով փորձարկելի դառնա։