VirtualBox VPN لیب: گیٹ وے VM یا صرف میزبان نیٹ ورک
VirtualBox VPN لیب کے لیے روٹ شدہ گیٹ وے VM اور صرف میزبان سیگمنٹ میں سے انتخاب کریں، پھر سرنگ گرنے پر مہمان کو بند حالت میں ناکام ہونے دیں۔
آپ کو فیصلہ کرنا ہے کہ آپ کی VPN لیب کتنی مشینری کی حقدار ہے۔ دو VirtualBox سیگمنٹس کے درمیان روٹ شدہ گیٹ وے VM پتہ ترجمہ، واپسی کا راستہ اور اس فائر وال کی پوزیشن دوبارہ پیدا کرتا ہے جس کے پیچھے ایک حقیقی کلائنٹ بیٹھتا ہے۔ ایک صرف میزبان سیگمنٹ آپ کو ایک کنٹرول شدہ دروازہ دیتا ہے اور اس کے سوا کچھ نہیں۔ گیٹ وے ورژن کے لیے تین مہمان اور ایک روٹنگ جدول درکار ہے جسے آپ سنبھالتے ہیں؛ صرف میزبان ورژن کے لیے ایک مہمان اور ایک پالیسی درکار ہے۔ تین سوال انہیں الگ کرتے ہیں، اور تیسرا فیصلہ کرتا ہے کہ آپ کا ٹیسٹ بالکل پاس ہو سکتا ہے یا نہیں۔
کچھ بھی کلون کرنے سے پہلے تین سوالوں کے جواب دیں
VPN سرور کو کیا مشاہدہ کرنا ہے اس سے شروع کریں۔ اگر سرور کو ایسا ماخذ پتہ دیکھنا ہے جو ٹیسٹ مہمان کا نہیں، تو ان کے درمیان کچھ ترجمہ کرنا ہوگا، اور وہ کچھ آپ کے کنٹرول والا روٹر ہونا چاہیے۔ صرف میزبان نیٹ ورکنگ میزبان کو مہمان کے سیگمنٹ میں ایڈاپٹر دیتی ہے، مترجم نہیں۔ پھر جب مہمان کو باہر کسی چیز تک پہنچنا ہو، تو آپ NAT ایڈاپٹر جوڑتے ہیں، اور VirtualBox کا اپنا NAT انجن آپ سے پوچھے بغیر ماخذ دوبارہ لکھ دیتا ہے۔
اس کے بعد پوچھیں کہ کیا مہمان سرنگ کے علاوہ کسی اور چیز تک پہنچ سکتا ہے۔ یہی جواب اندرونی یا صرف میزبان چنتا ہے، اور یہی وہ سوال ہے جسے زیادہ تر لیب تحریریں چھوڑ دیتی ہیں۔ آخر میں پوچھیں کہ سرنگ گرنے پر کیا ہونا چاہیے، کیونکہ یہ ٹوپولوجی نہیں بلکہ پالیسی طے کرتا ہے، اور جو لیب صرف خوشگوار راستہ ثابت کرتی ہے اس نے تقریباً کچھ بھی نہیں جانچا۔
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
تین کرداروں کو اندرونی نیٹ ورکس سے جوڑیں
تین مہمان اور دو نام والے سیگمنٹ استعمال کریں، اور گیٹ وے واحد مشین ہو جس کے دونوں پر ایڈاپٹر ہو:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANاندرونی نیٹ ورک کے لیے کوئی الگ تخلیق کا مرحلہ نہیں ہے۔ --intnet1 میں موجود سٹرنگ ہی سیگمنٹ ہے: دو مشینیں اسے صرف اسی صورت میں بانٹتی ہیں جب نام بالکل ملے، اور میزبان پر کچھ بھی اس سے منسلک نہیں۔ یہی آخری خصوصیت لیب کے صاف دہرانے کی وجہ ہے، کیونکہ میزبان کے روٹ، اس کا اپنا VPN کلائنٹ اور اس کی فائر وال حادثاتی طور پر مہمانوں تک نہیں پہنچ سکتے۔ اندرونی سیگمنٹ میں DHCP سرور بھی نہیں ہوتا جب تک آپ ایک نہ شامل کریں، اس لیے مستقل پتے سب سے چھوٹا راستہ ہیں۔
کلائنٹ کو صرف اس کا WAN پتہ دیں، اور ڈیفالٹ گیٹ وے گیٹ وے کے WAN پتے کی طرف اشارہ کرے۔ سرور کو LAN پتہ ملتا ہے اور وہ گیٹ وے کے LAN پتے کو اپنا ڈیفالٹ گیٹ وے بناتا ہے۔ جو مہمان ایک سیگمنٹ پر دو پتے رکھتا ہے، یا دوسرے سیگمنٹ کی طرف بھٹکا ہوا راستہ رکھتا ہے، اس کے پاس روٹر کے گرد راستہ ہے، اور نیچے کے ٹیسٹ آپ سے جھوٹ بولیں گے۔
میں VM ناموں کے ساتھ چار پتوں اور دو سیگمنٹ ناموں والی متن فائل رکھتا ہوں اور اسے ہر شیل میں چسپاں کرتا ہوں۔ ہفتوں بعد، جب پروفائل کی تبدیلی کچھ توڑ دیتی ہے، وہی فائل پروفائل ڈیبگ کرنے اور اپنی یادداشت ڈیبگ کرنے کے درمیان فرق ہوتی ہے۔
جس سیگمنٹ سے رساؤ نہیں ہونا چاہیے اس کے لیے اندرونی یا صرف میزبان منتخب کریں
صرف میزبان موڈ میزبان پر ہی ایک مجازی ایڈاپٹر بناتا ہے، عام طور پر vboxnet0، اور میزبان کو مہمان کے سیگمنٹ میں پتہ دیتا ہے۔ یہ انتظام کے لیے آسان اور تنہائی ٹیسٹ کے لیے مہلک ہے، کیونکہ میزبان اب مہمان تک براہ راست پہنچ سکتا ہے اور میزبان کی طرف کی ہر سروس ممکنہ راستہ بن جاتی ہے۔ اندرونی موڈ میں میزبان ایڈاپٹر بالکل نہیں ہوتا۔ دونوں موڈ نیٹ ورک سیٹنگز پینل میں آسانی سے گڈمڈ ہو جاتے ہیں، اس لیے لیبل نہیں بلکہ دستاویزی فرق جانچیں (VirtualBox نیٹ ورکنگ تفصیلات صفحہ دیکھیں)۔
جس مہمان کو سرنگ لازماً استعمال کرنی ہو اس کے لیے اندرونی زیادہ محفوظ ڈیفالٹ ہے، اور گیٹ وے ہی واحد اخراج ہے۔ اگر آپ صرف میزبان رکھتے ہیں، تو میزبان ایڈاپٹر کو انتظامی راستہ سمجھیں اور یہ اونچی آواز میں کہیں: میزبان مہمان تک پہنچ سکتا ہے، اور مہمان میزبان کو اخراج کے طور پر استعمال نہیں کر سکنا چاہیے۔
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0آپ جو تنہائی ثابت کر سکتے ہیں وہی تنہائی ہے جو آپ نے ترتیب دی۔ ایک اندرونی ایڈاپٹر، گیٹ وے پر ڈیفالٹ راستہ اور NAT ایڈاپٹر کے بغیر مہمان کے پاس گیٹ وے کو بچانے والا کوئی راستہ نہیں ہوتا۔ صرف میزبان ایڈاپٹر اور NAT ایڈاپٹر والے مہمان کے پاس دو راستے ہوتے ہیں، اور ان میں صرف ایک ہی وہ راستہ ہے جو آپ جانچنا چاہتے تھے۔
گیٹ وے پر روٹ اور ترجمہ کریں، پھر اسے بند حالت میں ناکام ہونے دیں
VirtualBox سیگمنٹس کے درمیان فارورڈ نہیں کرتا؛ مہمان کرتا ہے۔ VPN سرور VM گیٹ وے کے پیچھے ہونے پر فارورڈنگ فعال کریں اور کلائنٹ کی ٹریفک کا ترجمہ کریں جب وہ سرور کی طرف نکلتی ہے:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEاس قاعدے سے سرور کلائنٹ کی بجائے گیٹ وے کا LAN پتہ دیکھتا ہے، اور آپریٹر NAT کے پیچھے حقیقی کلائنٹ نیٹ ورک کے سر کو اسی طرح نظر آتا ہے۔ sysctl قدر /etc/sysctl.d/ میں اور قاعدہ اس فائر وال سروس میں محفوظ کریں جو ڈسٹری بیوشن استعمال کرتی ہے، ورنہ ری بوٹ لیب کو خاموشی سے روٹ شدہ مگر غیر مترجم حالت میں واپس لے آئے گا۔
فارورڈنگ اجازت نہیں ہے۔ ACCEPT کی ڈیفالٹ FORWARD پالیسی کے تحت، جس مہمان کا ڈیفالٹ راستہ گیٹ وے کی طرف اشارہ کرتا ہے وہ سرنگ ہو یا نہ ہو، روٹنگ جدول کے منتخب کردہ انٹرفیس سے نکلتا ہے۔ اگر گیٹ وے میں پیکیج انسٹال کے لیے NAT ایڈاپٹر بھی ہو، تو سرنگ گرنے کے لمحے وہ ایڈاپٹر کام کرنے والا غیر خفیہ شدہ اخراج ہے، اور آپ کا صرف-VPN ٹیسٹ کبھی صرف-VPN ٹیسٹ نہیں تھا۔
جب سرور دور ہو اور سرنگ خود گیٹ وے ختم کرے، تو وہی فیصلہ انٹرنیٹ تک پہنچنے والے NIC کی طرف نہیں بلکہ سرنگ انٹرفیس کی طرف اشارہ کرتا ہے:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTسرنگ کی اپنی بیرونی ترسیل اور بینڈ سے باہر انتظامی راستے کو فارورڈ ہونے والی ٹریفک سے الگ رکھیں۔ اگر گیٹ وے کی مرمت کا واحد راستہ وہی سرنگ ہے جسے آپ ڈیبگ کر رہے ہیں، تو لیب لاک آؤٹ کی مشق بن جاتی ہے۔ ایک سیریل کنسول، صرف میزبان انتظامی ایڈاپٹر، یا معلوم اچھی حالت کا اسنیپ شاٹ ہاتھ سے ٹوٹے روٹر کو واپس لینے سے سستا ہے۔
راستہ میزبان سے نہیں، مہمان سے تصدیق کریں
باہر کی طرف کام کریں۔ یقینی بنائیں کہ کلائنٹ گیٹ وے کے WAN پتے تک پہنچتا ہے، پھر گیٹ وے کے ذریعے سرور تک، پھر کہ VPN پورٹ تک کنکشن نکلتا اور واپس آتا ہے۔ گیٹ وے کے دونوں انٹرفیس پر کیپچر دکھاتا ہے کہ جواب آتا ہے یا واپسی راستے پر پھینک دیا جاتا ہے، جسے صرف کلائنٹ پر کیپچر الگ نہیں کر سکتا:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194پھر اخراج ثابت کریں۔ مہمان سے پتہ انعکاس سروس سے پوچھیں کہ وہ کون سا ماخذ دیکھتی ہے اور اسے گیٹ وے کے اپنے اخراجی پتے سے موازنہ کریں؛ اگر جواب میزبان کے پتے سے ملتا ہے، تو سرنگ کے گرد راستہ موجود ہے۔ جانچیں کہ مہمان واقعی کون سا حل کنندہ استعمال کرتا ہے، اور IPv6 الگ سے جانچیں، کیونکہ جس سیگمنٹ میں IPv6 فعال ہے جبکہ سرنگ صرف IPv4 لے جاتی ہے وہ حادثاتی طور پر نہیں بلکہ ڈیزائن سے رساؤ کرتا ہے۔
آخر میں، اسے جان بوجھ کر توڑیں۔ سرنگ روکیں، یا اس کا بیرونی پورٹ بلاک کریں، اور مہمان سے نیا کنکشن کھولیں۔ اسے ناکام ہونا ہی چاہیے، اور وجہ ایسی ہونی چاہیے جس کا آپ نام لے سکیں: کوئی راستہ نہیں، کوئی مسترد قاعدہ ہے، یا حل کنندہ مرا ہوا ہے۔ سرنگ دوبارہ شروع کریں اور یقینی بنائیں کہ مہمان نیٹ ورک دوبارہ بنائے بغیر سنبھل جاتا ہے۔ اگر Hamachi یا ZeroTier جیسا mesh VPN لیب بانٹتا ہے، تو یاد رکھیں کہ برج شدہ ایڈاپٹر mesh کی نہیں بلکہ ایڈاپٹر کے نام کی پیروی کرتا ہے، اس لیے کلائنٹ کے اپنا مجازی ایڈاپٹر انسٹال کرنے کے بعد برج دوبارہ ہدایت کرنا ہوگا۔
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>مہمان کی سرنگ میزبان کے ساتھ بانٹنا مسئلے کی عکاسی ہے۔ میزبان کے ڈیفالٹ راستے کو مہمان کی طرف ہدایت کرنا کام کرتا ہے، اور مہمان کے اندر پراکسی بھی کام کرتی ہے؛ میزبان کے ذریعے NAT میزبان کی شروع کردہ ٹریفک کے لیے مہمان کی سرنگ نہیں لے جاتا۔ سیگمنٹ نام اور فائر وال قواعد ایک ہی جگہ محفوظ کریں، کام کرنے والی حالت کا اسنیپ شاٹ لیں، اور وہ ماخذ پتہ درج کریں جو سرور نے مشاہدہ کیا۔ پھر اگلی پروفائل تبدیلی دوبارہ بنائی گئی لیب کی بجائے ایک اسکرپٹ رن کے برابر ہوگی۔