Raspberry Pi پر VPN گیٹ وے: ایک نیٹ ورک کارڈ یا الگ کلائنٹ پورٹ
Pi کا ایک پورٹ منتخب کلائنٹس کی خدمت کر سکتا ہے، یا دوسرا پورٹ آلات کو اندر بند کر سکتا ہے۔ جدا کاری، متبادل پالیسی اور DNS کس کے پاس ہے کی بنیاد پر ترتیب منتخب کریں۔
آپ کے پاس ایک Pi، ایک کام کرنے والا باہر جانے والا VPN پروفائل، اور دو آلات ہیں جنہیں اس کے ذریعے انٹرنیٹ تک پہنچنا چاہیے۔ پورے ڈھانچے کا فیصلہ کرنے والا سوال یہ نہیں کہ کون سی گائیڈ کی پیروی کی جائے، بلکہ یہ ہے کہ کتنی جدا کاری درکار ہے۔ ایک پورٹ Pi کو ان آلات کے ساتھ راؤٹر کے LAN پر بیٹھنے اور اضافی گیٹ وے کے طور پر کام کرنے دیتا ہے؛ دوسرا پورٹ آپ کو انہیں ایسے حصے میں رکھنے دیتا ہے جہاں Pi ہی باہر نکلنے کا واحد راستہ ہے۔ اس انتخاب کے بعد کا سب کچھ — DHCP، فائر وال کا دائرہ، DNS، تعطل کی صورت — اسی سے نکلتا ہے۔
دونوں ترتیبیں واقعی کس چیز میں مختلف ہیں
دونوں ڈیزائن روٹنگ کرتے ہیں۔ فرق یہ ہے کہ تار پر اور کون کھڑا ہے اور جب آپ کی پالیسی غلط ہو تو کیا ہوتا ہے۔
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
اصل محور جدا کاری ہے۔ ترتیب A مشورتی ہے: جو آلہ DHCP کے دیے گئے گیٹ وے کو نظرانداز کر کے راؤٹر منتخب کرتا ہے وہ بغیر خفیہ کاری کے بھی کام کرتا رہتا ہے۔ ترتیب B ٹوپولوجی سے مسلط ہوتی ہے، کیونکہ منتخب کرنے کے لیے کوئی دوسرا اگلا قدم نہیں۔
ترتیب A: موجودہ LAN پر اضافی گیٹ وے کے طور پر Pi
فرض کریں کہ ISP کا راؤٹر 192.168.50.1 ہے، Pi 192.168.50.2 ہے، اور منتخب کلائنٹس Pi کی طرف اشارہ کرتے ہیں۔ اہم بات یہ ہے کہ دو مختلف پیکٹ بہاؤ ایک ہی کیبل بانٹتے ہیں۔ کلائنٹ کا اندرونی پیکٹ Pi تک پہنچتا ہے اور سرنگ سے باہر جانا چاہیے؛ Pi کا اپنا خفیہ کردہ پیکٹ VPN ساتھی کی طرف اسی کیبل سے راؤٹر کی طرف باہر جانا چاہیے۔ وہ ایک ہی انٹرفیس پر مخالف سمتوں میں سفر کرتے ہیں اور مختلف سلوک درکار ہے۔
Pi کو اس کا پتہ نصب شدہ نیٹ ورک مینیجر کے ذریعے دیں، نہ کہ پرانی انٹرفیس فائل کی ترکیب سے جو آلے کے لیے اس سے لڑتی ہے۔ پھر کلائنٹس کو ترتیب دیں: ایک آلے پر جامد گیٹ وے، یا DHCP ریزرویشن جو 192.168.50.2 کو راؤٹر کے طور پر دیتا ہے۔ دو آلات کی خاطر راؤٹر کا پورا DHCP دائرہ نہ بدلیں، اور یہ نہ مانیں کہ کلائنٹ اس اختیار کا احترام کرتا ہے — تصدیق کریں۔
کمزوری ساختی ہے، قابلِ اصلاح نہیں۔ اس حصے کا کوئی بھی کلائنٹ 192.168.50.1 کی طرف اشارہ کر کے کھلے متن میں باہر جا سکتا ہے، اور دوسرا انٹرفیس یا سیلولر ریڈیو رکھنے والا آلہ آپ کا نفاذ کا راستہ مکمل طور پر چھوڑ دیتا ہے۔ اگر یہ جملہ متعلقہ آلے کے لیے ناقابلِ قبول ہے تو جواب آپ کے پاس پہلے سے ہے: ترتیب B استعمال کریں۔
ترتیب B: الگ پورٹ آلات کو اندر بند کرتا ہے
یہاں Pi اوپر کی لنک پر گیٹ وے 192.168.50.1 کے ساتھ 192.168.50.2 رکھتا ہے، اور منسلک آلات کے لیے دوسرے انٹرفیس پر 10.20.0.1/24 لیتا ہے۔ اب Pi دو نیٹ ورکس والا راؤٹر ہے، اور منسلک حصے کا بالکل ایک ہی اخراج ہے۔
عزم سے پہلے رینج کو باقی سب کے سامنے جانچیں: سرنگ کا اپنا سب نیٹ، دیگر سائٹ کے درمیان کے سابقے، اور VPN کے ذریعے قابلِ رسائی سب کچھ۔ دور دراز LAN سے ٹکرانے والا 10.20.0.0/24 وہ آدھا چلنے والا نتیجہ دیتا ہے جس کی تشخیص ایک شام لیتی ہے۔ اگر دوسرا پورٹ USB اڈاپٹر ہے تو تصدیق کریں کہ یہ معاون ہے اور اس کا نام نیٹ ورک مینیجر میں پن کریں تاکہ ری بوٹ کے بعد ترتیب بدلنا آپ کا LAN پتہ نہ ہلائے۔
DHCP سامع کو صرف اسی انٹرفیس پر چلائیں۔ اوپر کی لنک پر جواب دینے والا سرور ISP کے راؤٹر سے مقابلہ کرتا ہے اور آپ کے حصے کے پتے گھر کے باقی حصے کو دیتا ہے۔ اسے LAN انٹرفیس سے باندھیں، اعلان شدہ رینج تک محدود رکھیں، اور Pi کا اپنا پتہ تالاب سے باہر رکھیں۔
آگے بھیجنا، ترجمہ اور ناکامی پر بند ہونے کا قاعدہ
چار چیزیں اکثر ایک کہی جاتی ہیں اور ایک نہیں ہیں۔ آگے بھیجنا فعال کرنا (net.ipv4.ip_forward=1) کرنل کو صرف یہ بتاتا ہے کہ وہ انٹرفیسوں کے درمیان پیکٹ منتقل کر سکتا ہے؛ یہ بذاتِ خود کچھ اجازت نہیں دیتا اور کسی راستے کی ضمانت نہیں دیتا۔ اخراج منتخب کرنا روٹنگ کا فیصلہ ہے۔ پیکٹ کی اجازت دینا forward زنجیر میں پالیسی کا فیصلہ ہے۔ اس کے منبع کو دوبارہ لکھنا postrouting فیصلہ ہے۔ صرف پہلا کرنے والا ڈھانچہ ایسا Pi بناتا ہے جو کلائنٹ ٹریفک خوشی سے اوپر کی لنک سے باہر بھیجتا ہے۔
اجازت کو انہی ذرائع تک محدود کریں جن کا آپ نے ارادہ کیا اور اس انٹرفیس تک جسے ٹریفک استعمال کرنا چاہیے، اور واپسی کا راستہ اور Pi کی اپنی ضروری منزلیں شامل کریں۔ پھر اگر فراہم کنندہ آپ کا LAN سابقہ آپ کی طرف واپس روٹ نہیں کرتا تو سرنگ کے اخراج پر ترجمہ کریں۔ nftables کی کتابچہ آگے بھیجنے، مقامی اخراج اور منبع ترجمے کو الگ عمل سمجھتی ہے، اور یہاں یہی درست فکری نمونہ ہے۔
عام ناکامی جسمانی انٹرفیس پر وسیع masquerade قاعدہ ہے۔ تب ٹریفک ISP کے راستے انٹرنیٹ تک پہنچتا ہے، جبکہ کلائنٹ کی طرف سے یہ بالکل کام کرتے VPN جیسا دکھائی دیتا ہے۔ یہ کچھ ثابت نہیں کرتا۔ ترجمے کو اعلان شدہ اخراج سے باندھے رکھیں، اور اپنے قواعد اسی فائر وال میں رکھیں جو میزبان پہلے ہی استعمال کرتا ہے، مشترکہ postrouting زنجیر کو خالی کرنے والا حریف قواعد کا مجموعہ شامل کرنے کے بجائے۔
پھر سرنگ کی عدم موجودگی سے نمٹیں۔ وسیع طے شدہ راستہ نصب کرنے والا کلائنٹ پروفائل یہ بھی معنی رکھتا ہے کہ جب سرنگ گرے تو عام طے شدہ راستہ واپس آ سکتا ہے اور کلائنٹ ٹریفک خاموشی سے اوپر کی لنک پر لوٹ جاتا ہے۔ جہاں کھلے متن کی طرف واپسی قابلِ قبول نہیں, وہاں forward پالیسی کو کلائنٹ سے اوپر کی لنک تک ٹریفک کھلے طور پر مسترد کرنا ہوگا، اس حالت میں جب VPN کا راستہ جا چکا ہو۔ اسے مفروضے کے طور پر نہیں، مسترد قاعدے کے طور پر لکھیں۔ Pi کی اپنی خفیہ کردہ ترسیل VPN ساتھی کی طرف الگ local-output بہاؤ ہے اور اجازت یافتہ رہنا چاہیے، ورنہ سرنگ کبھی واپس نہیں آ سکتی۔
DNS اور IPv6 کو اپنا جواب درکار ہے
اگر کلائنٹس Pi کو حل کنندہ کے طور پر استعمال کریں تو وہ مقامی سامع تک پہنچتے ہیں اور Pi نیا استفسار شروع کرتا ہے۔ وہ اوپر کا استفسار کلائنٹس کے لیے آپ کے لکھے ہوئے forward قاعدے کا نہیں، Pi کے اپنے راستے کی پیروی کرتا ہے، اس لیے صرف سرنگ سے گزرنے والا کلائنٹ راستہ اور سیدھا باہر جانے والا حل کنندہ — یہ بغیر کسی خرابی کے پیغام کے رساؤ ہے۔ جان بوجھ کر فیصلہ کریں: سرنگ کے ذریعے پہنچنے والا حل کنندہ، یا مقامی جسے آپ سیدھا تسلیم کرتے ہیں، اور Pi کی اپنی اخراجی پالیسی کو اس فیصلے سے ہم آہنگ کریں۔
IPv6 پھر الگ معاملہ ہے۔ IPv4 کے لیے forward قاعدہ IPv6 کے بارے میں کچھ محدود نہیں کرتا، اور اوپر کی لنک پر راؤٹر کے اعلانات Pi کو، اور اس کے ذریعے منسلک حصے کو، آپ کی پالیسی سے بچنے والا دوسرا طے شدہ راستہ دے سکتے ہیں۔ یا تو اسی اصول پر IPv6 کو اپنا محفوظ راستہ دیں، یا کلائنٹ حصے پر اسے کھلے طور پر محدود کریں اور ایسا کہیں۔
بھروسہ کرنے سے پہلے حد جانچیں
ترتیب کو صرف چار الگ جانچوں کے بعد قبول کریں، کیونکہ ورغلانے والا واحد امتحان — ایک کلائنٹ پر براؤزر کھولنا — کئی ٹوٹی حالتوں میں کامیاب ہو جاتا ہے۔
تصدیق کریں کہ ایک حقیقی کلائنٹ سرنگ کے ذریعے انٹرنیٹ تک پہنچتا ہے، پھر تصدیق کریں کہ وہی کلائنٹ سرنگ بند ہونے پر انٹرنیٹ تک نہیں پہنچ سکتا۔ تصدیق کریں کہ DNS حل کام کرتا ہے اور استفسار وہیں سے باہر جاتا ہے جہاں آپ نے ارادہ کیا۔ تصدیق کریں کہ سرنگ دوبارہ شروع کرنے کے بعد بھی Pi کی اپنی ترسیل کام کرتی ہے، اور بحالی کے لیے مشین کے ری بوٹ کی ضرورت نہیں۔ آخر میں وہ آلہ دیکھیں جو آپ نے منتخب نہیں کیا: ترتیب A میں اسے معمول کے مطابق چلتا رہنا چاہیے، اور ترتیب B میں اسے اس حصے میں بالکل نہیں ہونا چاہیے۔
- دو پورٹ اور مسترد قاعدہ نفاذ دیتے ہیں؛ ایک پورٹ اور DHCP اختیار مشورہ دیتے ہیں۔
- غلط انٹرفیس پر ترجمہ کامیابی جیسا لگتا ہے اور نہیں ہے۔
- Pi کی اپنی ٹریفک، DNS اور IPv6 ہر ایک کو فیصلہ درکار ہے، اندازہ نہیں۔