VPN جڑنے پر Vagrant VM غائب ہو جاتا ہے: ٹوٹا راستہ کس کا

مشین نے ایک منٹ پہلے جواب دیا تھا، VPN جڑا، اور اب وہی پتہ وقت ختم کرتا ہے۔ تین خرابیاں یہ علامت پیدا کرتی ہیں، اور وہ الگ مشینوں پر رہتی ہیں۔ میزبان نجی نیٹ ورک کا راستہ کھو سکتا ہے، مہمان کی NAT رینج اب سرنگ کے اعلان کردہ رینج سے ٹکرا سکتی ہے، یا مکمل سرنگ میزبان کے ہر راستے کی ملکیت لے سکتی ہے۔ کوئی بھی ترتیب بدلنے سے پہلے معلوم کریں کہ کون سی ہوئی، کیونکہ ہر اصلاح کہیں اور رہتی ہے۔

راستہ دیکھیں، مشین نہیں

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

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

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

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

جڑنے سے پہلے اور بعد میں میزبان کا جدول پڑھیں

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

مہمان کے سابقے کے راستے کے ساتھ اڈاپٹر اور ان کے میٹرک چھاپیں۔ آؤٹ پٹ کا وہ جوڑا ملکیت کا سوال ایک نظر میں حل کرتا ہے۔

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

اگر راستہ بدلا مگر اڈاپٹر کا میٹرک نہیں، تو کلائنٹ نے مسابقتی راستہ نصب کیا۔ اگر میٹرک بدلا، تو کلائنٹ نے اڈاپٹر کی ترتیب بدلی۔ دونوں قابل اصلاح ہیں، اور دونوں الگ جگہوں پر ٹھیک ہوتے ہیں۔

جب مہمان کی NAT رینج ہی ٹکراؤ ہو

VirtualBox NAT بطور طے شدہ 10.0.2.0/24 استعمال کرتا ہے، اور وہی رینج دھکیلنے والی سرنگ مہمان کو وہ ٹریفک اصل منزل کی بجائے اپنے NAT گیٹ وے پر بھیجنے پر مجبور کرتی ہے۔ پیکٹ کبھی میزبان سے باہر نہیں جاتا، اس لیے دوسری طرف کا کوئی فائر وال لاگ اسے نہیں دکھائے گا۔ Docker Machine کے صرف-میزبان منصوبے میں بھی اسی قسم کا تصادم ہے، اور اس منصوبے کو بدلنے کے لیے مشین کو اس کے سرٹیفکیٹس سمیت دوبارہ بنانا پڑ سکتا ہے۔

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

مشین بننے کے وقت نئی رینج مقرر کریں، یا اسے بدل کر دوبارہ لوڈ کریں، پھر مہمان سے ناکام کنکشن دوبارہ جانچیں۔ مہمان کا اپنا جدول ہی اہم منظر ہے۔

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

کلائنٹ سے لڑے بغیر راستہ بحال کریں

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

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

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

اصلاح کو دونوں طرف جانچیں

تبدیلی کے بعد تین راستے جانچیں: میزبان سے مہمان، مہمان سے کارپوریٹ میزبان، اور مہمان سے انٹرنیٹ۔ جو اصلاح ایک بحال کرے اور دوسرا توڑ دے وہ مرمت کے بھیس میں ترتیب کی تبدیلی ہے۔ موازنہ برابر کا برابر ہو، اس لیے تبدیلی سے پہلے جمع کیے گئے وہی آؤٹ پٹ پکڑیں۔

بدلے ہوئے انٹرفیس، میٹرک اور راستے کو وقت کے ساتھ درج کریں، تاکہ اگلی بار تعمیر نو نہیں بلکہ تلاش ہو۔ وہ نوٹ لمبی ٹکٹ تھریڈ سے زیادہ قیمتی ہے۔

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

جب میزبان دوبارہ مہمان تک پہنچے اور مہمان LAN تک پہنچے، تو آپ نے شروع کیا راستہ بحال کر لیا۔ اگر ان میں سے صرف ایک چلے، تو باقی خرابی دوسرے مالک کے علاقے میں ہے، اور فرق بتاتا ہے کہ کون سا علاقہ ہے۔