VPN نام اسپیس کے اندر ایپ LAN سے قابل رسائی نہیں

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

LAN پتے پر کوئی جواب کیوں نہیں آتا

نام اسپیس ایک مکمل نیٹ ورک اسٹیک ہے: انٹرفیس، راستے، فائر وال کے قواعد اور ایک نجی لوپ بیک۔ ip netns exec کے ذریعے شروع کیا گیا عمل صرف وہی اسٹیک دیکھتا ہے، اس لیے جو پتہ یہ باندھتا ہے وہ صرف نام اسپیس کے اندر حل ہوتا ہے۔ ہوسٹ کا اپنا 127.0.0.1 بالکل مختلف لوپ بیک ہے۔

اسی لیے ہوسٹ پر curl ناکام ہوتا ہے جبکہ نام اسپیس کے اندر وہی کمانڈ کامیاب ہوتی ہے۔ ایپلیکیشن صحت مند ہے؛ پتہ بس ہوسٹ کے اسٹیک میں نہیں ہے۔

ایک پورٹ socat چھلانگ سے شائع کریں

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

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

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

ایک سے زیادہ پورٹ گزریں تو veth جوڑی استعمال کریں

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

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

قید خانہ توڑنے کا ارادہ نہ ہو تو ہوسٹ کے ذریعے ڈیفالٹ راستہ شامل نہ کریں۔ ٹنل ہی راستہ رہنا چاہیے، اس لیے جوڑی کے اوپر صرف شائع شدہ سروس کا پتہ قابل رسائی ہے۔ نام اسپیس کو اس کی اپنی ریزولور فائل بھی دیں، کیونکہ ip netns exec /etc/netns/vpn/resolv.conf پڑھتا ہے اور اس کے بغیر قید خانے میں نام حل کرنا خالی ہے۔

ہوسٹ سے نہیں، دوسری مشین سے جانچیں

ٹیسٹ دوسری مشین سے چلائیں، کیونکہ ہوسٹ مقامی سننے والے تک ایسے راستوں سے پہنچ سکتا ہے جو LAN کے بارے میں کچھ نہیں بتاتے۔ پہلے دیکھیں کہ ایپ نام اسپیس کے اندر اصل میں کس سے بندھی ہے، پھر باہر سے شائع شدہ پتے سے جڑیں۔ وہاں ہر پتے سے بندھنے سے قید خانہ وسیع نہیں ہوتا، کیونکہ وائلڈ کارڈ اب بھی نام اسپیس کا ہے اور LAN اسے نہیں دیکھ سکتا۔

ip netns exec vpn ss -lntp

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