ولې ستاسو د split tunnel قاعده له یو خدمت سره سمون موندل بند کړل
قاعده یو پریفکس ټینګوي او خدمت ځای بدل شوی. هغه مقصد ولولئ چې اپلیکیشن واقعاً یې کاروي، بیا د استثنا پراخولو پر ځای میکانیزم سم کړئ.
Split tunneling معمولاً په یوه له دوو لارو ناکامېږي۔ یا هغه ټرافیک چې باید د تونل دننه وي، د هغه شاوخوا ځي، یا هغه ټرافیک چې باید دباندې پاتې شي، دننه کش کېږي۔ د زاړه قاعدې ناکامي لومړی ډول دی، او ډېره ګډوډونکې ده، ځکه قاعده په هماغه توګه پلي کېږي لکه څنګه چې لیکل شوې۔ هغه څه چې بدل شوي مقصد دی: خدمت اوس په هغه پته ځواب وایي چې قاعدې هېڅکله نوم نه دی ایښی، او په تونل کې هېڅ شی غلط نه دی۔
قاعده څه ټینګوي او DNS څه بېرته راولي
د split tunnel قاعده د مقصدونو په اړه یو ثابت بیان دی، چې معمولاً د پریفکس، لارې یا د پتوو د لیست په توګه بیانېږي۔ دا د لېږلو په وخت کې د بنډل د مقصد پر وړاندې ارزول کېږي۔ د کوربه نوم یو پلټنه ده چې د ژوند مودې او کیش سره د پتوو یوه ټولګه بېرته راولي، او ځواب کېدای شي د resolver، د پوښتنې ډول او د دقیقې له مخې توپیر ولري۔
هغه دوه شیان هېڅکله له یو بل سره خبرې نه کوي۔ قاعده د هغه پریفکس سره سمون ته دوام ورکوي چې ورته ورکړل شوی، خدمت هغه پته بدلوي چې ورکوي یې، او د دوی ترمنځ تشه په چوپتیا پراخېږي۔ ځکه نښه د ترلاسه کوونکي تر مهاجرت یا د سند تر نوي کولو وروسته ښکاري، نه د ترتیباتو تر بدلون وروسته۔ چا تونل نه دی سم کړی، نو څوک تونل ته نه ګوري، او تشخیص د سیاست پر ځای د اپلیکیشن په لور ځي۔
درې لارې چې سمون پکې ماتېږي
روښانه پېښه لېږدول شوی خدمت دی: اپراتور ورته نوې پته ورکړه، DNS پسې وځي، او استثنا پسې نه ځي۔ دوهمه هغه د پتوو کورنۍ ده چې قاعدې هېڅکله نه ده پوښلې، چې هغه وخت پېښېږي کله چې نوم هغه AAAA ریکارډونه بېرته راوړي چې یوازې د IPv4 لپاره استثنا ورته پام نه کوي۔ درېیمه د resolver توپیر دی: کورني او عامه لید کېدای شي یو نوم ته بېلې پتې بېرته راوړي، نو هغه پته چې ستاسو اپ کاروي هغه نه ده چې تاسو یې ازموینه کړې۔
کیش شوې اړیکه څلورمه بڼه ده او اسانه ده چې له پامه ونه غورځېږي۔ اپلیکیشن کېدای شي لا هم له هغې پتې سره خبرې کوي چې یو ساعت دمخه یې حل کړې وه، چې مانا دا ده ستاسو نوې پلټنه او د هغې پرانیستې socket د دې په اړه سره نه جوړېږي چې خدمت چېرته اوسیږي۔
هغه مقصد ولولئ چې اپلیکیشن واقعاً یې کاروي
د براوزر ټب نه، بلکې عملیاتي سیستم او د socket جدول وپوښتئ۔ پلټنه ځواب وایي چې نوم اوس څه ته حل کېږي، او د socket جدول هغه پته ښیي چې پروسه ورسره نښلول شوې، کېدای شي زړه وي۔ تیوري جوړولو دمخه دواړه وچلوئ، ځکه د دوی ترمنځ توپیر په نږدې نیمایي پېښو کې پخپله ځواب دی۔
getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40
بیا د هغه څه سره یې پرتله کړئ چې قاعده یې پوښي۔ که اوسنۍ پته له استثنا بهر وي او غوښتنه لا هم ناکامېږي، تاسو لامل موندلی پرته له دې چې د تونل ترتیباتو ته لاس ووړئ۔ که اپلیکیشن له قاعدې سره سمون لرونکې پتې ته نښلول شوی وي او غوښتنه لا هم ناکامېږي، ستونزه د تونل هاخوا ده او دا غلطه څېړنه ده۔
میکانیزم سم کړئ، نه نښه
که محصول د ډومین پر بنسټ ساتل شوې لګښت ملاتړ کوي، هغه وکاروئ او د هغې مستنده تازه کولو او حد چلند تعقیب کړئ۔ دا ثابته اټکل د ساتل شوي ځواب سره بدلوي، په دې بیه چې د دې بڼې د مستند په توګه د کار کولو پورې تړلی یاست۔
که ډیزاین په ثابته لیست تکیه کوي، ورته یو مالک او د تازه کولو پلان ورکړئ۔ پلان باید ووایي چې پته څنګه موندل کېږي، بدلون څوک تصویبوي او لیست څومره ژر د ترلاسه کوونکي مهاجرت تعقیبوي۔ بې مالکه لیست د معلوم لامل سره راتلونکې ګډوډي ده۔
استثنا مه پراخوئ یوې لویې ګاونډې شبکې ته یوازې د دې لپاره چې هرهغه پته ونیسئ چې په لنډه ازموینه کې مو لیدلې۔ دا ترمیم نه دی؛ دا د امنیت د پولې تلپاتې بدلون دی، او تر څو چې قاعده شته، بې اړیکې خدمتونه به په چوپتیا تونل ته ورځي۔
د نیت دواړه نیمايي تایید کړئ
د split tunnel ډیزاین دوه نیتونه لري، او ترمیم باید دواړه وساتي۔ ساتل شوی خدمت باید له تونل څخه تېر شي، او ایستل شوې ډلې باید د هغه شاوخوا تګ ته دوام ورکړي۔ ترمیم شوې پتې ته نوې اړیکه ازموئ، بیا هغه څه ازموئ چې باید دباندې پاتې شي۔
curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'
نوې پته، غوره شوی میکانیزم او نېټه ولیکئ۔ همدا یادښت بل کس له دې پایلې مخنيوی کوي چې VPN خپل ترتیبات په ناڅاپي ډول له پامه غورځولي۔