NAT یا bridged VM نیٹ ورکنگ: VPN ٹریفک کون اٹھاتا ہے؟

NAT مہمان ہوسٹ کی ٹنل اُسی وقت مانگتے ہیں جب کلائنٹ راستے کے مطابق ٹنل کرے؛ bridged مہمان خود راستہ بناتے ہیں۔ مہمان کو جانچیں، پھر موزوں موڈ چنیں۔

Bridged اور NAT ایک ہی مہمان کو آپ کے VPN سے جوڑنے کے دو طریقے نہیں ہیں؛ یہ طے کرتے ہیں کہ کوئی بھی ٹنل آنے سے پہلے مہمان کے پیکٹ کس کے ہیں۔ NAT موڈ میں ہائپر وائزر مہمان کی ٹریفک دوبارہ لکھتا ہے اور میزبان کی طرف کے کوڈ سے باہر بھیجتا ہے، اس لیے مہمان اسی راستے پر چلتا ہے جو میزبان اُس کوڈ کو دیتا ہے۔ bridged موڈ میں مہمان کو فزیکل سیگمنٹ پر اپنی لنک لیئر شناخت ملتی ہے اور اپنا ڈیفالٹ گیٹ وے خود چنتا ہے، جس سے میزبان کی ٹنل اُس کے لیے بے معنی ہو جاتی ہے، الا یہ کہ LAN روٹر ہی ٹنل کر رہا ہو۔ میں نے VM کو VPN پر موجود چیز سمجھنا چھوڑ دیا اور اِسے اِس سوال کی شکل میں دیکھنا شروع کیا کہ اُس مہمان کا ڈیفالٹ راستہ کدھر اشارہ کرتا ہے۔ نیچے دیا گیا ٹیسٹ فی موڈ چند منٹ لیتا ہے اور اندازے کے بغیر معاملہ طے کر دیتا ہے۔

NAT مہمان کو ہائپر وائزر کوڈ کے پیچھے رکھتا ہے، جہاں میزبان کے راستے لاگو ہوتے ہیں

VirtualBox میں NAT مہمان 10.0.2.0/24 میں، 10.0.2.2 پر فرضی گیٹ وے، 10.0.2.3 پر DNS پراکسی کے ساتھ رہتا ہے اور فزیکل نیٹ ورک تک اُس کا اپنا کوئی راستہ نہیں ہوتا۔ باہر جانے والے پیکٹ NAT انجن لیتا ہے، اُنہیں اس طرح دوبارہ لکھتا ہے کہ ماخذ میزبان ہو، اور میزبان کے IP اسٹیک کو دے دیتا ہے۔ وہاں سے مہمان کی ٹریفک میزبان کا بہاؤ ہے، اور راستے کی تلاش منزل کے مطابق ہوتی ہے: مکمل ٹنل والا کلائنٹ جو میزبان پر 0.0.0.0/1 اور 128.0.0.0/1 لگاتا ہے، VM کے وجود سے بے خبر اُسے پکڑ لیتا ہے۔ VirtualBox کے نیٹ ورکنگ پر Oracle کا باب یہ ڈیفالٹ اقدار بتاتا ہے، اگر آپ اپنے بلڈ پر پتوں کی تصدیق کرنا چاہیں۔

libvirt کا ڈیفالٹ نیٹ ورک 192.168.122.0/24 سے اُسی جگہ پہنچتا ہے، جہاں dnsmasq لیز تقسیم کرتا ہے اور میزبان سب نیٹ کو ماسک کرتا ہے، چنانچہ مہمان کے پیکٹ پھر میزبان کے روٹنگ فیصلے تک پہنچتے ہیں۔ استثنا وہ کلائنٹ ہے جو ٹریفک راستے کے بجائے پروسیس کے مطابق چنتا ہے۔ اگر سپلٹ ٹنل کی فہرست میں صرف آپ کا براؤزر ہو، تو NAT انجن اُس فہرست میں نہیں ہے، اور مہمان بغیر ٹنل کے مشین سے نکل جاتا ہے جبکہ میزبان کا براؤزر اب بھی ڈھکا ہوا دکھائی دیتا ہے۔ ایک ہی سب نیٹ، اُلٹا نتیجہ۔

Bridged مہمان کو فزیکل LAN پر اُس کا اپنا مقام دیتا ہے

bridged مہمان کو حقیقی اڈاپٹر سے منسلک فرضی NIC ملتا ہے، اپنا MAC پتہ ملتا ہے، اور فزیکل نیٹ ورک سے DHCP لیز لیتا ہے۔ اُس کا ڈیفالٹ گیٹ وے LAN روٹر ہے، ہائپر وائزر نہیں، اور اُس کے فریم اُسی اڈاپٹر سے تار پر جاتے ہیں۔ میزبان کی ٹنل کے راستے میزبان کی جدول میں رہتے ہیں اور کبھی نہیں دیکھے جاتے، کیونکہ مہمان کے فریم کبھی میزبان کے IP اسٹیک میں داخل نہیں ہوتے۔

یہ دونوں طرف کاٹتا ہے۔ mDNS اور SMB براؤزنگ کام کرنے لگتی ہے کیونکہ مہمان LAN کی براڈ کاسٹ ٹریفک دیکھتا ہے، اور مہمان درمیان میں میزبان فائر وال کے بغیر اُسی سیگمنٹ کی دوسری مشینوں سے قابلِ رسائی ہو جاتا ہے۔ Bridging موجودہ ٹنل سے مہمان کو دھکیلنے کا طریقہ بھی نہیں ہے: VM کو میزبان کے WireGuard یا OpenVPN انٹرفیس سے جوڑنا ایسا کام نہیں جو VirtualBox یا libvirt آپ کے لیے کرے۔ اگر bridged مہمان کو ٹنل کرنا ضروری ہو، تو ٹنل کو اُسی LAN میں کہیں ختم ہونا چاہیے۔

وہ ٹیسٹ جو بحث ختم کرتا ہے

دونوں موڈز میں وہی جانچ چلائیں اور جواب لکھ لیں:

  • میزبان پر، curl -s https://ifconfig.me عوامی v4 پتہ دیتا ہے۔
  • مہمان میں، وہی کمانڈ، اور مزید ip route Linux پر یا Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windows پر ڈیفالٹ گیٹ وے کے لیے۔
  • حل کنندہ کی شناخت: resolvectl status یا cat /etc/resolv.conf مہمان میں، تاکہ دیکھ سکیں کہ یہ 10.0.2.3 کی طرف اشارہ کرتا ہے یا LAN سرور کی طرف۔
  • پتوں کی فیملی: ip -6 addr show scope global اور ایک v6 درخواست، کیونکہ v4 ٹنل اُس عالمی v6 پتے کے بارے میں کچھ نہیں بتاتی جو مہمان کے پاس ہو سکتا ہے۔

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

دو اشارے جھوٹ بولتے ہیں۔ کامیاب ping رسائی ثابت کرتا ہے، اخراج کا راستہ نہیں۔ اور DNS کا جواب 10.0.2.3 پراکسی سے میزبان کے حل کنندہ کے ذریعے دیا جا سکتا ہے جبکہ TCP کوئی دوسرا راستہ لے رہا ہو، اسی طرح وہ صفحہ ملتا ہے جو لوڈ ہو جاتا ہے اور وہ لاگ اِن جو کبھی مکمل نہیں ہوتا۔

کون سا موڈ کام کے لیے موزوں ہے

موڈ راستے کا فیصلہ ہے، اس لیے اُسے عادت کے بجائے ضرورت سے چنیں:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

پہلی سطر وہ جگہ ہے جہاں لوگ پھنستے ہیں: NAT اور میزبان پر مکمل ٹنل کلائنٹ مہمان کو واقعی ڈھانپ لیتے ہیں، مگر صرف اُس وقت تک جب تک کلائنٹ راستے کے مطابق ٹنل کرے اور میزبان کا اپ لنک وہی ٹنل ہو۔ کلائنٹ کو صرف براؤزر کی اجازت والی فہرست پر منتقل کریں، ڈھانپنا کہیں بھی کوئی خرابی ظاہر کیے بغیر غائب ہو جائے گا۔ چوتھی سطر اُلٹی غلطی ہے، سہولت کے لیے bridged کیا گیا مہمان جو خاموشی سے دفتر کے LAN پر SMB یا SSH کا جواب دینے لگتا ہے۔

وہ ناکامیاں جن کا الزام VPN پر ڈالا جاتا ہے

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

Wi-Fi پر bridging دوسرا کلاسیک ہے۔ ایکسس پوائنٹس غیر ملکی ماخذ MAC والے فریم شاذ و نادر ہی آگے بھیجتے ہیں، اس لیے wlan0 پر بریج یا فوراً ناکام ہو جاتا ہے، یا اُس وقت تک چلتا ہے جب تک AP پر کلائنٹ تنہائی اُسے گرانا شروع نہ کرے۔ VirtualBox پھر بھی وائرلیس اڈاپٹر اپنی فہرست میں پیش کرے گا۔ اگر میزبان Wi-Fi پر ہے اور مہمان کو bridged کرنا ہے، تو اندازے کے بجائے جانچ کا منصوبہ بنائیں۔

MTU تیسرا ہے۔ bridged مہمان LAN کا 1500 بائٹ MTU برقرار رکھتا ہے، اور اگر وہ اپنا WireGuard کلائنٹ 1420 پر چلائے، تو بڑے TLS ہینڈ شیک رُک جاتے ہیں جبکہ چھوٹی درخواستیں گزر جاتی ہیں۔ NAT کے تحت میزبان کی ٹنل کا MTU میزبان کا مسئلہ ہے، مگر مہمان اب بھی 1500 کو مانتا ہے، اور don't-fragment بٹ والا UDP اسی طرح بلیک ہول میں گرتا ہے۔

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

موڈ، وہ میزبان انٹرفیس جو بریج استعمال کرتا ہے، مہمان کا ڈیفالٹ گیٹ وے، اُس کا حل کنندہ، اور اُس کے v4 اور v6 اخراجی پتے درج کریں۔ یہی ریکارڈ اگلی ناکامی کو سستا بناتا ہے: جب لیپ ٹاپ ڈاک سے Wi-Fi پر جاتا ہے، bridged مہمان بریج کے ساتھ دوسرے فزیکل اڈاپٹر پر چلا جاتا ہے اور دوسرے سب نیٹ میں دوبارہ لیز لے سکتا ہے، جبکہ NAT مہمان اپنا 10.0.2.x پتہ رکھتا ہے اور خاموشی سے مختلف اپ لنک ورثے میں لے لیتا ہے۔

ٹکٹ بند کرنے سے پہلے اِن میں سے ہر ایک کی تصدیق کریں:

  • مہمان کا اخراجی پتہ میزبان کے اخراجی پتے سے مختلف ہے، یعنی وہ میزبان کی ٹنل پر نہیں ہے۔
  • حل کنندہ 10.0.2.3 پراکسی یا LAN سرور ہے، اور آپ جانتے ہیں کہ کس نے جواب دیا۔
  • مہمان میں کوئی عالمی v6 پتہ نہیں، اگر ٹنل کا ڈیزائن صرف v4 ہے۔
  • میزبان کی ٹنل بند ہونے پر مہمان براؤزنگ روک دیتا ہے، یا اب آپ جانتے ہیں کہ وہ کبھی اُس پر منحصر نہیں تھا۔
  • مہمان وہ LAN براڈ کاسٹ ٹریفک نہیں دیکھتا جو اُسے دیکھنے کا کوئی حق نہیں۔

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