بررسی و رفع خطای Unresolved FQDN در Policyهای FortiGate

مقدمه و معرفی مشکل

در دنیای پیچیده فایروال‌های نسل جدید، FortiGate یکی از راهکارهای پیشرو و قدرتمند برای تأمین امنیت شبکه است. با این حال، گاهی حتی در چنین سیستم‌های پایدار و کاملی، مدیران شبکه با خطاهای به ظاهر عجیبی روبرو می‌شوند که اگرچه ممکن است عملکرد اصلی را مختل نکنند، اما باعث سردرگمی و ایجاد نگرانی‌های کاذب می‌شوند. یکی از این خطاهای رایج، که به ویژه در نسخه‌های خاصی از سیستم عامل FortiOS مانند ۷.۲.۶ و ۷.۲.۷ ظاهر شد، خطای “Unresolved FQDN” در Policyها است. این خطا زمانی خود را نشان می‌دهد که شما یک شیء (Object) از نوع FQDN (مانند support.fortinet.com) تعریف کرده و آن را در یک پالیسی استفاده می‌کنید، اما رابط گرافیکی (GUI) فایروال با نمایش هشدار “Unresolved” در کنار آن، این تصور را ایجاد می‌کند که فایروال قادر به تبدیل (Resolve) آن نام دامنه به آدرس IP نیست. در این مقاله، به صورت عمقی به بررسی ریشه این مشکل، تأثیرات واقعی آن بر عملکرد فایروال و ارائه راهکارهای جامع و tested شده برای رفع آن می‌پردازیم.

برای استعلام قیمت و خرید تجهیزات فورتی نت با کارشناسان وینو سرور تماس بگیرید.

ریشه‌یابی و تشخیص مشکل

این تناقض ظاهری یعنی نمایش خطا در GUI در حالی که فایروال در پس‌زمینه به درستی در حال Resolve کردن دامنه است نخستین نشانه از یک “مشکل نمایشی” (Cosmetic Bug) است، نه یک اختلال عملکردی در موتور فیلترینگ. ریشه این مشکل به یک باگ یا عقب‌گرد (Regression) در کد FortiOS در نسخه‌های ذکر شده بازمی‌گردد، جایی که ماژول رابط گرافیکی وب به درستی قادر به دریافت و نمایش لیست آدرس‌های IPای که یک FQDN به آنها Resolve می‌شود، نیست. برای اطمینان کامل از این موضوع و اثبات اینکه فایروال در حال انجام صحیح وظیفه خود است، می‌توانید از دستورات تشخیصی (Diagnostic Commands) در خط فرمان (CLI) استفاده کنید.

استفاده از CLI برای تأیید عملکرد

دو دستور بسیار کاربردی در این زمینه عبارتند از:

diagnose firewall fqdn list-ip: این دستور تمام FQDNها و آدرس‌های IP Resolve شده مربوط به آن‌ها را نشان می‌دهد.

diagnose test application dnsproxy 6: این دستور اطلاعات دقیق‌تری از کش DNS پروکسی فایروال، از جمله TTL و آدرس‌های Resolve شده، در اختیار شما قرار می‌دهد.

خروجی این دستورات به وضوح تأیید می‌کند که FQDN مورد نظر شما به درستی Resolve شده است. در تصویر زیر، می‌توانید نمای GUI که خطای “Unresolved” را نشان می‌دهد، در کنار خروجی سالم دستورات CLI مشاهده کنید که این تناقض را به خوبی نمایان می‌سازد.

تصویر ۱ :

تأثیر واقعی و راه حل اصلی

اگرچه این خطا یک مشکل نمایشی محسوب شده و معمولاً بر عملکرد واقعی فایروال و امکان دسترسی کلاینت‌های پشت آن به مقصد تأثیر نمی‌گذارد، اما وجود این هشدار در رابط مدیریتی می‌تواند برای مدیران شبکه آزاردهنده باشد و در ممیزی‌ها و عیب‌یابی‌های آینده ایجاد ابهام کند. خوشبختانه، تیم فورتی‌نت این مشکل را شناسایی کرده و آن را در نسخه‌های FortiOS v7.2.8 و v7.4.4 به طور کامل برطرف ساخته است. بنابراین، اولین و بهترین راه حل، ارتقاء سیستم عامل فایروال به یکی از این نسخه‌ها یا نسخه‌های جدیدتر و پایدارتر است.

راه حل جایگزین و کاربردی

با این حال، در شرایطی که امکان ارتقاء فوری وجود ندارد، یک راه حل جایگزین و کاربردی که توسط خود فورتی‌نت ارائه شده است، می‌تواند مشکل را در رابط گرافیکی برطرف کند. این راه‌حل، ایجاد یک “Address Group” است. به این ترتیب که شما به جای استفاده مستقیم از شیء FQDN در پالیسی، یک گروه آدرس جدید ایجاد کرده و شیء FQDN مشکل‌دار خود را به عنوان عضو به این گروه اضافه می‌کنید. سپس در پالیسی، به جای خود FQDN، از این “Group Object” استفاده می‌کنید. تجربه نشان می‌دهد که با این کار، هشدار “Unresolved” در پالیسی از بین می‌رود.

این روش یک راه‌حل موقت است که مشکل نمایشی GUI را دور می‌زند، بدون آن‌که خللی در عملکرد فیلترینگ ایجاد کند. در تصویر زیر، مراحل ایجاد یک Address Group و اضافه کردن FQDN به آن نشان داده شده است.

تصویر ۲ :

پس از ایجاد گروه، کافی است در پالیسی مربوطه، به جای انتخاب مستقیم شیء FQDN، گروه آدرس ایجاد شده را انتخاب کنید. همانطور که در تصویر زیر مشاهده می‌کنید، با این کار هشدار “Unresolved” به طور کامل از کنار آدرس در پالیسی محو خواهد شد.

در اینجا از تصویر ۳ برای نمایش استفاده از Group Object در پالیسی و ناپدید شدن خطا استفاده می‌شود.

معرفی یک سناریوی پیشرفته‌تر: مشکل در Wildcard FQDN

با وجودی که راه‌حل Group Object برای خطای نمایشی FQDN‌های معمولی کارگشاست، اما یک سناریوی پیچیده‌تر زمانی رخ می‌دهد که از Wildcard FQDN (مانند *.example.com) در پالیسی‌ها استفاده کنید. در این حالت، ممکن است نه تنها در GUI با علامت “Unresolved” مواجه شوید، بلکه پالیسی به طور کامل از کار بیفتد و ترافیک مربوطه را مسدود کند. این اتفاق به این دلیل رخ می‌دهد که فایروال برای عملکرد صحیح Wildcard FQDN، نیاز دارد تا پاسخ‌های DNS مربوط به زیردامنه‌های آن را ببیند و در پایگاه داده داخلی خود ثبت کند.

ریشه مشکل Wildcard FQDN و تأثیر DNS امن

مشکل اصلی زمانی تشدید می‌شود که کلاینت‌های شبکه شما از DNS امن (DoH/DoT) استفاده کنند. مرورگرهای مدرن مانند Chrome، Firefox و Edge به طور پیش‌فرض گزینه “Use Secure DNS” را فعال کرده‌اند. هنگامی که این قابلیت فعال باشد، درخواست‌های DNS کلاینت به صورت رمزنگاری‌شده (عمدتاً روی پورت 443) ارسال می‌شوند. از آنجایی که این ترافیک شبیه به سایر ترافیک‌های HTTPS معمولی است، فایروال مگر اینکه بازرسی عمیق بسته (DPI) پیاده‌سازی شده باشد—قادر به مشاهده و استخراج پاسخ‌های DNS نخواهد بود. در نتیجه، Wildcard FQDN هرگز به آدرس IP تبدیل نمی‌شود و پالیسی مربوطه عملاً بی‌اثر می‌ماند.

راه‌حل‌های عملی برای مشکل Wildcard FQDN

برای تضمین عملکرد صحیح Wildcard FQDN، باید اطمینان حاصل کنید که ترافیک DNS ساده (غیررمزنگاری‌شده) از کلاینت‌ها از فایروال عبور کند. راهکارهای اصلی عبارتند از:

غیرفعال کردن DNS امن در کلاینت‌ها: این کار می‌تواند از طریق Group Policy در دامنه، پیکربندی Intune برای دستگاه‌های تحت مدیریت، یا حتی از طریق تنظیمات مستقیم مرورگر انجام شود.

راه‌اندازی یک سرور DNS داخلی: با تنظیم یک سرور DNS خصوصی (مانند FortiGate خود به عنوان DNS resolver) و اجبار کلاینت‌ها به استفاده از آن، می‌توانید مطمئن شوید که تمام درخواست‌های DNS به صورت ساده (روی پورت 53) از فایروال عبور می‌کنند و فایروال می‌تواند پاسخ‌ها را ببیند و Wildcard FQDN را به روز کند.

استفاده از بازرسی عمیق بسته (DPI): با فعال‌سازی SSL Inspection در پالیسی مربوطه و انتخاب گزینه “Inspect DNS over TLS” در پروفایل بازرسی، فایروال قادر خواهد بود ترافیک DNS رمزنگاری‌شده را رمزگشایی و بررسی کند. توجه داشته باشید که این روش مستلزم نصب Certificate فایروال روی تمام کلاینت‌ها است.

عیب‌یابی پیشرفته: استفاده از Packet Capture برای تشخیص قطعی

اگر پس از پیاده‌سازی تمام راه‌حل‌ها، همچنان با مشکل عملکردی در Wildcard FQDN مواجه هستید، آخرین ابزار برای عیب‌یابی قطعی، استفاده از Packet Capture داخلی فایروال است. این ابزار به شما امکان می‌دهد تا ببینید آیا ترافیک DNS ساده (پورت 53) از فایروال عبور می‌کند و آیا پاسخی از سرور DNS دریافت می‌شود یا خیر. با اجرای دستوری مانند diag sniffer packet any ‘host 8.8.8.8 and port 53’ 6 می‌توانید بسته‌های DNS را به صورت Real-Time مانیتور کنید. اگر هیچ پاسخی مشاهده نکنید، به این معنی است که ترافیک DNS در حال گذر از فایروال نیست (احتمالاً به دلیل استفاده از DoH/DoT) یا سرور DNS پاسخی ارسال نمی‌کند.

مشکل مشابه در قوانین SD-WAN

جالب است بدانید که این باگ نمایشی تنها به Policyهای فایروال محدود نمی‌شود. هنگام استفاده از اشیای FQDN در قوانین SD-WAN، همین هشدار “Unresolved” در بخش Network > SD-WAN > SD-WAN Rules نمایان می‌شود، حتی اگر همان شیء FQDN در منوی Addressها به درستی به عنوان “Resolved” نشان داده شود. این نیز یک مشکل کاملاً نمایشی است و تأثیری بر مسیریابی ترافیک ندارد. تأیید نهایی عملکرد صحیح با استفاده از دستور diagnose firewall fqdn list-ip در CLI ممکن است.

برای سازمان‌هایی که نمی‌توانند استفاده از DNS امن را در کلاینت‌ها غیرفعال کنند، یک راهکار جایگزین اما پیچیده‌تر، استفاده از بازرسی عمیق بسته (Deep Packet Inspection) است. با فعال‌سازی SSL Inspection در پالیسی مربوطه و انتخاب گزینه “DNS over TLS” در پروفایل بازرسی SSL، فورتی‌گیت قادر خواهد بود ترافیک رمزنگاری‌شده DoT را رمزگشایی و پاسخ‌های DNS موجود در آن را استخراج کند. توجه داشته باشید که این روش مستلزم نصب Certificate فورتی‌گیت بر روی تمامی کلاینت‌ها است و می‌تواند بار پردازشی بیشتری بر روی دستگاه ایجاد کند.

نکته فنی: فعال‌سازی بازرسی برای DNS over TLS

برای سازمان‌هایی که نمی‌توانند استفاده از DNS امن را در کلاینت‌ها غیرفعال کنند، یک راهکار جایگزین اما پیچیده‌تر، استفاده از بازرسی عمیق بسته (Deep Packet Inspection) است. با فعال‌سازی SSL Inspection در پالیسی مربوطه و انتخاب گزینه “DNS over TLS” در پروفایل بازرسی SSL، فورتی‌گیت قادر خواهد بود ترافیک رمزنگاری‌شده DoT را رمزگشایی و پاسخ‌های DNS موجود در آن را استخراج کند. توجه داشته باشید که این روش مستلزم نصب Certificate فورتی‌گیت بر روی تمامی کلاینت‌ها است و می‌تواند بار پردازشی بیشتری بر روی دستگاه ایجاد کند.

نکته حیاتی: الزامات عملکرد صحیح FQDN در فورتی‌گیت – جمع‌بندی میانی

پیش از ورود به جمع‌بندی نهایی، مرور و درک چند اصل بنیادین در مورد عملکرد اشیای FQDN در فورتی‌گیت ضروری است. این درک به شما کمک می‌کند تا در آینده به سرعت ریشه هر مشکل مشابهی را تشخیص دهید:

مشاهده ترافیک DNS: هسته مرکزی عملکرد FQDN و Wildcard FQDN، توانایی فورتی‌گیت در دیدن پاسخ‌های DNS (رکوردهای A و AAAA) است که از سرور DNS خارج می‌شود. فورتی‌گیت این آدرس‌های IP را در پایگاه داده داخلی خود ذخیره و به روز می‌کند.

ماهیت کش بودن: این نگاشت‌های FQDN به IP دارای TTL (Time to Live) هستند. پس از گذشت TTL، فورتی‌گیت نیاز دارد تا دوباره پاسخ DNS را ببیند تا اطلاعات را تمدید کند.

تأثیر فناوری‌های مدرن: گسترش استفاده از DNS امن (DoH/DoT) بزرگترین چالش برای اصل اول است. اگر ترافیک DNS از فورتی‌گیت عبور کند اما به صورت رمزنگاری‌شده باشد، فورتی‌گیت قادر به دیدن محتوای پاسخ نخواهد بود و در نتیجه شیء FQDN شما “تهی” خواهد ماند.

تفاوت باگ نمایشی و عملکردی: تمایز قائل شدن بین این دو بسیار مهم است. خطای “Unresolved” در GUI یک باگ نمایشی است، اما عدم وجود IP در خروجی دستور diagnose firewall fqdn list-ip یک مشکل عملکردی است که باید با اطمینان از مشاهده ترافیک DNS ساده توسط فورتی‌گیت برطرف شود.

با در نظر گرفتن این اصول، می‌توانید به طور سیستماتیک هر مشکلی مربوط به FQDN را عیب‌یابی کرده و مناسب‌ترین راهکار (بروزرسانی، ایجاد Group، مدیریت DNS یا بازرسی SSL) را انتخاب کنید.

جمع‌بندی نهایی و راهبرد جامع مدیریت

خطای «Unresolved FQDN» در FortiGate را می‌توان به مثابه یک چالش سلسله‌مراتبی در نظر گرفت که از سطح نمایشگر (GUI) تا لایه‌های عمیق‌تر زیرساخت شبکه امتداد می‌یابد. درک این سلسلهمراتب برای تدوین یک راهبرد مدیریتی مؤثر حیاتی است. در سطح اول، این خطا یک «عیب نمایشی» (Cosmetic Bug) شناخته می‌شود که در نسخه‌های خاصی از سیستم‌عامل (نظیر ۷.۲.۶ و ۷.۲.۷) ظاهر گردید و در نسخه‌های پایدارتر (مانند ۷.۲.۸، ۷.۴.۴ و بالاتر) رفع شده است. راه‌حل سریع و عملی برای این سطح، استفاده از «گروه‌های آدرس» (Address Groups) است که اگرچه مشکل نمایشی را می‌پوشاند، اما راه‌حل ریشه‌ای محسوب نمی‌شود.

در سطح دوم، زمانی که از «FQDNهای مبتنی بر وایلدکارت» (Wildcard FQDN) استفاده می‌شود، مسئله از یک عارضه نمایشی فراتر رفته و به یک «چالش عملکردی» (Functional Challenge) تبدیل می‌گردد. عملکرد صحیح این اشیا مستلزم آن است که فایروال بتواند پاسخ‌های DNS مربوط به زیردامنه‌ها را «ببیند» و در پایگاه داده داخلی خود ثبت نماید. در اینجاست که تأثیر مخرب فناوری‌های نوین مانند «DNS امن» (DoH/DoT) آشکار می‌شود، زیرا با رمزنگاری ترافیک DNS، مانع از مشاهده پاسخ‌ها توسط فایروال می‌گردند. راه‌حل‌های این سطح، مستلزم مداخلات زیرساختی از قبیل: غیرفعال‌سازی DNS امن در سمت کلاینت، راه‌اندازی سرور DNS داخلی، پیکربندی فورتی‌گیت به عنوان DNS Resolver، یا اعمال «بازرسی عمیق بسته» (DPI) همراه با نصب Certificate روی کلاینت‌ها می‌باشد.

نمودار راهبرد مدیریت خطای Unresolved FQDN:

خطای “Unresolved FQDN” در GUI

⬇

تشخیص نوع FQDN (معمولی / Wildcard)

⬇

🔹 FQDN معمولی:

• راه‌حل موقت: استفاده از Address Group
• راه‌حل دائم: بروزرسانی سیستم‌عامل

⬇

🔹 Wildcard FQDN:

• بررسی خروجی دستور `diagnose firewall fqdn list-ip`
• در صورت خالی بودن:

1. غیرفعال‌سازی DoH/DoT در کلاینت‌ها
2. راه‌اندازی DNS داخلی/استفاده از فورتی‌گیت به عنوان DNS
3. راه‌حل پیشرفته: فعال‌سازی DPI برای DNS امن

در نهایت، مهم‌ترین نکته، اتخاذ یک «رویکرد پیشگیرانه» (Proactive Approach) است. بهترین راهکار، همیشه به‌روزرسانی مستمر سیستم‌عامل فایروال به آخرین نسخه‌های پایدار است. این کار نه‌تنها باگ‌های نمایشی، بلکه بسیاری از آسیب‌پذیری‌های امنیتی و مشکلات عملکردی را به‌طور ریشه‌ای مرتفع می‌سازد. بعلاوه، طراحی اولیه شبکه و سیاست‌های امنیتی باید با در نظرگیری مفاهیمی نظیر FQDN و الزامات آن (مانند لزوم مشاهده ترافیک DNS ساده) انجام پذیرد.