Redsocks loopback پر سنتا ہے مگر VPN ٹریفک کبھی نہیں پہنچتی

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

ری ڈائریکٹ شدہ پیکٹ دراصل کہاں اترتا ہے

گیٹ وے پر شفاف پراکسی PREROUTING میں nat جدول کے REDIRECT کو استعمال کرتے ہوئے آنے والے کنکشن کی منزل کو مقامی پورٹ پر دوبارہ لکھتی ہے۔ دوبارہ لکھی گئی منزل وہ مقامی پتہ ہے جو پیکٹ جس انٹرفیس پر آیا اسے نظر آتا ہے، نہ کہ کہیں اور شروع کیے گئے عمل کا loopback پتہ۔ صرف 127.0.0.1 سے منسلک سننے والا ایسے کنکشن قبول کرتا ہے جو پہلے ہی میزبان پر مقامی تھے، اور ٹنل ٹریفک ناکام ہونے کے دوران کام جاری رکھنے والا معاملہ بالکل یہی ہے۔ کلائنٹ کا اپنا loopback تیسرا پتہ ہے اور کبھی گیٹ وے کے قاعدے کا ہدف نہیں ہوتا۔

اس لیے اوپر کی سطح کے اسناد کو چھونے سے پہلے دو حقائق قائم کریں: قاعدہ کس مقامی پتے پر دوبارہ لکھتا ہے، اور پراکسی ساکٹ کس پتے سے منسلک ہے۔

سننے والے اور ری ڈائریکٹ قاعدے کو ساتھ پڑھیں

ساکٹ جدول اور 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 ٹریفک کے لیے کبھی ضروری نہیں، کیونکہ دوبارہ لکھنے کے بعد کنکشن مقامی طور پر ختم ہوتا ہے۔ مقامی ری ڈائریکٹ کام کرے اس کے لیے پراکسی کو انٹرنیٹ پر مت کھولیں۔

کلائنٹ سے نئے کنکشن کے ساتھ اسے ثابت کریں

گیٹ وے کے شیل سے نہیں، اصل VPN کلائنٹ سے نئے TCP کنکشن کے ساتھ جانچ کریں۔ کلائنٹ پر curl -sS -o /dev/null -w '%{http_code}\n' http://example.com ری ڈائریکٹ شدہ راستے کو شروع سے آخر تک چلاتا ہے۔

پھر تصدیق کریں کہ ناقابل اعتماد نیٹ ورک سے سننے والے تک براہ راست کنکشن اب بھی مسترد ہوتا ہے، اور پراکسی کا اپنا بالائی کنکشن اسی قاعدے سے دوبارہ نہیں پکڑا جاتا۔ تکرار پذیر پکڑ ایسی پراکسی کے طور پر ظاہر ہوتی ہے جو خود سے جڑتی ہے اور کبھی درخواست مکمل نہیں کرتی۔ پراکسی کی منزل استثنا مجموعے میں شامل کریں، یا اس کے باہر جانے والے پیکٹ نشان زد کریں تاکہ زنجیر انہیں چھوڑ دے۔

آخر میں یاد رکھیں کہ یہ راستہ کیا نہیں ڈھکتا۔ عام redsocks TCP ری ڈائریکٹ UDP، QUIC یا DNS کو SOCKS ٹریفک نہیں بناتا، اور نجی منزلوں کے لیے عام طور پر واضح استثنا درکار ہوتے ہیں۔ کامیاب مقامی جانچ صرف اس loopback راستے کو ثابت کرتی ہے جو کبھی مسئلہ نہیں تھا۔