כתובות מנהרה סטטיות ב-pfSense: העדפה או הזמנה?

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

מה באמת מבטיחה כתובת עקיפה

עקיפה ספציפית ללקוח נושאת אפשרויות לכל לקוח, ובהן כתובת מנהרה מועדפת. Netgate מתארת את הכתובת כהעדפה ולא כהזמנה, כלומר המאגר הדינמי אינו מוותר על הכתובת עבור מישהו אחר.

בדרך כלל זה בסדר. התנגשות נדירה, והלקוח מקבל בדרך כלל את מה שביקש, וזה מספיק לנוחות ולא מספיק להרשאה. נוחות והרשאה הן דרישות שונות, ורק אחת מהן שורדת התנגשות.

בטופולוגיית תת-רשת, השדה מקבל את כתובת הלקוח יחד עם מסכת רשת השרת, ולכן כתובת בתוך מנהרת 10.90.0.0/24 נכתבת כ-10.90.0.10/24.

שום דבר מזה לא שומר את המספר. לקוח שהעקיפה שלו לא מתאימה, או הפעלה כפולה, יכול להגיע למקום אחר במאגר, וכלל שמבוסס על הכתובת מתאר אז מישהו שאינו שם.

סגרו את המסלול הדינמי עם ברירת מחדל מוגבלת

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

יישום זה אומר עקיפת DEFAULT מוגבלת לאותו שרת אחד עם חסימת חיבורים מופעלת. לקוח בלי עקיפה מתאימה לא יכול אז לחזור לקבלה הדינמית הרגילה. אותה שורה אחת היא מה שהופך העדפה לקבוצה סגורה.

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

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

התאימו לזהות שהשרת באמת משתמש בה

עקיפה מתאימה למשהו. בשרת שמתאים שמות נפוצים של תעודות, שם העקיפה חייב להיות אותו שם נפוץ, לא שם התצוגה של האדם. העתיקו אותו מהתעודה ולא מרשימת החשבונות.

שרת שמוגדר להשתמש בשם המשתמש כשם נפוץ מתאים במפתח אחר לגמרי, ועקיפה שנקראת על שם התעודה לעולם לא תופעל. קראו את ההגדרה במקום להסיק אותה ממה שרשימת החשבונות מציגה.

שמרו על גורמי האימות הנוספים שהפריסה דורשת. מודל כתובות סגור משנה מי יכול להתחבר ואיזו כתובת הוא מקבל; הוא לא מחליף את בדיקת התעודה או את הגורם השני.

כתבו את כללי הגישה אחרי שהמפה תקינה

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

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

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

בדקו את המקרים השליליים

נסו ארבעה חיבורים חדשים: נקודת קצה בשם, אחת בלי שום עקיפה, שירות שאמור להיות נגיש ואחד שלא. נקודת הקצה שאינה ברשימה היא המקרה החשוב, כי היא זו שהעיצוב קיים כדי לעצור. אם היא מתחברת, חסימת ברירת המחדל לא עושה את עבודתה.

בדקו IPv6 בנפרד, כי מדיניות כתובות IPv4 לא אומרת דבר על מחסנית שנייה. אחר כך אשרו שהיישום עדיין מאשר את המשתמש, כי כתובת מנהרה היא עובדת רשת ולא הוכחה למי שנמצא במקלדת. שתי הבדיקות שייכות להערת הקבלה.

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