د VPN د هر اپ استثناوې ماتېږي کله چې شریکه خدمت معلومات راوړي

تاسو یو اپلیکیشن له VPN څخه ایستئ او هغه ډاونلوډ چې ورته اړتیا وه لا هم ناکامېږي، یا لا بدتر، کار پیلوي او یو نامربوط شی ودريږي۔ لیدل شوې کړکۍ اړینه نه ده چې هره اړیکه پرانیستونکې پروسه وي: اپلیکیشن کولای شي کار یو مرستندوی، د شالید لیږد خدمت یا په بشپړ ډول بل بست ته وسپاري۔ نو ځکه د هر اپ قاعده د پلیټفارم ریښتینی پیژندنې ماډل ته اړتیا لري، نه د پیلوونکي فایل د اشنا نوم ته۔ لاندې کتنې له مشاهدې پیلېږي او هغه چاته بیرته ځي چې غوښتنه یې واقعیا لیږلې وه۔

په دغو ټیکټونو کې معمولا دوه شیان یوځای خرابیږي: غلط برخه ایستل کیږي، او استثنا وروسته هیڅکله تنګ نه کیږي۔

پروسه ومومئ، نه کړکۍ

ناکامه عملیه بیا تولید کړئ او هغه پروسه یا بسته وپیژنئ چې اړیکه یې لري د هغې د پېښېدو په وخت کې۔ په Windows کې دا له دې پوښتنې جلا ده چې کومه کړکۍ فوکس لري، ځکه چې شالید لیږد کیدای شي د یو خدمت لخوا منځګړیتوب شي چې په خپله پیژندنه کار کوي۔ په Linux او macOS کې هماغه ویش د مرستندویو پروسو او سیسټم ډیمونونو په بڼه ښکاري۔

درې جزئیات ولیکئ: د اجرایي فایل یا بست پیژندنه، هغه منزل چې ورسره اړیکه درلوده، او په کاري بهیر کې هغه شیبه چې دا پېښ شو۔ هغه ډاونلوډ چې په پیل کې ناکامېږي ډیری وخت د بلې برخې لخوا میټاډاټا راوړل وي، نه هغه ډاونلوډ چې په نیمایي کې ناکامېږي۔ یوازې همدا توپیر معمولا د قاعدې له لاس وهلو دمخه د سمې پیژندنې د ټاکلو لپاره بس دی۔ که پیژندنه د اپ پرځای خدمت ثابته شي، همدا یوه حقیقت ټوله قاعده بدلوي، نو لومړی هغه ثابت کړئ۔

که پروسه نشئ لیدلی ځکه چې عملیه ډیره لنډه ده، هغه د لوی بار یا ورو منزل سره بیا تکرار کړئ۔ هدف یوه تکراریدونکې مشاهده ده، نه د دې تیوري چې کوم مرستندوی ښکیل دی۔

DNS د خپل جلا لار په توګه وګورئ

د سیسټم نومونو حل کیدای شي ایستل شوي اپلیکیشن هیڅ ونه تعقیبوي، نو ځکه ایستل شوی براوزر لا هم کولای شي په یو شخصي هوسټ نوم کې ناکام شي، که څه هم د هغه ترافیک په سمه توګه د تونل څخه بهر دی۔ براوزر ایستل شوی و؛ حل کوونکی نه۔

وګورئ چې پلیټفارم د هر اپ قاعدې د پلي کیدو پر مهال له DNS سره څه کوي، او دا له HTTP غوښتنې جلا وګورئ۔ که حل کوونکی شریک خدمت وي، هغه د وسیلې هره اپلیکیشن ته خدمت کوي، نو هغه استثنا چې تاسو یې غور کوئ ډیر پراخ لیدونکي لري له هغه څخه چې تاسو ازمویلی۔

ثبت کړئ چې کوم حل کوونکي ځواب ورکړ او د کوم انټرفیس له لارې۔ هماغه یوه مشاهده د «اپ ایستل شوی خو نوم نه حل کیږي» راپورونو لویه برخه حلوي، نو هغه د ټیکټ سره وساتئ۔

شریک مرستندوی مه پراخوئ

شریک خدمت د څو اپلیکیشنونو لپاره کار ترسره کوي، نو د یو کاري بهیر د سمولو لپاره یې ایستل نامربوط ترافیک هم بدلوي۔ په Windows کې Background Intelligent Transfer Service د دې بڼې ښه بېلګه ده: دا هغه زیربنا ده چې ډیر اپلیکیشنونه یې کارولی شي، او پیژندنه یې د هغه اپ پیژندنه نه ده چې لیږد یې غوښتی دی۔

د هغه استثنا د اضافه کولو دمخه د کلاینټ ملاتړ شوی قاعده ماډل او د سازمان اړتیاوې وګورئ۔ وپوښتئ چې برخه نور څه کاروي، او ایا هغه قاعده چې تاسو یې لیکلو ته نږدې یاست د شریکې پروسې پرځای د منزلونو په وړاندې بیانیدای شي۔

که اړتیا په بشپړ ډول د اپ پولې په توګه بیان نشي، د منزل پر بنسټ پالیسي یا بله تصویب شوې طرحه کیدای شي له ودې کوونکې د مرستندویانو د استثناوو لیست څخه ډیره پوهاوی وړ او خوندي وي۔

ټول کاري بهیر وازموئ، نه ناکام ګام

د ملاتړ شوي بدلون وروسته غوښتل شوې دنده د نوي غوښتنې سره له پیل څخه تر پای پورې چل کړئ۔ بیا هغه بله کاري بهیر چل کړئ چې شریکه برخه کاروي، ځکه چې همالته پراخه تیریدنه ځان اعلانوي۔ هغه سمون چې لومړی سم کوي او دویم په خاموشۍ ماتوي سمون نه دی۔ دواړه پایلې په ټیکټ کې وساتئ او دویم کاري بهیر په څرګنده ونومئ، ترڅو بیاکتنه کوونکی یې تکرارولی شي۔

ازموینه کوچنۍ او تکراریدونکې وساتئ: هماغه منزل، هماغه حساب، هماغه شرایط۔ که دویم کاري بهیر مستند نه وي، د بدلون د خوندي والي د پرېکړې دمخه د هغه له مالک څخه وپوښتئ چې پر څه تکیه دی۔

نومونو لیست نه، دلیل پریږدئ

برخه، هغه کاري بهیر چې خدمت یې کوي، او د هغې د ایستلو دلیل مستند کړئ۔ د مرستندویانو د نومونو لیست پرته له تړلي هدف څخه په دوو خپرونو دورو کې د ساتلو وړ نه وي، او بل انجنیر د پاکولو پر مهال غلط داخل حذفوي۔

د هر استثنا لپاره یوه کرښه بس ده: پرته له هغې څه ماتېږي، د هغه کاري بهیر مالک څوک دی، او کله وروستی ځل تایید شوی۔ هغه درې ساحې یو اسرار لیست په داسې پالیسي بدلوي چې څوک یې دفاع کولی شي۔