فون کی Wi-Fi Calling توڑے بغیر IPsec کو روکنا

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

پروٹوکول کا نام لینے سے پہلے سروس کا نام لیں

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

Apple کا سروس پورٹ حوالہ Wi-Fi Calling کے لیے UDP 500 اور 4500 درج کرتا ہے، جو بالکل وہی جوڑی ہے جسے زیادہ تر عمومی IPsec بلاک چھوڑ دیتے ہیں۔ ان پورٹس کے ساتھ تبدیلی ریکارڈ میں خصوصیت کا نام لکھیں۔ استعمال شدہ حوالے کا ورژن یا تاریخ شامل کریں، کیونکہ فروشوں کے جدول میں ترمیم ہوتی ہے۔ جو قاعدہ اپنی موجودگی کی سروس کا نام لیتا ہے اس کا جائزہ ہو سکتا ہے؛ جو پروٹوکول کی قسم کا نام لیتا ہے اس کا نہیں۔

استثنا کو احسان نہیں، معاہدہ بنا کر لکھیں

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

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

عارضی فون مرمت کا لیبل لگی مستقل اجازت دو سال بعد دفاع کے قابل نہیں۔ شناخت شدہ سروس سے بندھی اجازت کی میعاد ہوتی ہے جو جان بوجھ کر تجدید ہوتی ہے۔

ماخذ کو ایمانداری سے محدود کریں

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

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

پورٹ قاعدہ جو نہیں بتا سکتا اسے قبول کریں

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

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

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

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

خصوصیت اور ممانعت کی تصدیق کریں

منظور شدہ جانچ ایک عام Wi-Fi کال پر، اسی آلے کی قسم سے چلائیں جس کے لیے استثنا ہے، اور تصدیق کریں کہ خارج شدہ کلائنٹ اب بھی ناکام ہوتا ہے۔ کسی بھی صورت میں ہنگامی کال کو آزمائشی کیس نہ بنائیں۔ پھر جاری شدہ قاعدے کا معائنہ کریں، کیونکہ صفر پر رکا کاؤنٹر اس بات کا تیز ترین ثبوت ہے کہ استثنا کبھی ملا ہی نہیں:

nft -a list chain inet edge forward

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