مسدود کردن IPsec بدون خراب کردن Wi-Fi Calling گوشی
شش بررسی، یک مسدودسازی کلی پروتکل را به استثنای سرویسی تبدیل می‌کند که می‌توانید از آن دفاع کنید: ویژگی، منبع، مقصدها، محدوده و تاریخ بازبینی.
درخواست همیشه به یک شکل می‌رسد: IPsec را در لبه ببندید چون تونل‌هایی را حمل می‌کند که هیچ‌کس تأیید نکرده است، و اولین شکایت از کسی می‌آید که تلفنش دیگر از طریق Wi-Fi تماس نمی‌گیرد. هر دو واقعیت همزمان درست‌اند و هیچ‌کدام کنار گذاشتن کنترل را توجیه نمی‌کند. آنچه دیوار آتش لازم دارد یک استثنای سرویس با ویژگی نام‌دار، منبع محدود، مقصدهای مستند و یک مسئول است. پنج گام آن را به قاعده‌ای تبدیل می‌کند که یک غریبه سال آینده می‌تواند بازبینی کند.
پیش از نام بردن پروتکل، سرویس را نام ببرید
تلفن رومیزی روی یک سرویس SIP و گوشی‌ای که Wi-Fi Calling اپراتور را انجام می‌دهد پروفایل شبکه مشترکی ندارند، و VoIP به‌عنوان اصطلاح دیوار آتش هیچ‌کدام را توصیف نمی‌کند. داده‌های پورت و مقصد باید از فروشنده یا اپراتوری بیاید که سرویس را اداره می‌کند، نه از فهرست پورت به‌خاطرمانده‌ای که به سیستم تلفن دیگری تعلق دارد. این تفاوت میان قاعده‌ای است که از یک ویژگی محافظت می‌کند و قاعده‌ای که از یک واژه محافظت می‌کند.
« مرجع پورت‌های سرویس » اپل برای 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 dropnftables به ترتیب ارزیابی می‌کند و در اولین تطابق می‌ایستد، پس اجازه محدود باید بالای منع کلی باشد. جای این دو را عوض کنید و استثنا بی‌صدا هیچ کاری نمی‌کند.
ویژگی و منع را اعتبارسنجی کنید
اعتبارسنجی تأییدشده را روی یک تماس معمولی Wi-Fi، از همان کلاس دستگاهی که استثنا برایش وجود دارد اجرا کنید و تأیید کنید که یک کلاینت حذف‌شده هنوز شکست می‌خورد. تحت هیچ شرایطی از تماس اضطراری به‌عنوان مورد آزمایش استفاده نکنید. سپس قاعده‌ای را که ابلاغ شده بازرسی کنید، چون شمارنده‌ای که روی صفر مانده سریع‌ترین مدرک است که استثنا هرگز تطابق نیافته:
nft -a list chain inet edge forwardدر آزمایش یک اتصال دوباره یا تغییر شبکه بگنجانید و آن را از شروع سرد تکرار کنید، وقتی گوشی تازه به شبکه می‌پیوندد نه آنکه از قبل متصل باشد. اگر شمارنده حرکت کند در حالی که تماس‌ها همچنان شکست می‌خورند، مشکل از دیوار آتش خارج شده و مربوط به فهرست مقصدهای اپراتور است.