שתי קבוצות לקוחות, שרת אחד: היכן לאכוף את המדיניות
תת-רשתות מתייגות קבוצות; הן אינן מבודדות אותן. החליטו איזה נתיב העברה מחזיק בכלל, ואז כתבו את המטריצה שהמימוש חייב לאכוף.
הצבת שתי קבוצות לקוחות בתת-רשתות שונות נראית כמו בידוד, והיא אינה. כתובות מתארות מאין נראה שהחבילה מגיעה, ואילו הרשאה היא החלטה שמקבל מי שמעביר אותה. על השאלה הזו עונה התצורה ולא המסכה, לכן החליטו איזה רכיב מעביר תעבורת עמיתים לפני שתכתבו כלל כלשהו.
תת-רשת היא תגית, לא כלל
הקצאת מאגר אחד לכל קבוצה נותנת כתובות קריאות ושום דבר אחר. לקוח שמקבל מסלול נוסף הרוויח נגישות, ונגישות אינה הרשאה. ההרשאה לדבר נמצאת בהחלטת ההעברה, שעשויה לשכון בדמון או בליבה בהתאם לאופן שבו השרת מוגדר.
הבעלות על הכתובת היא מה שהופך קידומת לשמישה כבורר קבוצה. כל זהות מאומתת חייבת להתמפות לכתובת או לטווח צפויים, והמיפוי הזה נכשל ברגע שמספר מכשירים חולקים אישור אחד והקצאה אחת. פתרו זהות וקונקרנציה לפני שתיסמכו על קידומת מקור, כי מדיניות שמנחשת איזה מחשב מתקשר מאשרת את הלא נכון ברגע הגרוע ביותר.
בחרו בנתיב שנושא את תעבורת העמיתים
כאשר הדמון מעביר חבילות עמיתים בתוך התהליך שלו, החבילות האלה לעולם אינן מגיעות לווי ההעברה של המארח, כך שכלל ליבה אינו יכול לראותן. בטלו את ההעברה הפנימית הזו והליבה הופכת לנקודת ההעברה, שבה חלים כללי העברה רגילים.
# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chainערוצי נתונים מפונים ושרתים המנוהלים על ידי המוצר מפרסמים מודלי אכיפה משלהם, לכן ודאו איזה מהם אתם מריצים במקום להניח את התנהגות הקהילה. הכשל שכדאי להימנע ממנו הוא כלל שנראה נכון בסקירה ולעולם אינו נשאל בזמן ריצה.
כתבו את המטריצה לפני כתיבת כללים
מטריצה קצרה קלה יותר לסקירה מאשר סט כללים, והיא החוזה שהמימוש חייב לקיים: עמיתים באותה קבוצה מותרים, עמיתים בין קבוצות אסורים, שתי הקבוצות מותרות אל שירות משותף אחד בעל שם, וכל השאר אסור. כתבו את ארבע השורות האלה לפני שתפתחו עורך חומת אש. סוקר שאינו קורא תחביר כללים עדיין יכול לבדוק את המטריצה. אז המימוש רק צריך להתאים לשורות.
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
הפרידו בין שלוש מחלקות היעד בזמן הכתיבה. שירות על מארח ה-VPN הוא קלט מקומי, לקוח אחר הוא מעבר עמיתים, ומכונה מאחורי השער היא נתיב העברה אחר. כלל נדיב אחד יכול להעניק את כל השלושה בטעות, וכך מדיניות קבוצה הופכת לרשת שטוחה עם צעדים נוספים. כתבו את המחלקה לצד כל שורה כדי שהכוונה תשרוד את העריכה הבאה.
הניחו את הכללים במקום שבו הם שורדים
הוסיפו את ההחלטות באותו מקום שבו מתחזקים את שאר חומת האש, לפני כל כלל מתיר שאחרת יבלע אותן. סדר הכללים הוא חלק מהמדיניות, וכלל נכון המוצב אחרי אישור רחב אינו אוכף דבר. רשמו את מספרי הכללים לפני ואחרי השינוי. מדיניות שקיימת בעורך אך לא בסט הכללים הפעיל היא תוכנית, לא בקרה.
החליטו מה קורה לזרימות שכבר קיימות כשהמדיניות משתנה, כי הפעלה שנפתחה לפני השינוי עשויה להמשיך אחריו. אם חבר שעזב צריך לאבד גישה מיד, סט הכללים זקוק לדרך לסיים את המצב הזה במקום להמתין שהחיבור ייסגר מעצמו.
הפכו את הכללים לקבועים באמצעות המנגנון שמחזיק בשאר חומת האש, ותעדו את המטריצה לצידם. מדיניות שלא תועדה נגזרת מחדש מהזיכרון באירוע הבא, בדרך כלל בידי מישהו ממהר.
הוכיחו זאת משני הצדדים
בדקו נגישות בתוך אותה קבוצה, כשל בין קבוצות ואת השירות המשותף מלקוח אחד בכל קבוצה. בדיקה אחת מלקוח אחד מוכיחה חצי מהמטריצה, והחצי שהיא משאירה בחוץ הוא בדרך כלל השגוי. חזרו על כיוון האיסור פעמיים, כי הפעלה שמורה במטמון יכולה להסתיר טעות אכיפה. תעדו איזה זוג בדקתם כדי שהאדם הבא לא יחזור עליו.
חזרו על הבדיקה ב-IPv6 אם המנהרה נושאת אותו, והשאירו אימות יישומים רגיל במקומו. קידומת מקור אינה חשבון, לכן מעבר מדיניות הרשת אינו אומר ששירות צריך לבטוח בקורא.