Հավելվածը չպետք է աշխատի, երբ VPN-ը միացված է. ինչն է դա պարտադրում

Kill switch-ները և չհամընկնելու կանոնները հակառակ ուղղություններ են ցույց տալիս, ինչը բացատրում է, թե ինչու սովորական VPN կարգավորումները երբեք չեն արտահայտում երկրորդը։ Kill switch-ը արձագանքում է ընկած թունելին, մինչդեռ այս պահանջը արձագանքում է վերևում գտնվող թունելին և հավելվածին դուրս է պահում պատկերից։ Մեկ ձևավորման որոշում լուծում է մեծ մասը՝ հավելվածը կանգնեցվում է, արգելափակվում է մեկնարկը, թե պարզապես զրկվում է ցանցային հասանելիությունից։ Ընտրեք այդ շերտը նախքան firewall-ի կանոնին կամ պրոցեսներ սպանող հանգույցին դիմելը, քանի որ դիտարկմամբ պարտադրված կանոնը յուրաքանչյուր մեկնարկի ժամանակ պատուհան է արտահոսում։

Առասպել. kill switch-ը խանգարում է ծրագրերի մեկնարկին

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

Այն կարգավորումը, որն իսկապես որոշում է՝ ծրագիրը կարող է սկսվել, հավելվածների վերահսկումն է։ Windows-ում դա նշանակում է AppLocker կամ WDAC, իսկ կառավարվող macOS-ում՝ սարքի պրոֆիլով պարտադրված թույլատրվածների ցանկ։ Երկուսն էլ անկախ են թունելից, այդ պատճառով երկու պահանջները միաձուլվում են մեկ տոմսի մեջ, և հետո ոչ մեկը չի բավարարվում։

Անվանեք ռեժիմը, նախքան գործիքը կանվանեք

Գրեք կանոնը որպես երեք վիճակով վիճակի մեքենա՝ սովորական օգտագործում, VPN աշխատանքային նստաշրջան և ելք։ Արգելված համընկնումը պատկանում է միջին վիճակին, ոչ թե հաճախորդի ծրագրաշարին։

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

Ինչ է իրականում անում երկկողմ հակամարտությունը

Երկու ծառայությունների համար, որոնք իսկապես կառավարվում են systemd-ով, Conflicts= սիմետրիկ է՝ մեկի մեկնարկը կանգնեցնում է մյուսին։ Միավորի տեղեկագիրքը փաստագրում է այդ վարքը և առանձին պահանջում է հստակ հերթականություն, երբ մեկը պետք է ավարտի կանգը մյուսի մեկնարկից առաջ։ Առանց այդ հերթականության գրառումների՝ կանգը և մեկնարկը մրցում են, և արդյունքը կախված է ժամանակից։

Սա արգելվածների ցանկ չէ։ Միացրեք կախվածությունը հակառակ ուղղությամբ, և հավելվածի մեկնարկը փոխարենը կկանգնեցնի VPN-ը, ինչը հենց այն խափանումն է, որին պետք է կասկածել, երբ թունելը ինքնուրույն անջատվում է կանխատեսելի պահին։ Աշխատասեղանի հավելվածը systemd միավոր չէ, և NetworkManager-ի կապը նույնպես միավոր չէ, ուստի այս ձևանմուշը աշխատում է միայն այն ծառայությունների համար, որոնք դուք ինքներդ եք փաթաթում։

Ստուգեք անցումները, ոչ միայն առաջին մեկնարկը

Չորս անցումներ են որոշում՝ պահանջը պահպանվում է. նստաշրջան մուտք գործելը աշխատող հավելվածով, նրա վերագործարկումը նստաշրջանի կեսին, VPN-ի ձախողված մեկնարկը և դիտավորյալ անջատումը։ Փորձարկեք յուրաքանչյուրը և արդյունքը պահեք միավորի ֆայլերի կողքին։ Ստորև բերված հրահանգները կարդում են ընթացիկ հարաբերությունը և ապա վարժեցնում ամենակարևոր անցումը։

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

Երրորդ հրահանգը պետք է հավելվածը թողնի ոչ ակտիվ, իսկ չորրորդը՝ նստաշրջանի ընթացքում թվարկի միայն թունելի կապը։ Այլ արդյունքը նշանակում է, որ անցումը բոլորովին չի պարտադրվում։

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