host-only نیٹ ورک میں VM ٹریفک کو TUN OpenVPN سرور کے ذریعے روٹ کریں

host-only اڈاپٹر مقامی مجازی نیٹ ورک بناتے ہیں، اور روٹ شدہ TUN ٹنل پتوں کے درمیان IP پیکٹ لے جاتے ہیں۔ ان میں سے کوئی ایک دوسرے کے لیے پل نہیں، اسی لیے کام کرنے والی ترتیب کو بتانا ہوگا کہ کون آگے بھیجتا ہے اور واپسی کا روٹ کس کا ہے۔ یہ دو ذمہ داریاں الٹ جائیں تو مہمان ٹنل کو ایسے ماخذ سے جواب دیتا ہے جو ٹنل کلائنٹ نے کبھی نہیں مانگا۔ نیچے کا ڈیزائن دونوں سابقے الگ رکھتا ہے اور واپسی کا راستہ واضح کرتا ہے۔

دو نیٹ ورک، دو سابقے

ٹنل پول اور host-only نیٹ ورک کو الگ الگ سابقے دیں اور کبھی ایک کو دوسرے کے لیے دوبارہ استعمال نہ کریں۔ اس مثال میں VPN پول 10.44.0.0/24 ہے اور host-only نیٹ ورک 192.168.99.0/24 ہے، میزبان 192.168.99.1 پر اور ایک مہمان 192.168.99.20 پر۔ ایک ہی سابقہ TUN ڈیوائس اور host-only اڈاپٹر دونوں کو دینا انہیں نہیں جوڑتا۔ یہ ایک پتہ رینج پر دو دعوے بناتا ہے، اور روٹنگ ٹیبل پھر اسی دعوے کے حق میں جواب دیتی ہے جو اس نے اتفاقاً رکھا تھا۔

host-only اڈاپٹر میزبان پر اور مہمان کے اندر دونوں جگہ موجود ہوتا ہے، اور اسے خود سے مشین سے باہر جانے کا کوئی راستہ نہیں۔ برج اور NAT کنکشن کا خطرہ مختلف ہوتا ہے، اور ایک مہمان سروس تک پہنچنے کے لیے برج موڈ میں جانا شرط نہیں۔

میزبان کے پاس راستہ پہلے سے ہے

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

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

تیسری سطر وہی طریقہ ہے جو میزبان کو ایک چھلانگ بناتا ہے۔ اس کے بغیر، ٹنل سے آنے والا پیکٹ ایسے نیٹ ورک پر پتہ پاتا ہے جہاں میزبان پہنچ سکتا ہے مگر آگے نہیں بھیجے گا۔ آگے بھیجنا ضروری ہے اور کافی نہیں۔ فلٹر پالیسی اب بھی طے کرتی ہے کہ ٹنل انٹرفیس اور host-only انٹرفیس کے درمیان کوئی مخصوص بہاؤ اجازت یافتہ ہے یا نہیں، اور یہ فیصلہ کسی نہ پڑھی گئی ڈیفالٹ پالیسی میں نہیں بلکہ تحریری ہونا چاہیے۔

روٹ دھکیلیں، پھر جو اس تک پہنچتا ہے اسے فلٹر کریں

سرور دھکیلے گئے روٹ قبول کرنے والے کلائنٹس کو host-only سابقہ دے سکتا ہے، جو ٹنل کے پیچھے کسی بھی دوسرے ذیلی نیٹ ورک کے لیے استعمال ہونے والا وہی طریقہ ہے۔

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

مہمان کو واپسی کا راستہ چاہیے

10.44.0.x سے پہنچنے والے مہمان کو اپنے جوابات میزبان کے host-only پتے پر بھیجنے ہوں گے، یا میزبان کو ماخذ کا ترجمہ کرنا ہوگا۔ VirtualBox DHCP سے پتہ ملنا ان دونوں ترتیبوں میں سے کسی کے بارے میں کچھ نہیں کہتا۔

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

مہمان کے اندر وہ روٹ شامل کرنا اصل ماخذ کو محفوظ رکھتا ہے، جو ہر کلائنٹ کی پالیسی اور لاگ کو بامعنی رکھتا ہے۔ میزبان پر محدود ماخذ ترجمہ متبادل ہے، اور یہ کام کرتا ہے، مگر اس قیمت پر کہ کون سا کلائنٹ جڑا۔ اوورلیپ ناکامی کا دوسرا طریقہ ہے۔ جس کا گھریلو LAN پہلے سے 192.168.99.0/24 استعمال کرتا ہے، ایسا دور کا کلائنٹ دھکیلے گئے روٹ کو اپنا نیٹ ورک پڑھے گا، اور سرور کی طرف کوئی تبدیلی اس ابہام کو دور نہیں کرتی۔ ایک طرف کو دوبارہ نمبر دیں یا ایسا سابقہ چنیں جس کے ٹکرانے کا امکان کم ہو۔

TUN ڈیوائس IP پیکٹ لے جاتا ہے، اس لیے مہمان کے اندر ڈیفالٹ گیٹ وے شامل کرنا ٹنل کو host-only اڈاپٹر کے ساتھ ایتھرنیٹ حصہ نہیں بناتا۔ TAP برج اپنی کلائنٹ معاونت اور پتہ ملکیت والا الگ ڈیزائن ہے، اور دونوں وضاحتیں ملانے سے ایسی ترتیب بنتی ہے جو کبھی نہیں ملتی۔

تصدیق کریں، پھر اسے ری اسٹارٹ برداشت کرنے والا بنائیں

عام دور کے کلائنٹ سے ایک بے ضرر سروس جانچیں، مہمان کا واپسی روٹ دیکھیں، اور تصدیق کریں کہ جس سروس کی آپ نے اجازت نہیں دی وہ سست نہیں بلکہ مسترد ہوتی ہے۔

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

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