חסימת IPsec בלי לשבור את ה-Wi-Fi Calling של הטלפון

הבקשה תמיד מגיעה באותה צורה: סגרו את IPsec בקצה כי הוא נושא מנהרות שאיש לא אישר, והתלונה הראשונה מגיעה ממי שהטלפון שלו הפסיק לבצע שיחות דרך Wi-Fi. שתי העובדות נכונות בעת ובעונה אחת, ואף אחת מהן אינה מצדיקה לזנוח את הבקרה. מה שצריך הוא חריגת שירות עם תכונה בשם, מקור מוגבל, יעדים מתועדים ובעלים. חמישה שלבים הופכים את זה לכלל שזר יוכל לסקור בשנה הבאה.

תנו שם לשירות לפני שאתם נותנים שם לפרוטוקול

טלפון שולחני על שירות SIP ומכשיר שמבצע Wi-Fi Calling של המפעיל אינם חולקים פרופיל רשת, ו-VoIP כמונח של חומת אש אינו מתאר אף אחד מהם. נתוני פורט ויעד חייבים לבוא מהספק או מהמפעיל שמפעיל את השירות, ולא מרשימת פורטים זכורה של מערכת טלפון אחרת. זה ההבדל בין כלל שמגן על תכונה לבין כלל שמגן על מילה.

ה עיון בפורטי שירות של Apple מפרט UDP 500 ו-4500 עבור Wi-Fi Calling, שהם בדיוק הזוג שרוב חסימות ה-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

כללו בבדיקה חיבור מחדש או שינוי רשת, וחזרו עליה מהתחלה קרה שבה הטלפון מצטרף לרשת ולא כבר מחובר. אם המונה זז והשיחות עדיין נכשלות, הבעיה יצאה מחומת האש ושייכת לרשימת היעדים של המפעיל.