د اپلیکیشن او د منزل پر بنسټ split tunneling: کوم یو غوره کړئ

د اپلیکیشن او د منزل پر بنسټ split tunneling د یوې کار دوه تنظیمات نه دي. یو پوښتنه کوي چې کومه پروسه پاکټ لېږي؛ بل پوښتنه کوي چې هغه پاکټ چېرته ځي. د لومړي پوښتنې لپاره جوړه شوې قاعده په خاموشۍ سره ناکامه کیږي کله چې ترافیک له مرستندویه پروسې راځي، او د دوهم لپاره جوړه شوې قاعده هغه وخت ناکامه کیږي چې د کوربه نوم داسې پتې ته ویجاړ شي چې تاسو هېڅکله نه وي لیست کړی. د اړتیا سره سم څیز وټاکئ، بیا یې په دوو ازموینې پاکټونو ثابته کړئ: یو باید تونل وکاروي او بل باید نه.

دوه قاعدې په بېلابېلو طبقو کې عمل کوي

د اپلیکیشن قاعده د شبکې طبقې پورته، د هغې پېژندنې پر وړاندې پلي کیږي چې عملیاتي نظام لېږونکي ته ورکوي. په Android کې هغه د پاکټ شاته UID دی، او VPN خدمت د هر UID لپاره پرېکړه کوي چې ترافیک تونل ته ننوځي که نه. د منزل په اړه هېڅ نه پوښتل کیږي، نو ټاکل شوی اپلیکیشن هر ځای ته رسېدلی شي او بل هېڅ اپلیکیشن داخلي شبکې ته نه شي رسېدلی.

د منزل قاعده پر خود پاکټ پلي کیږي. د تونل انټرفېس یوه ټولګه مخکښې لري، د لارښوونې جدول سمون خورا ترافیک هلته لېږي، او لېږونکې پروسه بې تړاوه ده. له همدې امله د منزل قاعده یوه خدمت، چاپګر یا د ټولګې کار تر پوښښ لاندې راولي چې هیڅوک یې د لیست کولو یاد نه و، او له همدې امله په هغه پلیټفارم کې چې کلاینټ یې هېڅکله پروسې ته نه ګوري، دا د یوازې دې پروګرام په توګه نشي بیانېدلی.

د اپلیکیشن قاعدې د موبایل کلاینټونو او مدیریت شوو اجنټانو لپاره مناسبي دي

Android انتخاب مستقیم ښیي: VpnService.Builder.addAllowedApplication() او addDisallowedApplication() د پاکټ نومونه اخلي او پرېکړه د هر UID لپاره پلي کوي، لکه څنګه چې په د Android د VPN پراختیا کونکي لارښود کې تشریح شوي. iOS کې د بنډل پېژندونکو پر بنسټ د هر اپلیکیشن VPN قاعدې شته، چې معمولاً د لاسي لیکلو پر ځای د MDM پروفایل له لارې ورکول کیږي.

ډیسکټاپ کلاینټونه کمزوري ټکی دي. ډېری د Windows او macOS VPN کلاینټونه د منزل له مخې لارښوونه کوي او د پروسې له مخې هیڅ انتخاب نه وړاندې کوي، ځکه چې د تونل ډرایور پروسې نه، پاکټونه ویني. که ستاسو پلان په لیپټاپ کې د یو اپلیکیشن تونل کولو پورې تړلی وي، د هغې شاوخوا د ډیزاین کولو دمخه د کلاینټ ریښتیني وړتیاوې وګورئ؛ کېدای شي تاسو د منزلونو لیست او دوهم ماشین ترمنځ انتخاب کوئ.

هغه پایله چې خلک یې له لاسه ورکوي: په هغو پلیټفارمونو کې د لارښوونو له لارې د اپلیکیشن قاعدې نقل نشي کېدلی. د اپلیکیشن سرور لپاره د کوربه لارښوونه زیاتول د هر چا ترافیک هغه سرور ته تونل کوي، د براوزر او تازه کوونکي په ګډون.

د منزل قاعدې د فرعي شبکو لیستونو او د سایټونو د لاسرسي لپاره مناسبي دي

WireGuard ماډل روښانه کوي. AllowedIPs د کریپټو کیلي لارښوونه ده: هغه داخلي پاکټ چې منزل یې د یو همکار په لیست کې راځي همغه همکار ته کوډ کیږي، او پاتې نور ټول د عادي لارې له مخې بې کوډه وځي. د نومولو لپاره پروسه نشته او د دې په اړه چې څه شامل دي هیڅ ابهام نشته.

OpenVPN د ټېل وهل شوي لارښوونې جدول له لارې همدې ځای ته رسي. route-nopull سرور له دې منع کوي چې لارښوونې وټاکي، بیا د کلاینټ اړخ route 10.20.0.0 255.255.0.0 vpn_gateway په سمه توګه د دفتر مخکښه پوښي. IPv6 په هر یو له دې کلاینټونو کې جلا بیان دی، او هېرول یې د سم ښکاري IPv4 وېش شاوخوا د تېښتې ترټولو عامه لاره ده.

د کوربه نوم لارښوونه نه ده. که پروفایل د ډومېن ساحه وړاندې کوي، هغه د نوم په توګه ونیسئ چې کلاینټ یو ځل یې حل کوي، نه د تلپاتې پتې حد په توګه؛ د منځپانګې رسولو شبکې او د بار متعادل کوونکي سبا بل پتې ورکوي.

چېرته چې دواړه ماډلونه ماتېږي: مرستندویان، شریک خدمتونه، حل کوونکي

مرستندویه پروسې د اپلیکیشن قاعدې ماتوي په داسې ډول چې د سرور د خرابۍ په څېر ښکاري. د براوزر تازه کوونکی، د خرابۍ راپور ورکوونکی، د SYSTEM په توګه روان sync خدمت او په بل پاکټ کې ننوتل شوی WebView ټول جلا پېژندنې دي، نو د براوزر تونل کول کېدای شي ریښتینې غوښتنه له تونل بهر پاتې کړي. برعکس هم همدومره ګډوډونکی دی: له پامه غورځول شوی اپلیکیشن چې د تونل شوې پروسې دننه شریک کتابتون غواړي، ترافیک یې بیا هم د تونل له لارې ځي.

د منزل قاعدې پر شریکو خدمتونو او نومونو ماتېږي. د فایل شریکونې، چاپګرونه، داخلي DNS او د جواز سرور ټول په پتوونو ژوند کوي، نو د یو اپلیکیشن تونل براوزر ته لاسرسی ورکوي خو نقشه شوې ډرایو مړه پاتې کیږي. دا د پوښښ توپیر په هیڅ ماډل کې خرابي نه ده، خو همدا لامل دی چې د یو اپلیکیشن تونل ډېری وخت هغه حالت جوړوي چې VPN روان دی او شریکونه ورک شو.

حل کوونکي دواړه غوڅوي. که کلاینټ داخلي DNS سرورونه وټاکي خو عملیاتي نظام عامه حل کوونکي ته د HTTPS پر سر DNS وکاروي، ځواب له تونل بهر راځي او د منزل قاعده کېدای شي هېڅکله ونه سمون خوري. د دې له مخې چې قاعده غلطه ده، لومړی وګورئ کوم حل کوونکي واقعاً ځواب ورکړ، او د کلاینټ په اړخ کې تایید کړئ چې د تونل حل کوونکی یې نصب کړی که نه. هغه وېش چې DNS له تونل بهر پریږدي په لارښوونې جدول کې بې نقصه ښکاري او بیا هم په هر داخلي نوم کې ناکامه کیږي.

کاري ترتیب: وټاکئ، پلي کړئ، تایید کړئ

د مینو نه، د اړتیا څخه پیل وکړئ. که هدف دا وي چې یوازې دا اپلیکیشن تونل وکاروي، اپلیکیشن قاعدې او هغه پلیټفارم چې ملاتړ یې کوي ته اړتیا لرئ. که هدف دا وي چې دا شبکې د تونل له لارې د لاسرسي وړ وي، مخکښو ته اړتیا لرئ. که ځواب دواړه وي، دوه جلا کنټرولونه یې کړئ او ولیکئ چې کوم یو د کومې ناکامۍ مسؤل دی.

هغه ترټوله تنګ بڼه پلي کړئ چې بیانولی شئ، بیا د کلاینټ د حالت آیکون پر ځای د لارښوونې جدول څخه پوښتنه وکړئ:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

لومړي دوه کرښې هغه انټرفېس نوموي چې ریښتینی منزل به یې کاروي؛ wg show ترتیب شوی مخکښ لیست چاپوي؛ په Windows کې Find-NetRoute هغه همغه پوښتنې ته ځواب ورکوي چې سټک به یې د پاکټ لېږلو پر مهال ورکړي. که انټرفېس تونل وي، قاعده سمه خوړلې ده.

بیا هغه دوهم پاکټ وآزمویئ چې باید وباسل شي، له بل اپلیکیشن څخه، همغه منزل ته. په ټیکټ کې د کلاینټ نسخه، د قاعدې ډول، د مخکښو یا پاکټونو لیست او دواړه لیدل شوې پایلې ولیکئ. همدا د پایلو جوړه ده چې بل انجینر ته وایي چې پالیسي غلط ترتیب شوې ده یا ترافیک هېڅکله د هغې نه و.