دوه VPN اپلیکیشنونه یوځای: کوم kill switch په رښتیا پلي کېږي؟
دوهم VPN کارن هیڅکله د لومړي kill switch په میراث نه اخلي. درې شرطونه ټاکي چې کومه تګلاره پلي کېږي، او څنګه خپله یې تصدیق کړئ.
دوه VPN کارنان کولی شي څنګ په څنګ کار وکړي، خو د دوی kill switch په یوه تګلاره نه یوځای کېږي۔ هر کارن د خپل تونل لپاره قواعد لګوي، او هیڅ یو نه پوهېږي چې بل شته۔ زه له دې سره مخ شوم چې لومړی د کار کارن وصل و: دوهم اپلیکیشن ونه توانېد چې لاس ورکول بشپړ کړي، لس دقیقې په „Connecting“ کې پاتې شو، او لومړي تونل هر څه په غلې مانده وړل۔ دا چې دوهم اپلیکیشن خوندي کېږي که نه، په درې شرطونو پورې اړه لري، نه په دې چې دواړه آیکونونه وايي وصل دی۔
kill switch په رښتیا څه ته محدود دی
په عملیاتي سیستم کې یوازې یوه kill switch بیرغ نشته۔ هغه کارن چې داسې بیرغ اعلانوي، یوه ټولګه قواعد لګوي: هر هغه څه وغورځوه چې زما د تونل له لارې نه وځي، او ډېری وختونه fail closed عمل کوه کله چې تونل ورک شي۔ په Linux کې دا معمولاً د nftables یا iptables زنځیر وي، په Windows کې د Windows Filtering Platform فلټرونو ټولګه، په Android او iOS کې د تونل خدمت خپله لارښونه او هغه سیسټم تنظیم چې پرته له VPN اړیکې بندوي۔ د Android VPN لارښود دا د خدمت ماډل بیانوي که تاسو د پلیټفارم لید غواړئ۔
ساحه هغه برخه ده چې مهمه ده۔ د „یوازې د wg0 د وتلو انټرفیس پاکټونو ته اجازه ورکړه“ په څېر قاعده په دې نه پوهېږي چې دوهم تونل شته که نه۔ که بل کارن wg1 پورته کړي، د لومړي کارن قواعد هغه پاکټونه عادي ترافیک ګڼي: معمولاً غورځول کېږي، کله ناکله اجازه ورکول کېږي۔ هر څنګه وي، لومړی کارن پرېکړه کوي، او هیڅ تصور نه لري چې دوهم اپلیکیشن انتظار کوي۔
درې شرطونه چې ټاکي څوک پوښل کېږي
اړتیا نشته چې هر ترکیب ولیکل شئ۔ درې پوښتنې دا په څو دقیقو کې حل کوي۔
- آیا پلیټفارم په بشپړ ډول دوهم تونل ته اجازه ورکوي؟ ډېری Android تلیفونونه او iPhone ګانې په هر کارن پروفایل کې یوازې یو فعال VPN خدمت مني، نو دوهم اپلیکیشن هیڅکله تونل نه لري او هیڅ شی نه پلي کوي۔ تاسو یوازې یوه تګلاره ترلاسه کوئ، له هغه اپلیکیشن چې ځای یې وګاټه۔
- کوم پروسه د اصلي لار مالکه ده؟ Windows، macOS او Linux په اسانۍ سره دوه تونلونه وړي۔ اصلي لاره د هغه کارن ده چې په آخر کې یا ښه میټریک سره یې تنظیم کړې، او بل کارن وصل دی خو بېکاره۔ په Linux کې د wg-quick د اصلي لار حالت د خصوصي جدول او fwmark قاعدې سره د تګلارې پر بنسټ لارښونه کاروي، نو دوهم wg-quick تونل د لومړي د بدلولو پر ځای سیال قاعده ورزیاتوي۔
- آیا دوهم کارن خپل سرور ته رسېدلی شي؟ که لومړی kill switch په اصلي ډول رد وي، د دوهم اپلیکیشن بهرنی پای ټکی یوازې یو بل غورځول شوی هدف دی۔ په غلې مانده بیا هڅه کوي او هیڅکله تېروتنه نه راپور کوي۔
لنډه بڼه، د ملاتړ تارونو لپاره:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
د دې کرښو دوه له سیستم ټری آیکون څخه یو شان ښکاري، له همدې امله آیکون دلته تر ټولو کمزوری شته ثبوت دی۔
لومړی څه ناکامېږي، او څنګه ښکاري
کارن چې په „Connecting“ کې بند پاتې وي او بل روغ وي، نږدې تل د پای ټکي قحطي ده: فعال kill switch د دوهم کارن لاس ورکول خپل سرور ته غورځوي۔ دا په ارزانه توګه تصدیق کړئ چې د لومړي کارن د بندولو قواعد د یوې هڅې لپاره ودرئ۔ که دوهم سمدلاسه وصل شي، پوښتنې ته ځواب ورکړل شوی۔
DNS دوهمه ناکامي ده۔ کارنان د خپل انټرفیس لپاره د حل کوونکي ترتیب ټاکي، او ځینې یې په بشپړ ډول نړیوال لیست باندې لیکي۔ کله چې دواړه تونلونه پورته وي، پوښتنې کولی شي له یوې خوا ووځي پداسې حال کې چې حل کوونکی بلې خوا ته اړه لري۔ هر اپلیکیشن قطع کړئ او پاتې یو د نه رسېدونکي نوم سرور سره پاتې کېږي: پاڼې یوه دقیقه درېږي او بیا حل کېږي، پداسې حال کې چې VPN لا هم وصل ښکاري۔
دریمه د لارو ښورېدل دي۔ بیا وصلېدل اصلي لاره بیا ترتیبوي، او د انټرفیس سره تړلی kill switch ورسره نه ځي۔ هغه ترافیک چې یوه شیبه دمخه په تونل کې و اوس د غورځولو قاعدې سره سمون لري، کوم چې د کارن له اړخه د VPN په توګه لوستل کېږي چې ناڅاپه کار کول بندوي۔
تصدیق کړئ کومه تګلاره په رښتیا نافذه ده
دا په بې ضرر ترافیک سره وکړئ، نه په هغه څه چې تاسو به یې فقدان احساس کړئ۔
په Linux کې له کرنل وپوښتئ څوک ګټي او اور واخیستونکی له څه سره تړل شوی۔ ip -4 route show default هغه تونل نوموي چې وتل لري۔ ip rule show ښیي چې د تګلارې پر بنسټ لارښونه په لوبې کې ده که نه۔ sudo nft list ruleset | grep -n oifname ښیي چې غورځول د انټرفیس نوم، نښې، یا ټول وتلو زنځیر سره تړلي دي۔
په Windows کې همدا کیسه د لارې میټریک او د فلټرونو لیست کې ده: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric او Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN"۔ په macOS کې، netstat -rn -f inet | head -5 او scutil --dns | head -20۔
بیا هغه ګام واخلئ چې خلک یې پرېږدي: تونل په قصد ودرئ او تصدیق کړئ چې هغه ترافیک چې تمه لرئ ناکام شي په رښتیا ناکامېږي۔ وصل آیکون د انټرفیس حالت دی، نه پلي کول۔
کله دوه کارنان غلط ډیزاین دي
که یوازینی شرط چې د دوهم اپلیکیشن شاته دی نوره ساتنه وي، هغه لرې کړئ۔ دوه متقابل بندولو تګلارې له یوې کمې وړاندوینې وړ دي، او هر بیا وصلېدل یوه فرصت دی چې په هغه حالت کې ولوېږئ چې هیڅ عرضه کوونکی یې نه ازموي۔
که تاسو واقعاً زنځیر ته اړتیا لرئ، لکه یو شرکت ګېټوې چې د سوداګریزې ټوپې له لارې رسېږي، د یوازې یو پلي کولو ټکي سره ډیزاین وټاکئ۔ دا معمولاً یو روټر یا یو کارن مانا لري چې زنځیر ملاتړ کوي، نه دوه ډیسکټاپ اپلیکیشنونه چې د یوې اصلي لارې لپاره سیالي کوي۔ په مدیریت شوي وسیله کې اجازه ورکړل شوی کارن وساتئ او هر بل څه له ساحې بهر وګڼئ، هر څه چې په ټری کې ښیي۔
د دواړو ساتلو دمخه د تفتیش لیست
لیست په ترتیب سره بشپړ کړئ؛ لومړی ناکام شوی توکی هغه دی چې باید سم شي۔
- تصدیق کړئ چې یوازې یو کارن د اصلي لار او حل کوونکي مالک دی۔
- که غواړئ دوهم کارن پورته وي، د هغه د سرور پای ټکي ته په ښکاره ډول اجازه ورکړئ او له هر اپلیکیشن تازه کولو وروسته بیا وګورئ۔
- د تمه شوې پایلې ولیکئ کله چې کوم تونل ولویږي، او هماغه حالت وازموئ۔
- د بیا پیل وروسته د ناکامۍ لاره وګورئ، کله چې د پیل ترتیب توپیر لري۔
- په مدیریت شوي پروفایل کې ودرېږئ او د هر څه زیاتولو دمخه له مالک وپوښتئ۔
که دریم ګام ناکام شي، رښتینې ځواب دا دی چې یوازې یو کارن تاسو ته تګلاره درکوي۔ پرېکړه وکړئ چې پر کوم باور لرئ او بل یې پرېږدئ۔