כבלי רשת כחולים המחוברים זה לזה, המחשה לכללי יישום ב-IPv6
צילום: Scott Rodgerson / Unsplash

Azure Firewall מוסיף כללי Application ל־IPv6 ב־Public Preview

Microsoft הרחיבה את תצורת ה־Dual Stack של Azure Firewall: כללי יישום (Application Rules) עבור תעבורת IPv6 זמינים כעת ב־Public Preview. עד כה, צוותים שהתקדמו ל־IPv6 יכלו להסתמך בעיקר על כללי רשת; התמיכה החדשה מוסיפה סינון שכבה 7 לתעבורת HTTP ו־HTTPS ומאפשרת לשמור על מדיניות דומה בסביבות IPv4 ו־IPv6.

מה מאפשר העדכון

ב־Dual Stack Firewall אפשר להגדיר מרחבי כתובות ותתי־רשתות IPv6, כתובות ציבוריות, נתיבים מותאמים וכללי רשת. עם העדכון, ניתן גם ליצור כללי יישום שמאפשרים או חוסמים תעבורת IPv6 לפי יעדי יישום. Microsoft מציינת גם תמיכה ב־DNS Proxy בסביבות IPv6.

  • סינון HTTP ו־HTTPS ב־IPv6: כללי יישום מאפשרים בקרה מעבר לכתובת ולפורט.
  • מדיניות עקבית: ארגונים יכולים לקרב את מודל האכיפה של IPv6 לזה שכבר קיים אצלם ב־IPv4.
  • Dual Stack: אותו Firewall מטפל ב־IPv4 וב־IPv6; תצורת IPv6 בלבד אינה נתמכת.
  • Public Preview: מדובר ביכולת לבחינה ולא בשירות שהוכרז כ־GA.

היכן נמצאות המגבלות

התמיכה אינה הופכת את כל תכונות Azure Firewall לזמינות ב־IPv6. לפי התיעוד המעודכן, Classic Azure Firewall ו־Firewall ב־Virtual Hub אינם נתמכים בתרחיש הזה. גם DNAT עבור IPv6 עדיין אינו נתמך, וכך גם תרחישים המבוססים על Threat Intelligence,‏ IDPS,‏ Explicit Proxy ו־IP Groups. בנוסף, לא ניתן כרגע להחזיר Firewall ששודרג ל־Dual Stack למצב IPv4 בלבד.

ביציאות מהרשת הווירטואלית, Azure Firewall מחיל SNAT באמצעות כתובת ה־IP של מופע ה־Firewall. עבור יעדים בטווח ULA ‏fc00::/7, לא מוחל SNAT. זו התנהגות מתוכננת שצריך להביא בחשבון בתכנון ניתוב, רישום וחקירת תקלות.

למי זה חשוב

העדכון רלוונטי במיוחד לארגונים המפעילים שירותים ציבוריים או פנימיים ב־Dual Stack, לספקי SaaS שמתחילים לקבל תעבורת לקוחות ב־IPv6, ולצוותי רשת שרוצים להימנע משתי שכבות אכיפה נפרדות. הוא גם מצמצם את הפיתוי “לאפשר זמנית הכול” ב־IPv6 רק מפני שכלי האכיפה לא הגיעו לבשלות של IPv4.

בדיקות מומלצות לפני הטמעה

  1. למפות יישומים שכבר חשופים ל־IPv6 ולוודא שה־FQDN והמדיניות שלהם מוגדרים נכון.
  2. לבחון כללים בסביבת Preview מבודדת ולבדוק לוגים עבור תעבורת Allow ו־Deny.
  3. לאמת מסלולי UDR,‏ DNS ו־SNAT, במיוחד עבור כתובות ULA.
  4. לתעד את המגבלות שאינן נתמכות ולהחזיק בקרות חלופיות ל־DNAT,‏ IDPS ו־Threat Intelligence.
  5. להימנע מהפעלה בייצור קריטי לפני בדיקת התאמה לתנאי Preview ולדרישות התמיכה של הארגון.

מקורות

תמונה: Scott Rodgerson / Unsplash. מקור הקובץ: Unsplash. שימוש לפי Unsplash License, המתיר שימוש מסחרי באתר וברשתות חברתיות. שימוש מערכתי; אין טענה לחסות.

דילוג לתוכן