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

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

متعلقہ مضامین