اپلیکیشن باید د VPN د فعالیدو پر مه ونه ځغلي: څه شی دا پلي کوي

kill switchونه او د یو بل پورته کېدو د بندیز قواعد مخالف لورته اشاره کوي، ځکه چې عادي VPN تنظیمات دویم هېڅکله نه څرګندوي. kill switch هغه تونل ته غبرګون ښیي چې لوېدلی وي، خو دا غوښتنه هغه تونل ته غبرګون ښیي چې پورته وي او اپ له انځوره بهر ساتي. یوه ډیزاین پرېکړه ډېره برخه حل کوي: اپ بند شي، له پیلېدو منع شي، که یوازې د شبکې لاسرسی ترې واخیستل شي. له فایر وال قاعدې یا د پروسس وژونکي کړۍ مخکې هغه پوړ وټاکئ، ځکه چې د کتنې له مخې پلي شوې قاعده په هر پیل کې یوه کړکۍ تېزوي.

افسانه: kill switch پروګرامونه له پیلېدو منع کوي

kill switchونه د ترافیک کنټرول دي او په دې کې رښتیني دي: د تونل د حالت له مخې پاکټونه اجازه یا ردوي. هیڅ یو یې له پروګرام پیلولو انکار نه کوي، او هیڅ یو یې نه ګوري چې کوم اجرایي فایل ساکټ پرانیستی. د ډیسکټاپ لنډلار، ټاکل شوې دنده او شاته مرستندوی ټول شبکې ته رسېږي پرته له دې چې د اپ نوم پېژندونکي څه شي څخه تېر شي. د دې دوو میکانیزمونو ترمنځ فاصله هغه ځای دی چې ډېره ګډوډي پکې اوسېږي.

هغه ترتیب چې واقعاً پرېکړه کوي چې پروګرام کولی شي پیل شي که نه، د اپلیکیشن کنټرول دی. په 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 کلاینت پورې. د ناستې پای هم مستند کړئ، او د ننوتلو پر مهال بند شوي هر پروسس بیا پرانیستلو پرځای قصدي دوام ته لومړیتوب ورکړئ. د هر لېږد پایله په هماغه یادښت کې ولیکئ چې د واحد فایلونه پکې ساتل کېږي.