ایا پروکسي د VPN له بیاځلي نښلولو وروسته لا هم په زاړه تونل پته کې دی؟

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

دوهمه ناکامي خطرناکه ده: تونل روان دی، پاڼې بارېږي، او یوازې د وتلو پته غلطه ده۔

له اورېدونکي پیل کړئ، نه له تونل

په لوبه کې درې پتې دي، او بیاځلی نښلول یوازې ځینې یې خوځوي۔ اورېدونکی هغه ځای دی چې ستاسو براوزر ورته اشاره کوي، معمولاً 127.0.0.1 یا د LAN پته، او دې ته پروا نه لري چې تونل بدل شوی۔ وتونکې ځایي سرچینه هغه ده چې لېږدونکی له کرنل غواړي د بل ګام په غږولو کې یې وکاروي، او هغه د تونل وسیلې سره تړلې ده۔ عامه وتل هغه دی چې ویب سرور ثبتوي، او کېدای شي د څو ګامونو په فاصله ژباړل شوې پته وي۔

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

د کانټینر او نومتشکیل ترتیبات دا انګېرنه په چوپتیا ماتوي۔ په یو شبکه نومتشکیل کې لېږدونکی نشي کولای په بل کې شته تونل وتړي، او د ترتیباتو سمون هیڅ اندازه دا نه جوړوي۔

له هر څه سمون مخکې څلور کتنې

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

1. تایید کړئ چې کارول شوی تونل هغه پروفایل دی چې پروکسي پرې جوړ شوی، نه دوهم پروفایل چې پخپله ونښلېد۔
2. په دې وسیله اوس مهال موجوده پته چاپ کړئ او د روان ترتیب پتې سره یې پرتله کړئ۔
3. د ډیسک فایل چې څه ادعا کوي هغه نه، له لېږدونکي وپوښتئ کومه سرچینه یې موندلې۔
4. تایید کړئ چې د لېږدونکي ترافیک واقعاً د هغه لارښوونې او فایر وال تګلارې تابع دی چې تاسو یې تمه لرئ۔

د وسیلې پته اسانه ده: ip -4 addr show dev tun0 اوسنۍ چاپوي، او ip -4 route get 1.1.1.1 ښیي چې کرنل د هغې موخې لپاره کومه انټرفېس ټاکي۔ هغه لېږدونکی چې دقیقه پته تړي کله چې پته ورکه شي په لوړ غږ ناکامېږي۔ هغه لېږدونکی چې وسیله تړي، یا بېرته ډیفالټ سرچینې ته راګرځي، کار ته دوام ورکوي او تویېږي، او همدا چوپه پایله ده۔

د اسنادو سره هغه خپرونه سمه کړئ چې تاسو یې چلوئ، نه د پلټنې لومړنۍ پایله۔ د Squid د وتلو پتې لارښوونه د v7 او پخوانیو لپاره مستنده ده، او v8 اسناد په روښانه ډول وایي چې لارښوونه هلته نشته، نو پرې جوړ شوی سکریپټ هغه پوله نه تېروي (وګورئ د Squid tcp_outgoing_address حواله)۔ له هر څه بیا بارولو مخکې د محصول خپل تحلیل کوونکی وکاروئ: squid -k parse تېروتنې راپور کوي او روان بهیر ته له لاس وهلو پرته وتل کوي۔

هر تونل شمېره کړئ او زاړه بدلونونه وغورځوئ

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

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

خلاص ساکټونه به نوې پتې پسې نه ځي

د لېږدونکي بیا تنظیمول د لا جوړو شوو اړیکو په اړه هیڅ نه وایي۔ دا چې به تشېږي یا مړه شي په محصول پورې اړه لري، نو د انګېرنې پرځای چلند وګورئ۔

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

نوی وتل په نوې غوښتنې سره ثابت کړئ

مهمه دا ده چې غوښتنلیک له فعالولو وروسته خلاص شي، نه ping او نه هغه پاڼه چې لا دمخه کیش شوې۔ له پروکسي څخه ریښتینی URL وغواړئ او هغه وتلو پته ولولئ چې لرې سر یې راپور کوي، بیا یې د کلینټ د تونل په اړه له خپل لید سره پرتله کړئ کله چې چمتو کوونکی یوه ښیي۔

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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