Pi پر ہاٹ اسپاٹ کلائنٹس TUN VPN کے ذریعے گھر کے LAN تک نہیں پہنچتے

مقامی Wi-Fi اور Ethernet کلائنٹس Pi کے ہاٹ اسپاٹ سے جڑتے ہیں، اس کی DHCP رینج سے پتہ لیتے ہیں اور بغیر شکایت انٹرنیٹ صفحات لوڈ کرتے ہیں۔ پھر وہی کلائنٹس گھر کے LAN پر فائل شیئرنگ یا ویب انٹرفیس کھولتے وقت وقت سے گزر جاتے ہیں، جبکہ خود Pi سرنگ کے ذریعے اس LAN تک پہنچتا ہے۔ وائرلیس پرت میں کچھ بھی ٹوٹا نہیں۔ جو کمی ہے وہ روٹ شدہ معاہدہ ہے: ہاٹ اسپاٹ کا پریفکس TUN انٹرفیس میں لے جانا ہوگا، اور گھر کی طرف کسی چیز کو جاننا ہوگا کہ جوابات وہاں واپس کیسے بھیجے جائیں۔ ایک پیکٹ کے سفر کی تکمیل سے پہلے دونوں نصف موجود ہونے چاہئیں۔

تین مختلف کاموں والے تین رابطے

Linux Ethernet پل منزل MAC پتے کے مطابق فریم آگے بھیجتا ہے۔ OpenVPN TUN موڈ میں IP پیکٹ لے کر چلتا ہے اور اس میں MAC پرت بالکل نہیں، اس لیے مقامی پل شامل کرنا سرنگ کو کبھی بندرگاہ کے طور پر درج نہیں کرتا۔ کرنل کی TUN/TAP دستاویزات اس تقسیم کی وضاحت کرتی ہیں: TAP ڈیوائس Ethernet انٹرفیس جیسی نظر آتی ہے، TUN ڈیوائس نہیں۔ دو مقامی پورٹوں کو پل کر کے پھر روٹ کرنے والا ڈیزائن، انٹرفیس کے نام کچھ بھی کہیں، ایک روٹر ہے۔

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

موڈیم کو بھی کلائنٹ پل سے باہر رکھیں۔ PPP رابطہ دوسرے لیبل والا Ethernet آلہ نہیں، اور pppd کی دستاویزی ڈیفالٹ روٹ منطق IPCP گفتگو کے بعد چلتی ہے اور وہ لنک گرنے پر اپنا راستہ واپس لے لیتی ہے۔ DHCP ٹیمپلیٹ کاپی کرنا اور ہر usb0 کا نام ppp0 رکھنا گیٹ وے، میٹرک یا زندگی کے چکر کے بارے میں کچھ ثابت نہیں کرتا۔

کوئی بھی کنفگ ترمیم کرنے سے پہلے پریفکس منتخب کریں

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

پہلا تالاب وہ underlay پتہ ہے جو آپریٹر نے موڈیم کو دیا؛ اسے کلائنٹس کی طرف دیکھنے والے ہر منصوبے سے باہر رہنا چاہیے۔ دوسرا سرنگ کا سب نیٹ ہے جو سرور نے چنا، اکثر اس کا اپنا نجی /24۔ تیسرا ہاٹ اسپاٹ پل ہے، اور چوتھا وہ گھریلو پریفکس ہے جہاں آپ پہنچنا چاہتے ہیں۔ اس سفر میں ہاٹ اسپاٹ کو 172.28.90.0/24 ملتا ہے، پل 172.28.90.1 پر ہے، اور گھر کی سروس LAN 192.168.77.0/24 رکھتی ہے، جو صارفین کے روٹروں کے ساتھ آنے والے 192.168.1.0/24 اور 10.0.0.0/24 ڈیفالٹس اور آپریٹر کی 100.64.0.0/10 رینج سے بچتی ہے۔

ہاٹ اسپاٹ کی DHCP رینج میں صرف پل کا پتہ گیٹ وے کے طور پر اعلان کریں، اور کچھ نہیں۔ ہاٹ اسپاٹ کلائنٹس کو کبھی گیٹ وے کے طور پر گھر کا پتہ نہ دیں؛ ان کے پاس اس حصے تک لنک پرت کا راستہ نہیں۔

ہر سمت کو اسی طرف روٹ کریں جو اس کا مالک ہے

Pi کو سرنگ کے ذریعے گھریلو پریفکس کا راستہ درکار ہے۔ سرور موڈ کے سرور عام طور پر وہ راستہ دھکیلتے ہیں، اس لیے پہلے تصدیق کریں کہ فارورڈنگ آن ہے اور کرنل tun0 سے گھر کا پتہ حل کرتا ہے۔

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

اگر ip route get اب بھی underlay انٹرفیس کی اطلاع دیتا ہے تو وہیں رک جائیں؛ راستے میں آگے کچھ بھی غلط تلاش کو درست نہیں کر سکتا۔

گھریلو آلات کے پاس 172.28.90.0/24 تک راستہ نہیں، اس لیے ان کے جوابات ڈیفالٹ گیٹ وے کی پیروی کرتے ہیں اور روٹر پر مر جاتے ہیں۔ دو معاون مرمت موجود ہیں۔ یا گھر کے روٹر پر ایک جامد راستہ شامل کریں جو ہاٹ اسپاٹ پریفکس کو VPN سرور کے LAN پتے کی طرف لے جائے، یا جب سرور خود گیٹ وے ہو تو کلائنٹ پریفکس کو سرور کی اپنی روٹنگ جدول میں درج کریں۔ OpenVPN کے ملٹی کلائنٹ موڈ میں کلائنٹ مخصوص ڈائریکٹری وہ نسبت رکھتی ہے: کلائنٹ سرٹیفکیٹ کے عام نام پر نامزد فائل، جس میں iroute 172.28.90.0 255.255.255.0 اور اسے سرور کرنل میں نصب کرنے والی مماثل route لائن ہوتی ہے۔ سرور پر اندازہ لگایا گیا کرنل راستہ یہ بتانے کے برابر بیان نہیں کہ کون سا کلائنٹ پریفکس کا مالک ہے۔

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

فائر وال کا اندازہ لگائے بغیر فارورڈنگ کھولیں

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 سے tun0 تک قبولیت کا قاعدہ اور مماثل جواب کی سمت، اور ایسا postrouting قاعدہ تلاش کریں جو ماخذ کو دوبارہ لکھ سکے۔ اگر چین پالیسی drop ہے اور کوئی قاعدہ نہیں ملتا تو پالیسی کو accept میں پلٹانے کے بجائے تنگ قبولیتیں شامل کریں اور دوبارہ جانچیں۔

ترجمہ ایک پالیسی انتخاب ہے، شرط نہیں۔ گھر کے LAN کی طرف ماخذ NAT ہر ہاٹ اسپاٹ کلائنٹ کو Pi کے سرنگ پتے جیسا دکھاتا ہے، جو گھر کے لاگز میں فی کلائنٹ انتساب کھو دیتا ہے اور اصل ماخذ کی توقع رکھنے والی خدمات توڑ دیتا ہے۔ NAT کے بغیر روٹنگ کلائنٹ پتے نظر آتے رکھتی ہے مگر اوپر والے واپسی راستے پر منحصر ہے۔ ایک منتخب کریں اور DNS اور IPv6 کے ساتھ بھی ویسا ہی سلوک کریں، کیونکہ ٹوٹے IPv6 راستے کے ساتھ چلتا IPv4 راستہ براؤزر میں اب بھی آدھا ٹوٹا پڑھا جاتا ہے۔

سفر کی تصدیق کریں، پھر اسے جان بوجھ کر توڑیں

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

دونوں کیپچر ایک ساتھ پڑھیں۔ br0 پر وہ درخواستیں جو کبھی tun0 پر ظاہر نہیں ہوتیں، مطلب Pi فارورڈ نہیں کر رہا یا راستہ کہیں اور اشارہ کرتا ہے۔ tun0 پر بغیر جواب کی درخواستیں مطلب گھر کی طرف واپسی راستہ نہیں یا سرور نے پیکٹ فلٹر کیا۔ tun0 پر وہ جوابات جو پھر کبھی br0 پر ظاہر نہیں ہوتے، مطلب الٹا فلٹر قاعدہ غائب ہے، جہاں سرنگ کامل دکھتی ہے اور کلائنٹ پھر بھی کچھ نہیں دیکھتا۔

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

ڈیزائن صرف اس وقت قبول کریں جب ہاٹ اسپاٹ کلائنٹ گھر کا نام حل کر سکے، TCP خدمت کھول سکے اور ایک موڈیم دوبارہ رابطے کے دوران سیشن زندہ رکھ سکے۔ اگر کسی ایپلیکیشن کو گھر کے حصے میں واقعی Ethernet سطح کی دریافت درکار ہو تو مقامی پل کو پل شدہ بتا کر نشریات کا انتظار کرنے کے بجائے معاون Layer 2 ڈیزائن منتخب کریں۔