VPN سے جڑے دو دفتروں کے درمیان رسائی کو کیسے محدود کریں

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

اسی ترتیب سے کام کریں، اور جب تک نیچے دیے گئے پالیسی مراحل پاس نہ ہوں سرنگ کا راستہ نہ بڑھائیں۔

گیٹ وے کو چھونے سے پہلے میٹرکس لکھیں

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

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

جہاں پیکٹ ڈکرپٹ ہوتے ہیں وہیں نافذ کریں

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

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT اور متوازی سب نیٹ قواعد بدل دیتے ہیں

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

متوازی رینجیں دوسرا جال ہیں۔ دونوں 192.168.1.0/24 استعمال کرنے والے دو دفتروں کو ایک طرف کی میپنگ کے بغیر ایک پالیسی جدول میں بیان نہیں کیا جا سکتا، اور میپنگ ٹکراؤ سے پاک ایڈریسنگ کا متبادل نہیں ہے۔ بعد میں کھولنے والے قواعد لکھنے سے پہلے منصوبہ درست کریں۔

انکار ثابت کریں، صرف کامیابی نہیں

صرف اجازت شدہ ایپلیکیشن کی جانچ بہت کم ثابت کرتی ہے، کیونکہ اوپر کہیں ایک نرم قاعدہ وہی نتیجہ دیتا ہے۔

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

فہرست کو زندہ رکھیں

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

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