Գործառույթների ցանկում գրված kill switch-ը գրեթե ոչինչ չի ասում այն մասին, թե ինչ է լինում, երբ թունելն ընկնում է։ Մի իրականացում փակում է ընտրված գործընթացներ, մյուսը տեղադրում է փաթեթային զտիչներ օպերացիոն համակարգի սահմանին, իսկ երրորդը պարզապես փորձում է նորից միանալ։ Տարբերությունը երևում է ձախողումից հետո վայրկյաններին, ոչ թե կարգավորումների էկրանին։ Անցեք այս ստուգումները հերթականությամբ և կանգնեք առաջինի վրա, որին չեք կարող ազնիվ պատասխանել, որովհետև հենց այնտեղ է ավարտվում ձեր իրական ծածկույթը։

Նախ անվանեք կիրառման մեխանիզմը

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

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

Արդյո՞ք արգելափակումը գոյատևում է հաճախորդից։

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

Փակեք հաճախորդը երկար ներբեռնման կեսին և տեսեք՝ փոխանցումը կանգ է առնում, թե շարունակվում։

Փնտրեք սովորական անցքերը

IPv6-ը առաջինն է։ IPv4 հասցեների համար գրված կանոնը անփոփոխ է թողնում IPv6 թրաֆիկը, և շատ հաճախորդներ գրում են միայն v4 կեսը։ Երկրորդը ինտերֆեյսն է. USB tethering-ը, երկրորդ Wi-Fi ադապտերը և բջջային մոդեմը կարող են ներառված չլինել հիմնական կապակցությամբ սահմանափակված կանոնում։ Բացառված հավելվածներ և տեղական ցանցի բացառությունները երրորդն են։

Windows-ում կարող եք կարդալ տեղադրված կանոնները՝ անջատիչին վստահելու փոխարեն. Get-NetFirewallRule -DisplayName '*VPN*'-ը և netsh wfp show filters-ը երկուսն էլ ցույց են տալիս, թե ինչ կա։ Linux-ում iptables -S-ը, ip6tables -S-ը և nft list ruleset-ը ծածկում են սովորական դեպքերը, և երեքի համեմատությունն է բուն իմաստը։

DNS-ը սովորական արտահոսքն է

TCP-ի արգելափակումը, երբ UDP 53-ը բաց է մնում, տալիս է շատ համոզիչ kill switch, որը դեռ պատասխանում է հոսթի անվան յուրաքանչյուր հարցման։ Նույնը վերաբերում է, երբ DNS-ը հանձնվում է մեկ այլ ինտերֆեյսի լուծիչի, կամ երբ հաճախորդը արգելափակում է միայն v4-ը, իսկ լուծիչը հասանելի է v6-ով։

Թունելն ընկած վիճակում լուծեք մեկ հայտնի անուն և տեսեք՝ պատասխանը վերադառնում է։ Եթե այո, թրաֆիկը լրիվ արգելափակված չէ, ինչ էլ ասի կարգավիճակի պատկերակը։

Փորձարկեք անցումը, ոչ թե անջատիչը

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

Մեկ նոութբուքի արդյունքը չի փոխանցվում հեռախոսին կամ երթուղիչին։ Տարբեր պլատֆորմային API-ներ, տարբեր լռելյայն արժեքներ, և Android-ում տարբերությունը կտրուկ է. արգելափակմամբ always-on ռեժիմը պարտադրում է համակարգը, ոչ թե հաճախորդը, ուստի այն շարունակում է աշխատել, երբ հաճախորդը չի աշխատում։ Android VPN ուղեցույցը նկարագրում է այդ բաժանումը։

Պահեք վերադարձի ճանապարհ

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

Եթե չեք կարող պատասխանել ձեր հաճախորդի վթարի, IPv6-ի, DNS-ի և անցման ստուգումներին, վերաբերվեք նրան որպես հավելվածի մակարդակի անջատիչ՝ հայտնի բացերով, և պլանավորեք համապատասխանաբար։

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