کیا VPN روٹ کیش آپ کی تبدیلی چھپا رہا ہے؟ تین چیزیں جانچیں

تبدیلی لاگو نہ ہونے پر روٹ کیش خالی کرنا پہلی عادت ہے، اور جدید لینکس پر یہ بیکار محنت ہے: عالمی IPv4 روٹ کیش برسوں پہلے ہٹا دیا گیا، اس لیے ip route show cache کچھ نہیں چھاپتا اور خالی کرنے کو کچھ نہیں۔ جو حالت آپ کو دھوکہ دیتی ہے وہ ایک طبقہ اوپر رہتی ہے: socket میں، NAT نقشہ میں، resolver میں یا نیٹ ورک مینیجر میں جس نے پرانا پروفائل دوبارہ لاگو کیا۔ تین سوال ان صورتوں کو الگ کرتے ہیں: غلط راستہ نئی روانی سے آ رہا ہے یا پرانے رابطے سے، آپ کا پلیٹ فارم روٹ کیش رکھتا ہے یا نہیں، اور حالت روٹنگ میں ہے یا اس کے اوپر۔ انٹرفیس ری سیٹ کرنے سے پہلے ان کے جواب دیں۔

جانچ ایک: پرانا راستہ نئی روانی سے آ رہا ہے؟

قائم شدہ رابطہ وہی روٹ رکھتا ہے جس کے ساتھ بنا تھا۔ اسی لیے ٹنل پر SSH سیشن روٹنگ جدول کی تبدیلی سے بچ جاتا ہے جبکہ نیا سیشن فوراً نیا راستہ لیتا ہے، اور اسی لیے «تبدیلی نے کچھ نہیں کیا» کا مطلب اکثر «پرانا socket اب بھی اسے تھامے ہوئے ہے» ہوتا ہے۔ پہلے سے کھلی ونڈو کے بجائے نئی عمل سے جانچیں۔

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

آخری کمانڈ وہ پتہ چھاپتی ہے جہاں نیا رابطہ واقعی پہنچا، اور حالت کی ونڈو پر بھروسہ کیے بغیر اصل راستہ دیکھنے کا یہی سستا طریقہ ہے۔ اس کا موازنہ اس ماخذ پتے سے کریں جو namespace یا انٹرفیس کو استعمال کرنا چاہیے تھا۔

اگر نئی روانی صحیح راستہ لے اور پرانی بحال نہ ہو تو روٹنگ دیکھنا بند کریں۔ روٹ صحیح تھا؛ سیشن پرانا تھا۔

جانچ دو: کیا آپ کا پلیٹ فارم روٹ کیش رکھتا ہے؟

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

دوسرے پلیٹ فارم مختلف ہیں، اور مشورے نقل کرنا یہیں غلط ہوتا ہے۔ Windows منزل کیش رکھتا ہے جسے آپ netsh interface ip delete destinationcache سے صاف کر سکتے ہیں۔ BSD اور macOS route -n get کے ذریعے ہر منزل کی تلاش دکھاتے ہیں، اور ان کے کیش اپنے شیڈول کے مطابق ختم ہوتے ہیں۔ ان میں سے کسی ایک پر چلنے والی کمانڈ لینکس پر کچھ بھی نہیں کرتی، اسی لیے وہی حل آزمانے والے آدھے لوگوں کو ناکام لگتا ہے۔

NAT یا conntrack جدول روٹ کیش نہیں، اگرچہ وہی علامت پیدا کرتا ہے۔ آپ کی تبدیلی سے پہلے ترجمہ شدہ روانی اپنا ترجمہ رکھتی ہے، اور روٹنگ پالیسی آگے بڑھنے کے بعد بھی conntrack -L اسے بہت دیر تک دکھاتا ہے۔ یہ پرانی حالت ہے، لیکن روٹ صاف کرنا اسے نہیں چھوئے گا۔

جانچ تین: حالت روٹنگ میں ہے یا اس کے اوپر؟

کچھ اور پڑھنے سے پہلے موجودہ تلاش پڑھیں: منزل کے لیے ip route get، پھر from اور ماخذ پتے کے ساتھ وہی کمانڈ، پھر ip rule show۔ اگر یہ تینوں آپ کے ارادے سے میل کھائیں تو روٹنگ درست کرنے کا طبقہ نہیں، اور پرانا مشاہدہ کہیں اور سے آیا ہے۔

تین عام مشتبہ روٹنگ کے اوپر بیٹھتے ہیں۔ نیٹ ورک مینیجر آپ کے روٹ ہٹانے کے چند سیکنڈ بعد محفوظ پروفائل سے اسے دوبارہ نصب کر سکتا ہے، اس لیے آپ کی تبدیلی واپس آتی لگتی ہے؛ جدول دوبارہ ترمیم کرنے سے پہلے nmcli connection show --active اور یونٹ کی حالت جانچیں۔ resolver کیش پرانا پتہ واپس کرتا ہے، جو کیش توڑنے والے اوزار سے وہی نام پوچھنے تک روٹنگ کی ناکامی جیسا لگتا ہے۔ کسی ایپلی کیشن کا کنکشن پول پرانی منزل کے ساتھ کام کرنے والا socket رکھتا ہے اور کرنل سے کبھی نیا فیصلہ نہیں مانگتا۔

تین جواب آپ کو کیا نتیجہ نکالنے دیتے ہیں

جواب اکٹھے کریں اور مرمت اکثر خود بول اٹھتی ہے۔ روٹ کیش نہ رکھنے والے پلیٹ فارم پر نئی روانی کا غلط راستہ لینا یعنی پالیسی واقعی غلط ہے، اس لیے وہ قواعد اور جدول پڑھیں جو ٹنل نے نصب کیا۔ پرانا سیشن رکے ہوئے ہونے کے دوران نئی روانی کا صحیح راستہ لینا یعنی مسئلہ ایپلی کیشن یا socket ہے۔ دونوں صورتوں میں صحیح روٹ کے ساتھ ٹوٹا مشاہدہ یعنی حالت روٹنگ کے اوپر ہے۔

عام ریفریش کی مخالفت کریں۔ نیٹ ورک اسٹیک دوبارہ شروع کرنا یا جس مشین کا ڈیفالٹ روٹ ٹنل ہے وہاں ہر روٹ ہٹانا ٹھیک وہی رابطہ کاٹ سکتا ہے جو آپ اسے درست کرنے کے لیے استعمال کر رہے ہیں، اور وہ ثبوت تباہ کرتا ہے جو بتاتا کہ کون سا طبقہ ناکام ہوا۔

اگر واقعی کچھ صاف کرنا ہو تو تشخیص سے میل کھانے والی سب سے چھوٹی چیز صاف کریں: ایک عمل کے socket، ایک conntrack اندراج، resolver کیش۔ پھر وہی نئی روانی کی جانچ دہرائیں اور لکھیں کہ کیا بدلا۔

اپنے نوٹس میں تینوں حالتیں الگ رکھیں

محفوظ کنفیگریشن، موجودہ تلاش اور مشاہدہ شدہ روانی تین مختلف حقائق ہیں، اور انہیں «کیش» میں یکجا کرنا ہی نقص کو دوبارہ پیدا کرنا مشکل بناتا ہے۔ روٹ کا مالک پروفائل یا یونٹ، ip route get کا آؤٹ پٹ، اور اصل رابطے کا ماخذ اور منزل لکھیں۔

ان کے ساتھ پلیٹ فارم اور کلائنٹ ورژن لکھیں، کیونکہ Windows منزل کیش صاف کرنے والا حل لینکس ہوسٹ پر لاگو ہونے والا حل نہیں، اور دونوں کے درمیان نقل کیا گیا طریقہ کار غلط سبق سکھاتا ہے۔ جب آپ مسئلہ کسی اور کو دیں، وہ تین سطریں اسے اندازہ لگانے کے بجائے ناکام حالت دوبارہ پیدا کرنے دیتی ہیں۔