دو کلائنٹ گروپس، ایک سرور: پالیسی کہاں نافذ کریں

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

سب نیٹ ایک لیبل ہے، قاعدہ نہیں

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

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

وہ راستہ چنیں جو ہم منصبوں کی ٹریفک لے جاتا ہے

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

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

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

قواعد لکھنے سے پہلے میٹرکس لکھیں

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

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

قواعد وہاں رکھیں جہاں وہ بچیں

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

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

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

دونوں طرف سے ثابت کریں

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

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