OpenBSD VPN گیٹ وے پر tun0 کے ذریعے LAN کا NAT

ایک ہی OpenBSD گیٹ وے والے دو انجینئرز اکثر آپ کو دور دراز نیٹ ورک تک پہنچنے کے لیے دو مختلف اصولوں کے مجموعے دیتے ہیں، اور دونوں کا دفاع کیا جا سکتا ہے۔ ماخذ ترجمہ اور واپسی راستے کے درمیان انتخاب بالکل بھی نحو کا سوال نہیں ہے۔ یہ اس بات پر منحصر ہے کہ سامنے والا فریق 192.168.88.0/24 کے بارے میں پہلے سے کیا جانتا ہے اور آپ کو اپنے لاگز میں کیا رکھنا ہے۔ یہاں غلطی کریں تو nat-to کی سطر بالکل درست دکھائی دے گی جبکہ جوابات دور دراز کے طے شدہ گیٹ وے میں غائب ہو جائیں گے۔

روٹنگ اور دوبارہ لکھنا مختلف سوالوں کے جواب دیتے ہیں

روٹنگ ٹیبل فیصلہ کرتا ہے کہ 172.20.0.0/16 تک tun0 کے ذریعے پہنچا جا سکتا ہے، اور یہ فیصلہ کسی بھی pf ترجمے سے مشورہ کرنے سے پہلے ہوتا ہے۔ پھر ماخذ ترجمہ پیکٹ کی سرخی بدلتا ہے تاکہ دور والا سرا LAN ہوسٹ کے بجائے گیٹ وے کا ٹنل پتہ دیکھے۔ کوئی بھی طریقہ دوسرے کی جگہ نہیں لیتا: nat قاعدہ راستہ پیدا نہیں کر سکتا، اور راستہ ایسے دور دراز راؤٹر کو قائل نہیں کر سکتا جس نے آپ کے نجی ذیلی نیٹ کے بارے میں کبھی نہیں سنا۔ جب سامنے والے فریق کے پاس واپسی کا راستہ نہ ہو تو جوابات رد کر دیے جاتے ہیں یا اس کے طے شدہ گیٹ وے کی طرف بھیج دیے جاتے ہیں، اور اصولوں کی کتنی ہی اصلاح اسے درست نہیں کرتی۔

آسان الفاظ میں، فارورڈنگ بتاتی ہے کہ ٹریفک کہاں جاتی ہے اور ترجمہ بتاتا ہے کہ یہ کہاں سے آتا دکھائی دیتا ہے۔ اصولوں کا مجموعہ ترتیب دیتے وقت دونوں کو الگ ذہنی ڈبوں میں رکھیں۔

فیصلہ کرنے والی تین شرطیں

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

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

ٹکڑا اس طرح رکھیں کہ pf واقعی اس کا جائزہ لے

نیچے دیا گیا ٹکڑا فرض کرتا ہے کہ LAN 192.168.88.0/24 ہے، دور دراز نیٹ ورک 172.20.0.0/16 ہے اور ٹنل انٹرفیس tun0 ہے۔ اس میں کوئی چیز اگلا قدم منتخب نہیں کرتی۔ یہ صرف ان پیکٹوں پر ماخذ دوبارہ لکھتا ہے جو پہلے ہی ٹنل کے ذریعے باہر جا رہے ہیں۔

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

اس پہلی سطر کی دو تفصیلیں سب سے زیادہ بوجھ اٹھاتی ہیں۔ tun0 کے گرد بریکٹ pf کو کہتے ہیں کہ جب بھی حالت کا اندراج بنائے انٹرفیس کا پتہ پڑھے، جو دوبارہ جڑنے کے بعد ٹنل کے نئے نمبر ملنے پر اہم ہوتا ہے۔ لفظ match کا مطلب ہے کہ قاعدہ دوبارہ لکھتا ہے اور پھر نیچے گر جاتا ہے، اس لیے الگ pass قاعدہ کو اب بھی بہاؤ کی اجازت دینی ہوگی۔ match سطر میں نامزد انٹرفیس بھی وہی ہونا چاہیے جسے روٹنگ ٹیبل منتخب کرتا ہے، ورنہ pf قاعدے کا جائزہ پیکٹ کے اصل راستے سے مختلف اخراجی راستے پر کرے گا۔

کرنل کا پہلو نہ بھولیں۔ IPv4 فارورڈنگ فعال ہونی چاہیے، اور ٹنل اور LAN کے لیے حالت والے pass قواعد اس سب کے معنی بننے سے پہلے موجود ہونے چاہئیں۔ یہاں کلیدی الفاظ کی ترتیب کے لیے OpenBSD FAQ کا PF NAT حصہ درست حوالہ ہے۔

ٹریفک پر بھروسہ کرنے سے پہلے اصولوں کے مجموعے کی تصدیق کریں

پہلے pfctl -nf /etc/pf.conf سے نحو جانچیں، جو فائل کو لوڈ کیے بغیر تجزیہ کرتا ہے۔ پھر پالیسی لوڈ کریں اور پڑھیں کہ کرنل واقعی کیا رکھتا ہے، کیونکہ صاف تجزیہ شدہ قاعدہ بھی چھایا میں رہ سکتا ہے یا غلط انٹرفیس سے جڑ سکتا ہے۔ pfctl -sn ترجمے کے قواعد کو ان کی لوڈ شدہ شکل میں چھاپتا ہے، اور pfctl -sr فلٹر قواعد کو جانچ کی ترتیب میں چھاپتا ہے۔

پھر تار پر نظر رکھیں۔ گیٹ وے پر tcpdump -ni tun0 'host 172.20.0.10' دکھاتا ہے کہ ٹنل سے باہر نکلنے والا ماخذ پتہ ٹنل کا پتہ ہے یا LAN ہوسٹ۔ تیز netstat -rn -f inet تصدیق کرتا ہے کہ منزل کس انٹرفیس پر حل ہوتی ہے۔ ٹریفک بہنے لگے تو pfctl -ss حالت کے اندراجات کی فہرست دیتا ہے؛ اگر کسی بہاؤ نے حالت نہ بنائی، تو پیکٹ کبھی حالت بنانے والے قاعدے سے نہیں ٹکرایا۔

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

جب ترجمہ بچت سے زیادہ مہنگا پڑے

ترجمہ کلائنٹس کو چھپاتا ہے، اور کبھی کبھی یہی غلط سودا ہوتا ہے۔ ایک دوسرے پر چڑھتے ذیلی نیٹ ایک صورت ہیں: اگر سامنے والا فریق اندرونی طور پر بھی 192.168.88.0/24 استعمال کرتا ہے، تو LAN ہوسٹوں کو گیٹ وے کے طور پر پیش کرنا ٹکراؤ کو بہتر کرنے کے بجائے مزید خراب کرتا ہے۔ پتہ جوڑے کے مطابق ٹریفک منتخب کرنے والی IPsec پالیسیاں دوسری صورت ہیں، کیونکہ سلامتی پالیسی کا ڈیٹا بیس ترجمے سے پہلے ملایا جاتا ہے اور آپ کا دوبارہ لکھا پیکٹ کبھی نہیں دیکھتا۔ ہر وہ تعیناتی جو فی صارف بل کرتی، محدود کرتی یا آڈٹ کرتی ہے، وہ بھی وہ شناخت کھو دیتی ہے جس کی اسے اس لمحے ضرورت ہوتی ہے جب ماخذ ایک ہی پتے پر سمٹ جاتا ہے۔

قابلِ منتقلی pf ماخوذات الگ جال ہیں۔ جو مصنوعات اپنی اصول فائلیں خود بناتی ہیں وہ توقع کرتی ہیں کہ NAT ان کے انٹرفیس سے ترتیب دیا جائے گا، اور ہاتھ سے ترمیم شدہ ٹکڑے اگلی لوڈنگ پر اوپر لکھ دیے جاتے ہیں۔ match کا کلیدی لفظ وجود میں آنے سے پہلے لکھی گئی رہنماؤں سے نقل کیے گئے اصولوں کے مجموعے موجودہ کرنل پر لوڈ نہیں ہوں گے، اس لیے نحو منتقل کریں اور اندازہ لگانے کے بجائے خرابی پڑھیں۔

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