ایک اور NAT شامل کرنے سے پہلے نجی LAN کے درمیان روٹنگ کریں

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

ڈیزائن طے کرنے والی تین شرطیں

پہلی شرط پتہ جگہ ہے۔ اگر دونوں LAN ایک ہی RFC 1918 بلاک استعمال کرتے ہیں، تو روٹنگ انہیں الگ نہیں کر سکتی اور ترجمہ اختیاری کے بجائے ناگزیر ہو جاتا ہے۔ دوسری واپسی راستہ ہے: A سے B تک راستہ تب تک بیکار ہے جب تک B کو بھی یہ معلوم نہ ہو کہ A کے LAN تک کیسے پہنچنا ہے، اور غیر متوازن علم ہی وہ عام ترین وجہ ہے جس سے روٹ شدہ ڈیزائن خاموشی سے جواب گرا دیتا ہے۔

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

سادہ ڈیزائن تب ہی جیتتا ہے جب تینوں ایک ہی سمت اشارہ کریں۔ اگر ان میں سے کوئی ناکام ہو، تو اس شرط کو ترجمے سے ڈھانپنے کے بجائے واضح طور پر درست کریں، کیونکہ NAT ناکامی چھپاتا ہے، حل نہیں کرتا۔

ٹرانزٹ نیٹ ورک پر راستہ منصوبہ بنائیں

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

فائر وال A 10.30.0.0/24 کی خدمت کرتا ہے اور فائر وال B 10.40.0.0/24 کی، جبکہ دونوں ٹرانزٹ پتے 192.0.2.0/24 میں ہیں۔ ہر LAN ہوسٹ اپنے مقامی فائر وال کو گیٹ وے رکھتا ہے، اس لیے واحد نئی حالت ہر طرف ایک راستہ ہے۔ Linux پر مبنی فائر وال میں وہی منصوبہ ایسا دکھتا ہے، اور فارورڈنگ فعال ہونی چاہیے، ورنہ راستہ حل ہو جائے گا جبکہ پیکٹ گرا دیا جائے گا۔

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

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

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

پھر یہ نتیجہ اخذ کرنے سے پہلے کہ کوئی NAT نہیں ہو رہا، باہر جانے والا ترجمہ دیکھیں۔ خودکار باہر جانے والے قواعد ایسی ٹریفک دوبارہ لکھ سکتے ہیں جو کبھی ترجمے کے لیے نہ تھی، اور یہ دوسرے فریق کے اپنے پالیسی اور لاگ کے لیے درکار ماخذ پتے تباہ کر دیتا ہے۔ تصدیق کریں کہ منتخب بہاؤ اپنے اصل پتے برقرار رکھتے ہیں، اور جس ٹریفک کو ابھی بھی ضرورت ہے اس کے لیے انٹرنیٹ ترجمہ قواعد کو اچھوت چھوڑ دیں۔

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

جب NAT ہی ایماندار جواب ہو

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

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

جب ٹرانزٹ خود غلط مفروضہ ہو

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

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