VPN میزبان پر چلائیں یا VM کے اندر؟ فیصلے کی رہنمائی

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

کلائنٹ کو چھونے سے پہلے مالک کا فیصلہ کریں

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

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

جواب VM کے نام کے ساتھ ایک سطر میں لکھیں: guest-owned یا host-owned۔ چھ مشینوں کی لیب میں وہ نوٹ نیچے کے کسی بھی مرحلے سے زیادہ وقت بچاتا ہے، کیونکہ یہ آپ کو ایسے ٹنل کی چھان بین سے روکتا ہے جو اس مشین میں کبھی تھا ہی نہیں جس میں آپ نے لاگ ان کیا۔

WSL1 اور WSL2 متضاد صورتیں ہیں

WSL1 مجازی مشین نہیں ہے، اس لیے جگہ کا سوال زیادہ تر اڑ جاتا ہے۔ اس کی Linux بائنریاں ترجمے کی تہہ کے ذریعے Windows کے نیٹ ورک اسٹیک کے سامنے چلتی ہیں، اور Linux VPN کلائنٹ کے پاس ترتیب دینے کے لیے کوئی خودمختار انٹرفیس نہیں ہوتا۔ جو کام کرتا ہے وہ Windows کی جانب ٹنل ہے، اور تقسیم کچھ بھی ملکیت میں لیے بغیر نتیجہ استعمال کرتی ہے۔

WSL2 اس کے برعکس ہے۔ یہ Hyper-V مجازی سوئچ کے پیچھے ایک ہلکے یوٹیلیٹی VM میں حقیقی کرنل چلاتا ہے، اور اس کا پتہ کی جگہ میزبان کی جانب کے اڈاپٹر سے NAT ہوتی ہے۔ اس لیے تقسیم کے اندر Linux کلائنٹ ایسے برتاؤ کرتا ہے جیسے کسی جسمانی Linux باکس پر: یہ tun0 یا wg0 بناتا ہے، اپنے راستے لگاتا ہے، اور کام کرتا ہے۔ ناکامی میزبان کی جانب رہتی ہے۔ جب Windows VPN کلائنٹ ایسی پالیسی کے ساتھ جڑتا ہے جو مقامی نیٹ ورکوں پر ٹریفک روکتی ہے، تو یہ WSL2 ذیلی نیٹ ورک کو ناقابلِ اعتماد مقامی نیٹ ورک سمجھ کر NAT راستہ کاٹ دیتا ہے۔ پھر تقسیم DNS اور باہر کی رسائی کھو دیتی ہے جبکہ اس کا اپنا ٹنل ابھی صحت مند ہے: wg show ہاتھ ملانے کی اطلاع دیتا ہے، ip route درست دکھتا ہے، اور curl لٹک جاتا ہے۔

کون سی اصلاح استعمال کر سکتے ہیں یہ Windows بلڈ پر منحصر ہے۔ پرانی والی WSL ذیلی نیٹ ورک کے لیے میزبان کلائنٹ میں ایک استثنا ہے، جو کلائنٹ کی مقامی نیٹ ورک یا منقسم ٹنل ترتیبات کے تحت شامل کیا جاتا ہے۔ نئی والی، ان Windows 11 بلڈز پر جو اس کی حمایت کرتے ہیں، آئینہ نیٹ ورکنگ ہے: %UserProfile%\.wslconfig کے [wsl2] حصے میں networkingMode=mirrored رکھیں، wsl --shutdown چلائیں، اور تقسیم نجی NAT ذیلی نیٹ ورک کے بجائے میزبان کے انٹرفیس بانٹ دے گی۔ آئینہ موڈ localhost اور آنے والے پورٹس کا برتاؤ بھی بدلتا ہے، اس لیے اسے ٹوگل نہیں بلکہ منتقلی سمجھیں۔

NAT، پل اور میزبان کیا دیکھ سکتا ہے

NAT کے تحت مہمان کے ٹنل پیکٹ VPN سرور کے عوامی پتے پر بھیجے جاتے ہیں اور خفیہ کردہ UDP یا TCP کی صورت میں میزبان کے اڈاپٹر سے باہر نکلتے ہیں۔ میزبان ایک بہاؤ اور اس کی بائٹ گنتی دیکھتا ہے، اندر کے منازل کے بارے میں کچھ نہیں۔ پل والے اڈاپٹر کے تحت مہمان کی جسمانی LAN پر اپنی تہہ 2 کی شناخت ہوتی ہے، اپنا DHCP لیز لیتا ہے، اور MAC پر مبنی کسی بھی پالیسی کے سامنے دوسرے آلے کی طرح دکھتا ہے۔ کوئی بھی موڈ میزبان کو ٹنل کا مواد پڑھنے نہیں دیتا؛ پل والا مہمان اپنے گرد کے نیٹ ورک کے لیے کہیں زیادہ نظر آتا ہے۔

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

رہنمائی: رکھیں، ترتیب دیں، ثابت کریں

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

1. ip route get 1.1.1.1 اگر tun0 یا wg0 واپس دے تو مہمان کی ملکیت، اور نجی اگلی چھلانگ کے ساتھ eth0 دے تو میزبان کی ملکیت۔
2. resolvectl query example.com، یا جہاں مہمان کوئی حل کنندہ خدمت نہیں چلاتا وہاں /etc/resolv.conf پڑھیں۔ جو ٹنل ٹریفک لے جاتا ہے مگر DNS نہیں، وہی سب سے عام آدھی ترتیب شدہ حالت ہے۔
3. اخراج کا موازنہ کریں: مہمان میں curl -4 -s https://ifconfig.me اور میزبان پر curl.exe -4 -s https://ifconfig.me۔ مختلف پتے کا مطلب ہے مہمان ٹنل کا مالک ہے، اور VPN پر میزبان کے ساتھ گھر کا ISP دکھانے والا مہمان وہ صورت ہے جس میں کچھ بھی ورثے میں نہیں ملا۔
4. دونوں کو -6 کے ساتھ دہرائیں۔ صرف v4 والا ٹنل v6 لیک کرتا ہے جب تک کلائنٹ اسے نہ روکے یا راستہ نہ دے، اور بہت سے کلائنٹ طے شدہ طور پر v6 جسمانی انٹرفیس پر ہی چھوڑ دیتے ہیں۔

کئی مہمان ایک ٹنل بانٹنے والے میزبان گیٹ وے ڈیزائن میں میزبان کو فارورڈ اور ترجمہ کرنا پڑتا ہے۔ Linux میزبان پر وہ تین حصے ہیں، اور ان میں سے کوئی ایک نہ ہو تو مہمان خاموشی سے اپنے سادہ راستے پر لوٹ جاتا ہے:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

WireGuard کی جانب میزبان ساتھی کے AllowedIPs میں مہمانوں کا ذیلی نیٹ ورک شامل ہونا چاہیے، مثلاً 192.168.122.0/24، ورنہ واپسی پیکٹ کبھی نہیں پہنچیں گے اور ترتیب فائر وال کے مسئلے جیسی لگے گی۔ Windows میزبان Internet Connection Sharing یا Hyper-V سوئچ پر NAT قاعدے سے وہی نتیجہ پاتا ہے، اور اسے بھی وہی واپسی راستے کی جانچ درکار ہے۔

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

دو ٹنل، دو مہمان، اور ان کے درمیان تصادم

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

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

تصدیق کریں، پھر بحالی مالک کے پاس ہی رکھیں

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

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