VPN سے VLAN تک رسائی: قواعد سے پہلے میٹرکس بنائیں
ایک طرف کردار، دوسری طرف خدمات۔ پانچ جانچیں ایک غیر واضح VPN سے VLAN تک رسائی کے ڈیزائن کو ایسی جدول میں بدل دیتی ہیں جسے فائر وال کا مالک نافذ کر سکے۔
فائر وال کی نحو سے نہیں، میٹرکس سے شروع کریں۔ جس جدول میں ایک طرف کردار اور دوسری طرف خدمات ہوں، اسے کسی ایپلیکیشن کا مالک دیکھ سکتا ہے، سیکیورٹی کا مالک اس پر بحث کر سکتا ہے اور گیٹ وے رکھنے والا کوئی بھی نافذ کر سکتا ہے۔ وہ جائزہ ان قواعد کو ڈیبگ کرنے سے سستا ہے جن پر کبھی کوئی متفق نہیں ہوا۔
اسے لکھنے کا ایک گھنٹہ بعد میں ایک ہفتے کی قواعد کی آثارِ قدیمہ بچاتا ہے۔ ڈیزائن بتاتا ہے کہ کون کس خدمت تک پہنچتا ہے، اور دوبارہ نمبر بندی کے بعد بچنے والا حصہ یہی ہے۔
مرحلہ 1: نیٹ ورکس سے پہلے کرداروں کے نام رکھیں
سوئچ سے نہیں، لوگوں سے شروع کریں۔ دور سے جڑنے والے ہر گروہ اور وہ گروہ کیا کرتا ہے بتانے والا ایک جملہ لکھیں، مثلاً اسٹاک کی سطح پڑھنے والے گودام کے عملے یا ایک انضمام سنبھالنے والا ٹھیکیدار۔ اگر دو گروہوں کو ایک جیسی رسائی ملے تو اس مقصد کے لیے وہ ایک کردار ہیں۔
اگر کوئی کردار صرف تنظیمی چارٹ کی وجہ سے ہو تو یہیں رکیں۔ جس کردار کی اپنی الگ خدمت کی ضرورت نہ ہو وہ یکساں خلیوں کی قطار بن جاتا ہے، اور یکساں قطاریں کسی کو بعد میں سہولت کے لیے پورا ذیلی نیٹ دینے پر آمادہ کرتی ہیں۔ لوگ کیا کرتے ہیں اس کی بنیاد پر تقسیم کریں، ان کے اخراجات پر کون دستخط کرتا ہے اس کی بنیاد پر نہیں۔ چھوٹے دفتر کے لیے چھ کردار عموماً زیادہ ہوتے ہیں اور تین اکثر درست ہوتے ہیں۔
مرحلہ 2: ہر خلیے کو خدمت کا بیان بنائیں
جس خلیے میں «ایپلیکیشنز» لکھا ہو وہ جانچا نہیں جا سکتا۔ جس خلیے میں «اسٹاف پول سے 443 پر ERP ہوسٹ تک HTTPS» لکھا ہو وہ جانچا جا سکتا ہے۔ ہر نیٹ ورک کے نام کو منزل، پروٹوکول اور پورٹ سے بدلیں، پھر وہ انحصار شامل کریں جس کے بغیر خدمت نہیں چلتی، مثلاً اندرونی حل کنندہ یا شناخت فراہم کرنے والا۔
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
سمت کا کالم سب سے مہنگی غلطیاں پکڑتا ہے۔ عملے کو ایپلیکیشن کھولنے کی اجازت کا مطلب یہ نہیں کہ ایپلیکیشن سرورز عملے کے لیپ ٹاپ کی طرف واپس رابطے کھول سکیں، اور پہلی سمت کی اجازت دینے والا حالت والا قاعدہ اکثر دوسری کی اجازت سمجھ کر پڑھا جاتا ہے۔
مرحلہ 3: فیصلہ کریں کہ شناخت کہاں پالیسی بنتی ہے
کسی کو تصدیق شدہ سیشن کو ایسے کردار میں بدلنا ہوگا جسے گیٹ وے نافذ کر سکے۔ معاون اختیارات میں تصدیق کے بیک اینڈ کی فراہم کردہ گروپ پالیسی، قابلِ اعتماد سیشن خصوصیات، یا ہر کردار کے لیے الگ پتوں کے پول شامل ہیں۔ تینوں کام کرتے ہیں؛ کلائنٹ کی بھیجی ہوئی لیبل کام نہیں کرتی۔ وہ طریقہ منتخب کریں جو آپ کا گیٹ وے دستاویز کرتا ہے، وہ نہیں جو کوئی فورم پوسٹ بیان کرتی ہے۔
ایسا پتہ دینا جو صرف VLAN کا لگتا ہو، دوسرے لباس میں وہی بے جوابی ہے۔ OpenVPN فائر وال قواعد کے بارے میں Netgate کی رہنمائی اس علیحدگی کو واضح کرتی ہے: سرنگ کے اوپر آنے دینا اس میں سے ٹریفک گزرنے دینے سے الگ فیصلہ ہے۔
لکھیں کہ آپ نے کون سا طریقہ چنا اور وہ کہاں تشکیل شدہ ہے۔ جب کوئی کردار بدلتا ہے تو وہ نوٹ ایک ترمیم اور تین انٹرفیس میں تلاش کے درمیان فرق ہے۔ یہ آڈیٹر کو یہ بھی بتاتا ہے کہ پہلے کہاں دیکھنا ہے۔
مرحلہ 4: وہ ماخذ پتہ دیکھیں جو منزل دیکھتی ہے
حد پر فارورڈنگ پالیسی کو اصل ماخذ سے مطابقت رکھنی چاہیے۔ اگر گیٹ وے VPN کلائنٹس کو اپنے پتے میں ترجمہ کرتا ہے تو نیچے کا ہر فائر وال ایک ہی ماخذ دیکھتا ہے اور کردار کے مطابق فیصلہ کرنے کی صلاحیت کھو دیتا ہے۔ اگر وہ کلائنٹ کا پتہ محفوظ رکھتا ہے تو اس پول کے لیے واپسی کا راستہ موجود ہونا چاہیے۔
حتمی قواعد لکھنے سے پہلے دونوں سمتیں جانچیں، پھر مشاہدہ شدہ ماخذ کو ہر خلیے کے پاس درج کریں۔ وہی جانچ دو مختلف کرداروں سے چلائیں اور نتیجے کا موازنہ کریں۔ اگر دونوں گیٹ وے کا پتہ دکھائیں تو کرداروں کا فرق پہلے ہی ختم ہو چکا ہے۔ ایسا میٹرکس جو محفوظ پتوں کو فرض کرتا ہے جبکہ گیٹ وے ماخذ کا ترجمہ کر رہا ہو، پہلے نچلے ACL پر ناکام ہوتا ہے۔
مرحلہ 5: جاری کرنے سے پہلے ہر خلیے کی جانچ کریں
ہر اجازت شدہ خلیے کو ایک نمائندہ عمل میں اور ہر مسترد خلیے کو منفی صورت میں بدلیں۔ دونوں کو اصل کردار والے کلائنٹ سے چلائیں، گیٹ وے کنسول سے نہیں، کیونکہ کنسول اس راستے سے گزرتا ہے جس کی آپ جانچ کر رہے ہیں۔
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'جڑنے والی منفی صورت ایک دریافت ہے، اتفاق نہیں، اور قاعدہ درست ہونے تک اس کا مقام میٹرکس میں ناکام خلیہ ہے۔ جانچ کے احکام جدول کے پاس رکھیں تاکہ اگلا جائزہ لینے والا استدلال دوبارہ بنانے کے بجائے انہیں دوبارہ چلائے۔
مکمل جدول اس گیٹ وے سے زیادہ عرصہ زندہ رہتی ہے جس کے لیے لکھی گئی۔ قواعد فرم ویئر اور وینڈر کے ساتھ بدلتے ہیں، جبکہ وہ قطار جو کہتی ہے ٹھیکیدار ایک پروجیکٹ خدمت تک پہنچتا ہے، اس کام کے بدلنے تک درست رہتی ہے۔