Redsocks په loopback باندې اورېدل کوي مګر د VPN ترافیک هېڅکله نه رسیږي

یو تونل پورته کیږي، کاروونکی کولای شي ګیټوی ته ping وکړي، مګر هره ویب غوښتنه چې د پروکسي لارې څخه تیریږي مري۔ د redsocks پروسه روانه ده او پورټ یې اورېدل کوي، نو خدمت له ګیټوی څخه پخپله روغ ښکاري۔ هغه څه چې ناکام کیږي د تحویل مرحله ده: له تونل څخه لېږدول شوی پاکټ په هغه socket باندې نه کېني چې تاسو پیل کړی دی۔ د تړاو پته او د لېږدولو هدف باید سره سمون ولري، او معمولا یوازې یو له دوی څخه ګوري۔

لېږدول شوی پاکټ په حقیقت کې چېرته کېني

په ګیټوی باندې روڼ پروکسي د PREROUTING په nat جدول کې REDIRECT کاروي ترڅو د راغلي اړیکې منزل په سیمه‌ای پورټ باندې بیا ولیکي۔ بیالیکل شوی منزل هغه سیمه‌ای پته ده چې د هغه انټرفېس څخه چې پاکټ پرې راغلی ښکاري، نه د بل ځای پیل شوې پروسې د loopback پته۔ یوازې په 127.0.0.1 تړل شوی اورېدونکی هغه اړیکې مني چې لا دمخه په کوربه باندې سیمه‌ای وې، او کله چې د تونل ترافیک ناکام شي کار ته دوام ورکوونکی حالت دقیقا همدا دی۔ د کاروونکي خپله loopback دریمه پته ده او هېڅکله د ګیټوی د قاعده هدف نه ده۔

نو مخکې له دې چې پورتنۍ کچې اسنادو ته لاس ووهئ، دوه حقیقتونه ثابت کړئ: قاعده کومې سیمه‌ای پتې ته بیا لیکي، او پروکسي socket کومې پتې سره تړلی دی۔

اورېدونکی او د لېږدولو قاعده یوځای ولولئ

د socket جدول او nat قواعد په یوه تیریدو کې چاپ کړئ، ځکه هغه قاعده چې هغه پورټ ته اشاره کوي چې څوک یې مالک نه دی د هغې قاعدې په څېر ښکاري چې غلطې پتې ته اشاره کوي۔ sudo ss -ltnp | grep redsocks د تړاو پته او مالک پروسه ښیي۔ sudo iptables -t nat -S PREROUTING د REDIRECT هدف ښیي، او sudo iptables -t nat -L PREROUTING -v -n ښیي چې څه ورسره سمون درلود که نه۔

د REDSOCKS په نوم د کاروونکي ځنځیر ته ټوپ وهل هېڅ نه ترلاسه کوي پرته له دې چې هغه ځنځیر موجود وي او غوښتل شوي استثناوې او د REDIRECT کړنه ولېږدوي۔ د نوم دنده ترسره کوي داسې انګېرلو پرځای، هغه ځنځیر چې ټوپ ورته وهي د sudo iptables -t nat -S REDSOCKS سره ولولئ۔

بیا دوه ارزښتونه پرتله کړئ۔ که قاعده 12345 پورټ کې ګیټوی پتې ته لېږدوي او اورېدونکی 127.0.0.1:12345 راپور ورکوي، نو ناسمون یې پرته له نور تشخیص ناکامي تشریح کوي۔

تنګ وتړئ، بیا محدود کړئ چې څه ورته رسیږي

د پورتنۍ کچې بېلګې ترتیبول اورېدونکی په ښه دلیل loopback ته ږدي: روڼ پروکسي د هر هغه چا په استازیتوب اړیکې مني چې ورته رسیږي۔ تړاو 0.0.0.0 ته بدلول تحویل سمول او په عین وخت کې په هر انټرفېس باندې پورټ پرانیزي، چې د امنیت بدلون دی، نه بې‌طرفه ترمیم۔ غوره ده هغې ځانګړې سیمه‌ای پتې ته وتړئ چې لېږدول یې هدف دی، او په ناسم باوري انټرفېسونو کې پورټ بند وساتئ۔ که پراخه تړاو حتمي وي، د کوربه فایرول قاعده ورزیاته کړئ چې یوازې د تونل سرچینې حد او د ګیټوی خپل سیمه‌ای ترافیک ته اجازه ورکوي۔

د عامه انټرفېس باندې پورټ پرانیستل د لېږدول شوي VPN ترافیک لپاره هېڅکله اړین نه دي، ځکه اړیکه له بیالیکنې وروسته په سیمه‌ای ډول پای ته رسیږي۔ پروکسي د انټرنیټ سره مخ مه کوئ ترڅو سیمه‌ای لېږدول کار وکړي۔

دا د کاروونکي له نوي اړیکې سره ثابت کړئ

د ګیټوی shell څخه نه، بلکې له ریښتیني VPN کاروونکي څخه د نوي TCP اړیکې سره ازموینه وکړئ۔ په کاروونکي curl -sS -o /dev/null -w '%{http_code}\n' http://example.com لېږدول شوې لار له پیل څخه تر پای پورې تیریږي۔

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

په پای کې، په یاد ولرئ چې دا لار څه نه پوښي۔ عادي redsocks TCP لېږدول UDP، QUIC یا DNS په SOCKS ترافیک نه بدلوي، او خصوصي منزلونه معمولا ښکاره استثناوو ته اړتیا لري۔ بریالۍ سیمه‌ای ازموینه یوازې هغه loopback لار ثابتوي چې هېڅکله ستونزه نه وه۔