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

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

نام ایسی شناخت نہیں جسے ہر پرت جانچ سکے

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

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

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

ہر پرت کیا شناخت کر سکتی ہے

جدول کو درمیانی ستون سے باہر کی طرف پڑھیں: پرت جو شناخت کنندہ دیکھ سکتی ہے وہی طے کرتا ہے کہ وہ ایمانداری سے کون سی پالیسی نافذ کر سکتی ہے۔

LayerIdentifier it seesWhat it cannot see
Packet filteraddress, protocol, portthe name, or which other services share that address
DNS policythe queried name and the answer handed backconnections made by clients that ignore the resolver
Managed browsersupported URL patterns on managed profilesnon-browser clients, or unmanaged devices
CONNECT proxyhost and port for tunnelled requeststhe path inside an encrypted request

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

جہاں واضح قاعدہ ناکام ہوتا ہے

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

زیر انتظام براؤزر پالیسی کاپی کی گئی پتوں کی فہرست سے زیادہ براہ راست ویب پابندی بیان کرتی ہے، لیکن یہ ان براؤزرز اور پروفائلز پر لاگو ہوتی ہے جنہیں انتظامی نظام کنٹرول کرتا ہے۔

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

کمانڈ سے نہیں، کلائنٹس سے منتخب کریں

پوچھیں کہ پالیسی کو کون سے کلائنٹس محیط ہونے چاہئیں اور کون رہ سکتے ہیں۔ زیر انتظام براؤزر پالیسی وہ محیط ہوتی ہے جہاں تک انتظامی نظام پہنچتا ہے اور براؤزر کی حد پر رک جاتی ہے۔ حل کنندہ پالیسی وہ سب محیط ہوتی ہے جو آپ کا حل کنندہ استعمال کرتا ہے، جو زیادہ وسیع مجموعہ ہے، اور جو ایسا نہیں کرتے ان کے لیے یہ کھلے طور پر ناکام ہوتی ہے۔

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

قاعدہ وسیلے کے اعتبار سے لکھیں

قابل دفاع پالیسی وسیلے، شناختوں، دائرے کی ایپلیکیشنوں اور انہیں لے جانے والے راستے کا نام لیتی ہے، استعمال میں موجود دونوں پتہ خاندانوں سمیت۔ یہ یہ بھی بتاتی ہے کہ اس مشترکہ بنیادی ڈھانچے کا کیا ہوگا جسے قاعدہ اتفاقاً متاثر کرے گا۔

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

متعلقہ مضامین