سائٹ ٹو سائٹ VPN کے لیے کیا درج کریں: سلیکٹرز اور دائرہ

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

ترتیب دیا گیا طے شدہ نہیں ہے

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

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

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

روٹ پر مبنی ٹنل مختلف طریقے سے چنتے ہیں

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

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

ترجمہ اسی جدول میں آتا ہے

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

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

نجی DNS اسی جگہ آتا ہے۔ ایسا نام جو متعلقہ سائٹ سے ناقابل استعمال پتے پر حل ہو، سپورٹ ٹکٹ کے ساتھ منسلک دستاویزی خرابی ہے، اور الزام ٹنل پر ڈالا جائے گا۔

سروس کی ضرورت منسلک کریں

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

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

ریکارڈ کو ٹیسٹ پلان بنائیں

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

swanctl --list-sas

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

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

صرف گیٹ وے تک پنگ قبولیت کا ٹیسٹ نہیں ہے۔ یہ کبھی ٹرانزٹ راستہ استعمال نہیں کرتا، اس لیے یہ کامیاب ہو سکتا ہے جبکہ ہر فارورڈ ہونے والا بہاؤ ناکام ہو۔ ایک طرف کے ہوسٹ سے دوسری طرف کی سروس تک ٹیسٹ کریں اور تصدیق کریں کہ جواب ٹنل سے آتا ہے۔ اگر صرف پنگ کامیاب ہو، تو ریکارڈ نے ابھی وہی فارورڈنگ مسئلہ ڈھونڈ لیا ہے جسے روکنے کے لیے لکھا گیا تھا۔ فارورڈنگ کے بارے میں strongSwan دستاویز وضاحت کرتی ہے کہ Linux پیر پر سلیکٹرز، روٹس اور فارورڈنگ کیسے تعامل کرتے ہیں۔