میزبان کی ٹریفک کو VM میں VPN کے ذریعے روٹ کرنا: چھ جانچیں

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

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

جانچ 1: میزبان کو ایسا لنک چاہیے جسے وہ پتہ دے سکے

میزبان کے پاس مہمان کے دوسرے اڈاپٹر والے ہی سابقے میں انٹرفیس ہونا چاہیے۔ VirtualBox میں host-only، VMware Workstation میں host-only یا حسبِ ضرورت VMnet، QEMU/KVM میں اندرونی پل یا tap ڈیوائس، اور Hyper-V میں Internal سوئچ سب اہل ہیں۔ مہمان 192.168.56.2، میزبان 192.168.56.1، سابقہ 192.168.56.0/24 وہ ترتیب ہے جو میں لیب میں استعمال کرتا ہوں۔

QEMU کی صارف موڈ نیٹ ورکنگ (-netdev user، طے شدہ SLIRP بیک اینڈ) اور VirtualBox NAT اس جانچ میں مکمل ناکام ہوتے ہیں۔ مہمان کے پیکٹ میزبان پر پراکسی عمل تک پہنچتے ہیں، اس لیے میزبان کو کبھی ایسی ڈیوائس نظر نہیں آتی جو مہمان کے پتے اٹھائے ہوئے ہو اور روٹ دکھانے کے لیے کچھ نہیں ہوتا۔ Hyper-V کا Default Switch بھی وہی کہانی ہے۔ اگر میزبان سے ping 192.168.56.2 ناکام ہو تو رکیں: بعد میں شامل کیا گیا کوئی روٹ اسے درست نہیں کرے گا۔

جانچ 2: مہمان فارورڈ کرتا ہے اور ترجمہ کرتا ہے

میزبان سے آنے والے پیکٹ host-only ماخذ پتے اور اندرونی منزل کے ساتھ آتے ہیں، اس لیے مہمان کو انہیں فارورڈ کرنا اور پھر اپنی سرنگ کے پتے کے پیچھے چھپانا ہوتا ہے۔ Linux مہمان میں اس کا مطلب فارورڈنگ، FORWARD accept کی جوڑی، اور سرنگ کی طرف source NAT ہے:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE قاعدہ وہی حصہ ہے جو لوگ چھوڑ دیتے ہیں۔ کارپوریٹ راؤٹر شاذ و نادر ہی جانتے ہیں کہ 192.168.56.0/24 موجود ہے؛ قاعدے کے ساتھ اندرونی سرور مہمان کا سرنگ پتہ دیکھتے ہیں اور اس کا جواب دیتے ہیں، اور جواب مہمان تک واپس راستہ پا لیتا ہے۔

Windows مہمان زیادہ بھدا ہے۔ SYSTEM\CurrentControlSet\Services\Tcpip\Parameters کے تحت IPEnableRouter=1 بغیر ترجمے کے فارورڈنگ آن کرتا ہے، اس لیے یہ صرف وہاں چلتا ہے جہاں کارپوریٹ روٹنگ پہلے ہی آپ کے host-only سابقے کی طرف واپس اشارہ کرتی ہے۔ Internet Connection Sharing ترجمہ کرتا ہے، مگر مشترکہ اڈاپٹر کو 192.168.137.1 پر دوبارہ نمبر دیتا ہے، اس لیے میزبان کے روٹ لکھنے سے پہلے وہ پتہ پڑھیں جو اس نے واقعی لیا۔

جانچ 3: میزبان کے روٹ مہمان کا نام لیتے ہیں، سرنگ کا نہیں

مہمان کے ذریعے صرف وہ سابقے بھیجیں جو میزبان کو درکار ہیں۔ Linux پر فی سابقہ ایک روٹ کافی ہے اور وہ صاف طور پر واپس مڑتا ہے:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows پر متبادل route add 10.20.0.0 mask 255.255.0.0 192.168.56.2 ہے۔ جانچ کے دوران -p چھوڑ دیں، تاکہ خراب روٹ ری بوٹ پر مر جائے، اور راستہ چلنے کے بعد اسے شامل کریں۔ میزبان کا طے شدہ روٹ نہ ہٹائیں، جب تک میزبان کی ہر ایپلیکیشن کو سرنگ استعمال کرنی نہ ہو؛ اگر واقعی مکمل سرنگ درکار ہے تو دو /1 روٹ شامل کریں اور ہائپر وائزر نیٹ ورک تک سیدھا روٹ رکھیں:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows میزبان پر انٹرفیس میٹرک بھی دیکھیں۔ وہ روٹ جو host-only اڈاپٹر بند ہونے کے دوران شامل کیا گیا تھا جدول میں رہتا ہے مگر کبھی ٹریفک نہیں اٹھاتا، اور کم میٹرک والا دوسرا اڈاپٹر اسی سابقے کی تلاش جیت سکتا ہے۔

جانچ 4: DNS روٹ کی پیروی کرتا ہے، سرنگ کے طے شدہ کی نہیں

روٹ پیکٹ حرکت دیتے ہیں؛ حل کرنے والا طے کرتا ہے کہ کون سے نام پیکٹ بناتے ہیں۔ میزبان کے حل کرنے والے کو بدلنے کے بجائے کارپوریٹ حل کرنے والے کو کارپوریٹ زون تک محدود کریں، اور اسے ایسے DNS سرور کی طرف دکھائیں جہاں نیا روٹ پہلے ہی پہنچتا ہے۔ میزبان پر systemd-resolved کے ساتھ:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows پر نام حل کرنے کی پالیسی جدول کا اندراج وہی کام کرتا ہے: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53۔ اگر مہمان host-only پتے پر اپنا حل کرنے والا چلاتا ہے تو اس کے بجائے وہی پتہ استعمال کریں، مگر صرف اس بات کی تصدیق کے بعد کہ وہ loopback پر نہیں، 192.168.56.2 پر جواب دیتا ہے۔

پھر سست صفحات کے لیے DNS کو قصوروار ٹھہرانے سے پہلے MTU دیکھیں۔ سرنگ کا انٹرفیس میزبان کے 1500 بائٹ انٹرفیس سے چھوٹا ہے، اس لیے DF بٹ لگا کر پورے سائز کے سیگمنٹ بھیجنے والا میزبان انہیں مہمان کے اندر کہیں گراتا ہے۔ کلاسیکی علامت کام کرنے والا ping اور اندرونی ویب ایپ ہے جو TLS ہینڈ شیک کے بعد رک جاتی ہے۔ مہمان کے فارورڈ راستے میں MSS سکیڑیں:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

جانچ 5: دونوں سروں سے تصدیق کریں

میزبان سے اندرونی پتے کی طرف traceroute یا tracert پہلے ہاپ کے طور پر جسمانی گیٹ وے نہیں، 192.168.56.2 دکھانا چاہیے۔ مہمان میں وہی کوشش باہر جاتے دیکھیں: tcpdump -ni any host 10.20.30.40 host-only طرف فارورڈ شدہ درخواست اور سرنگ پر ترجمہ شدہ درخواست دکھاتا ہے۔ جو درخواست باہر جاتی ہے، واپس آتی ہے اور پھر بھی میزبان کو خاموش چھوڑ دیتی ہے، وہ واپسی کے راستے کی طرف اشارہ کرتی ہے۔

اس کا بیشتر حصہ دو ناکامیوں سے واضح ہوتا ہے۔ یا تو NAT قاعدہ نہ ہونے کی وجہ سے مہمان کی سرنگ host-only سابقے کے لیے واپسی کا روٹ نہیں رکھتی، یا میزبان کا روٹ ایسے پتے کی طرف اشارہ کرتا ہے جو ری بوٹ کے بعد مہمان کے پاس نہیں رہتا۔ پچھلے سیشن کے نوٹوں پر بھروسا کرنے کے بجائے ip -br addr اور ip route get سے پتے دوبارہ پڑھیں۔

جانچ 6: اسے ری بوٹ اور ہائپر وائزر اپ گریڈ برداشت کرنے والا بنائیں

دونوں حصے قائم رکھیں: میزبان پر netplan یا NetworkManager روٹ کنفیگریشن، Windows پر route add ... -p، اور /etc/sysctl.d/ میں net.ipv4.ip_forward=1 کے ساتھ مہمان میں دوبارہ لوڈ ہونے والا فائر وال قواعد کا مجموعہ۔ کنفیگریشن کی تصدیق ہوتے ہی، اگلی کارپوریٹ کلائنٹ اپ ڈیٹ آنے سے پہلے مہمان کا snapshot لیں۔

جب ہائپر وائزر اپنے اڈاپٹر دوبارہ بناتا ہے تو host-only نیٹ ورک دوبارہ نمبر پاتے ہیں، جو 192.168.56.0/24 پر بنے ہر روٹ اور NAT قاعدے کو خاموشی سے باطل کر دیتا ہے۔ اپ گریڈ کے بعد پہلی تین جانچیں ترتیب سے دوبارہ چلائیں؛ اس میں ایک منٹ لگتا ہے اور وہ صورت پکڑ لیتا ہے جہاں میزبان کے پاس اپنا روٹ اب بھی ہے جبکہ مہمان نیا سب نیٹ اختیار کر چکا ہے۔

IPv6 کو اپنی الگ باری چاہیے۔ ip6tables قواعد، AAAA ریکارڈ اور میزبان روٹ کا دوسرا خاندان IPv4 ترتیب کی پیروی نہیں کرتے، اور IPv6 کے ذریعے قابلِ رسائی کارپوریٹ سروس IPv4 کے چلتے ہوئے مستقل خراب دکھائی دے گی۔

کامیاب یا ناکام، ترتیب سے: میزبان مہمان کے host-only پتے کو پنگ کر سکتا ہے؛ مہمان سرنگ کی طرف فارورڈ اور MASQUERADE کرتا ہے؛ ip route get اندرونی سابقے کے لیے گیٹ وے کے طور پر مہمان واپس دیتا ہے؛ کارپوریٹ نام محدود حل کرنے والے سے حل ہوتے ہیں؛ traceroute مہمان کو پہلے دکھاتا ہے؛ اور وہی چھ جواب ری بوٹ برداشت کر لیتے ہیں۔