صرف IPv6 کنکشن، IPv4 سروس: SOCKS پروکسی کو پل بننے دیں

آپ کو منزل کے ایڈریس خاندان کا ایڈریس نہ ہونے پر بھی اس تک پہنچا جا سکتا ہے، بشرطیکہ راستے میں کوئی چیز ریلے کرنے کو تیار ہو۔ ایپلیکیشن پروکسی سے جڑتی ہے، اور پروکسی منزل سے دوسرا کنکشن کھولتا ہے۔ یہ آزاد ایڈریس خاندانوں والے دو ساکٹ ہیں، اور کسی بھی پروٹوکول میں یہ لازم نہیں کہ وہ مطابقت رکھیں۔ یہ ایپلیکیشن سطح کا ریلے ہے، مقامی IPv4 راستہ نہیں، اور یہی فرق طے کرتا ہے کہ کیا کام کرے گا اور کیا نہیں۔ دونوں کو خلط کرنا ہی وہ طریقہ ہے جس سے لیپ ٹاپ کو IPv4 کنیکٹیویٹی والا بتایا جاتا ہے جبکہ اس کے پاس صرف ایک پروکسی ہوتا ہے۔

دو ساکٹ، دو ایڈریس خاندان

SOCKS5 درخواست منزل کو تین شکلوں میں سے ایک میں نام دیتی ہے: لفظی v4 ایڈریس، لفظی v6 ایڈریس، یا وہ نام جسے پروکسی حل کرے۔ درخواست بتاتی ہے کہ پروکسی کہاں جڑے، یہ نہیں کہ کلائنٹ سے پروکسی کنکشن کیسی دکھتی ہے۔

ان ایڈریس اقسام کو ایک پیغام کے اندر تین آزاد انتخاب سمجھیں۔ IPv6 کے ذریعے قابل رسائی پروکسی IPv4 منزل کا ساکٹ کھول سکتا ہے جب اس کے پاس فعال IPv4 اخراج ہو اور اس کی پالیسی درخواست کی اجازت دے۔ SOCKS5 تفصیل انہیں کلائنٹ کی ترسیل کے کسی حوالے کے بغیر بیان کرتی ہے۔

ایک کنٹرول شدہ SSH مثال

ایسا SSH میزبان لیں جسے استعمال کرنے کی آپ کو اجازت ہے، جو IPv6 پر جواب دیتا ہے اور خود صرف v4 پر موجود HTTPS سروس تک پہنچ سکتا ہے۔ OpenSSH کی متحرک فارورڈنگ لاگ ان سیشن کے v6 سے گزرنے کے دوران آپ کی مشین پر مقامی SOCKS سامع رکھتی ہے۔

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

اوپر دیا میزبان اور اکاؤنٹ مثالیں ہیں، اور loopback بائنڈنگ سامع کو اسی کمپیوٹر پر رکھتی ہے۔ دفتر کو بغیر توثیق والی پروکسی شیئر کرنے کی اجازت دینے کے لیے اسے وائلڈ کارڈ بائنڈنگ سے نہ بدلیں۔ ExitOnForwardFailure=yes اس لیے موجود ہے کہ ناکام فارورڈنگ سیشن ختم کرے، پس منظر میں خاموش کمانڈ چلتی نہ رہے۔

سیشن چلتے وقت درخواست ایسی دکھتی ہے:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

loopback کنکشن IPv4 انٹرنیٹ راستہ نہیں ہے۔ آپ کی مشین سے جو نکلتا ہے وہ v6 کے ذریعے لاگ ان سیشن ہے، اور منزل کا ساکٹ دور والا فریق کھولتا ہے۔ socks5h شکل ناموں کا حل بھی اسی فریق کو سونپتی ہے، جو اہم ہے جب کلائنٹ کے پاس اپنا IPv4 حل کنندہ راستہ نہ ہو۔

منزل دراصل کیا دیکھتی ہے

منزل ریلے کا اخراجی ایڈریس دیکھتی ہے۔ وہاں آپ کے لیپ ٹاپ کا کوئی ایڈریس نظر نہیں آتا۔ اس سروس پر ماخذ کی اجازت فہرست میں ریلے کا نام ہونا چاہیے۔ اس کے لاگ بھی ٹریفک کو ریلے ہی سے منسوب کریں گے۔ یہ آڈٹ سے پہلے تبدیلی ریکارڈ میں لکھیں، کیونکہ کلائنٹ ایڈریسز کے گرد بنی اجازت فہرست پہلی درخواست پر ہی ناکام ہوتی ہے۔

ریلے وہ جگہ بھی ہے جہاں گفتگو کے دونوں حصے نظر آتے ہیں، جو تشخیص کے دوران مفید خصوصیت ہے اور اگر ریلے بغیر پالیسی کے شیئر ہو تو بوجھ ہے۔

یہ DNS64 یا NAT64 نہیں ہے

DNS64 ایسے مصنوعی ریکارڈز سے جواب دیتا ہے جو v4 منزلوں کا متبادل بنتے ہیں، اور NAT64 مقررہ راستے پر پیکٹ دوبارہ لکھتا ہے۔ کوئی بھی یہ نہیں بتاتا کہ یہاں کیا ہوتا ہے، جہاں ایک ترسیلی گفتگو ختم ہوتی ہے اور دوسری شروع، اور کوئی مصنوعی ایڈریس نتیجہ کی وضاحت نہیں کرتا۔ اس لیے کامیاب درخواست آپ کے فراہم کنندہ کی ترجمہ سروسز کے بارے میں کچھ نہیں بتاتی، اور پروکسی اپنے اخراج پر عام NAT چلا سکتی ہے۔

دونوں طریقے ایک ہی نیٹ ورک میں موجود ہو سکتے ہیں، اس لیے جو قریب ترین سنائی دے وہ نہیں، جو آپ نے واقعی تصدیق کیا ہے اسے بیان کریں۔

وعدہ کرنے سے پہلے دائرہ کار جانیں

OpenSSH کی متحرک فارورڈنگ TCP کنکشنز لے جاتی ہے، من مانی IP ٹریفک نہیں، اس لیے UDP، ICMP اور پروکسی کو نظر انداز کرنے والے کسی بھی پروٹوکول کو الگ معاون ڈیزائن چاہیے۔ SSH میزبان کلید کی تصدیق، سرور کی فارورڈنگ پابندیاں اور HTTPS سرٹیفکیٹ کی توثیق برقرار رکھیں، کیونکہ پروکسی ایک اضافی قابل اعتماد شریک ہے، شناخت کی جانچ کمزور کرنے کی وجہ نہیں۔ اگر مقصد VPN کی بیرونی ترسیل پروکسی کے ذریعے لے جانا ہے، تو یہ ماننے کے بجائے کہ کوئی بھی SOCKS سامع اسے ریلے کر سکتا ہے، تصدیق کریں کہ دونوں سرے اس ترسیل کی حمایت کرتے ہیں۔

ان میں سے کچھ بھی کلائنٹ کو دوہرا اسٹیک نہیں بناتا، اور اس کی ضرورت بھی نہیں۔ یہ ایک ایپلیکیشن کو ایک ریلے کے ذریعے ایک سروس تک پہنچاتا ہے، جو چھوٹا دعویٰ ہے اور تصدیق کرنا کہیں زیادہ آسان ہے۔