مسکراڈ یا پالیسی پر مبنی روٹنگ: VPN گیٹ وے کے ذریعے LAN ٹریفک

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

دونوں ڈیزائن مختلف چیزوں کا وعدہ کرتے ہیں

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

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

ناکامی کے طریقے وعدوں جتنے ہی مختلف ہیں۔ غیر موجود مسکراڈ اصول ایسے پیکٹ بناتا ہے جو نجی ماخذ کے ساتھ نکلتے ہیں اور کبھی واپس نہیں آتے۔ غیر موجود واپسی راستہ پالیسی پر مبنی روٹنگ میں وہی علامت دیتا ہے، لیکن اصلاح گیٹ وے پر نہیں، دور کے راؤٹر پر ہوتی ہے۔

مسکراڈ: دور کے کنارے پر ایک ساتھی

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

DNS ایک الگ فیصلہ ہے۔ دور کے کنارے کا حل کنندہ صرف اسی صورت جواب دیتا ہے جب اس کا جواب کلائنٹ تک واپس جا سکے۔ مسکراڈ کے تحت استفسار گیٹ وے سے آتا دکھتا ہے، اس لیے حل کنندہ کا واپسی راستہ پہلے ہی پورا ہے؛ پالیسی پر مبنی روٹنگ کے تحت حل کنندہ کو کسی بھی دوسری دور کی سروس کی طرح وہی واپسی راستہ درکار ہے۔

پالیسی پر مبنی روٹنگ: ماخذ رکھیں، واپسی راستہ شامل کریں

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

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

پھر دور کے کنارے کو LAN سابق کو ٹنل سے واپس روٹ کرنا ہوتا ہے۔ یہ اس گیٹ وے پر نہیں، دور کے راؤٹر پر ترتیب ہے۔ گیٹ وے کو ایسے جوابات بھی قبول کرنے ہوتے ہیں جو مرکزی جدول کی توقع سے مختلف انٹرفیس پر آئیں؛ جب سخت موڈ ان پیکٹوں کو گرا دیتا ہے تو ڈھیلی الٹی راستہ فلٹرنگ (rp_filter 2 پر مقرر) عام ایڈجسٹمنٹ ہے۔

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

ملکیت اور اس بات کی بنیاد پر فیصلہ کریں کہ دور کا کنارہ کیا ریکارڈ کرتا ہے

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

اگر دونوں کنارے آپ کے ہوں اور دور کی سروسز ماخذ پتوں پر عمل کریں تو پالیسی پر مبنی روٹنگ اپنے اضافی راستے کی حقدار ہے۔ تب فائر وال اصول، فی صارف رسائی اور آڈٹ لاگ کلائنٹس میں فرق کر سکتے ہیں۔ اگر دور کے کنارے کو صرف رسائی درکار ہو تو مسکراڈ آسان ہے اور واپسی راستے کی غلطیوں کی ایک پوری قسم ہٹا دیتا ہے۔

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

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

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

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

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