کیا آپ کا VM میزبان کا VPN استعمال کرتا ہے؟ مہمان کے اندر سے جانچیں

آپ میزبان کا عوامی IP دیکھتے ہیں، اس پر VPN نظر آتا ہے، اور آپ نتیجہ نکالتے ہیں کہ VM محفوظ ہے۔ یہ نتیجہ اس جانچ سے ثابت نہیں ہوتا۔ مہمان کا اپنا روٹنگ جدول، اپنا حل کنندہ اور اپنے انٹرفیس ہوتے ہیں، اور میزبان کا اخراجی پتہ ان کے بارے میں کچھ نہیں بتاتا۔

جانچ مہمان کے اندر چلنی چاہیے، اور یہ بتانا چاہیے کہ کیا ناپا گیا۔

میزبان کے براؤزر سے نہیں، مہمان کے اندر سے شروع کریں

پہلے ہائپر وائزر کا نیٹ ورک موڈ ریکارڈ کریں: NAT، bridged، host-only یا macvtap۔ NAT موڈ میں میزبان مہمان کی ٹریفک کو روٹ کرتا ہے، اس لیے میزبان کی سرنگ لاگو ہو سکتی ہے یا نہیں، اس پر منحصر ہے کہ کلائنٹ راستے کیسے نصب کرتا ہے۔ bridged موڈ میں مہمان جسمانی LAN پر برابر کا شریک ہوتا ہے اور میزبان کی سرنگ غیر متعلق ہے۔ یہ دونوں موڈ ایک ہی میزبان ترتیب سے متضاد جواب دیتے ہیں۔

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

ایک درخواست کریں جس کی منزل آپ جانتے ہیں

ایسی خدمت کو بے ضرر درخواست بھیجیں جو اپنا دیکھا ہوا ماخذ پتہ بتاتی ہے۔ پھر اس منزل کے لیے مہمان کا اپنا روٹنگ فیصلہ دیکھیں: ip route get 203.0.113.5 وہ انٹرفیس اور گیٹ وے چھاپتا ہے جو مہمان استعمال کرے گا۔

اگر انٹرفیس مہمان کا معمول کا NIC ہے، تو وہ ٹریفک مہمان کے اندر سرنگ سے نہیں گزرتی۔

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

حل کنندہ کو الگ سے دیکھیں

بدلا ہوا اخراجی پتہ یہ نہیں بتاتا کہ وہ میزبان نام کس حل کنندہ نے سنبھالا۔ نام کو پلیٹ فارم کے مطابق آلے سے واضح طور پر پوچھیں، اور لکھیں کہ جواب کس سرور نے دیا۔ Split DNS کا مطلب ہے کہ حل کنندہ کا سوال اور روٹنگ کا سوال مختلف جواب رکھتے ہیں۔

وہ دونوں کسی بھی سمت میں مختلف ہو سکتے ہیں، اور یہی فرق اکثر اصل بگ ہوتا ہے۔

systemd میزبان پر resolvectl query جواب کے پیچھے موجود انٹرفیس اور DNS سرور کا نام لیتا ہے۔ پرانی ترتیبیں سرور کو dig کے آؤٹ پٹ میں دکھاتی ہیں۔ بہرحال، بات یہ دیکھنے کی ہے کہ جواب کس سرور نے دیا، نہ صرف یہ کہ جواب آیا یا نہیں۔

صرف کامیابی نہیں، ناکامی کی پالیسی بھی جانچیں

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

سرنگ گرنے پر جسمانی NIC پر واپس جانے والا مہمان بالکل وہی کر رہا ہے جس کی NAT موڈ اجازت دیتا ہے۔

موڈ اور دائرہ ریکارڈ کریں

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

اگر IPv4 سرنگ کے پیچھے چلا، تو یہ کہیں۔ اس دعوے کو IPv6، کسی اور نام کی جگہ یا کسی اور نیٹ ورک کے کسی اور VM تک نہ بڑھائیں۔