macOS پر VPN روٹ کی جانچ: کچھ بدلے بغیر route get

ایک صارف دفتر کے نیٹ ورک پر انٹرانیٹ تک پہنچتا ہے اور ٹنل سے نہیں، جبکہ ترتیبات اب بھی VPN کو منسلک دکھاتی ہیں۔ اُس لمحے روٹ ٹیبل میں ترمیم کرنا تشخیص کے لیے استعمال ہونے والے ریموٹ سیشن کے ٹوٹنے کا خطرہ رکھتا ہے۔ اس کے بجائے کرنل سے پوچھیں کہ ناکام ہوسٹ کے لیے وہ کون سا راستہ چنے گا۔ macOS کی route یوٹیلیٹی میں get عمل ہے جو ایک منزل کے لیے بالکل اسی کا جواب دیتا ہے، کچھ بدلے بغیر۔

ناکام ہوسٹ سے پوچھیں، ڈیفالٹ راستے سے نہیں

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

شکل یہ ہے کہ route -n get کے بعد پتہ: route -n get 203.0.113.10، جہاں دستاویزی پتہ آپ کے ہدف کی نمائندگی کرتا ہے۔ مجاز منزل اور مماثل پتہ خاندان استعمال کریں، کیونکہ IPv4 جواب صرف IPv6 والے وسیلے کے بارے میں کچھ نہیں کہتا۔ route یوٹیلیٹی کی دستاویز get عمل اور اُس کے چھاپے جانے والے فیلڈز کی وضاحت کرتی ہے۔

انٹرفیس اور گیٹ وے کو ثبوت کے طور پر پڑھیں

VPN جوڑنے سے پہلے استفسار چلائیں، پھر بعد میں دوبارہ، اور انٹرفیس اور گیٹ وے کی سطریں موازنہ کریں۔ اُن دو جوابوں کا فرق وہی ہے جو ٹنل نے واقعی بدلا، اور یہ پوری ٹیبل ڈمپ کرنے سے کہیں زیادہ مفید ہے۔ اگر دونوں بار انٹرفیس ایک جیسا ہو تو راستہ کبھی مسئلہ نہیں تھا اور آپ روٹنگ دیکھنا بند کر سکتے ہیں۔

نتیجہ نکالنے سے پہلے منزل، انٹرفیس، گیٹ وے اور استفسار کا وقت درج کریں۔ آؤٹ پٹ ثبوت ہے، تشخیص نہیں: تقسیم شدہ ٹنل کے ساتھ ایک ہی انٹرفیس ایک ہوسٹ کے لیے درست اور دوسرے کے لیے غلط ہو سکتا ہے۔

درست راستہ کام کرنے والی درخواست نہیں

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

روٹنگ ٹیبل کی فہرست کی اب بھی جگہ ہے: اسی طرح غیر متوقع ڈیفالٹ نظر آتا ہے۔ باقی ماندہ عام ڈیفالٹ یہ ثابت نہیں کرتا کہ VPN استعمال نہیں ہو رہا، کیونکہ زیادہ مخصوص اندراجات اُس پر غالب آتے ہیں۔

اینڈ پوائنٹ اور وسیلے کو الگ رکھیں

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

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

پہلے پڑھیں، بعد میں بدلیں

route add اور route delete کو پہلے دور سے باہر رکھیں۔ جس Mac کو آپ دور سے سنبھالتے ہیں، اُس پر ایک لاپرواہ ٹیبل ترمیم مشین تک واپسی کا راستہ ہی چھین سکتی ہے، اور تشخیص مکمل کرنے والا کوئی نہیں بچے گا۔ طے کریں درست راستہ کون سا ہے، لکھیں کہ تبدیلی کیسے واپس لی جائے، اور پھر ہی اُسے چلائیں۔ جانچ کی ایسی دم نہیں ہوتی۔

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