הכללה בלבד או החרגה בלבד בפיצול מנהרה: איזו ברירת מחדל?
בחרו את ברירת המחדל לפני שאתם בונים את הרשימה: להעביר במנהרה רק את מה שציינתם, או להעביר הכול ולהוציא חריגים. אחר כך בדקו את היישום שאיש לא רשם.
פתחו את קטע הניתוב בלקוח ה-VPN ותראו שני פקדים בעלי צורה שונה שלעיתים קרובות נושאים אותה תווית. האחד מבקש מכם לרשום את היעדים ששייכים למנהרה, וכל השאר ממשיך להשתמש ברשת המקומית. האחר מניח שהכול עובר במנהרה ושואל מה צריך להוציא החוצה. שניהם נותנים לכם מנהרה שעובדת כבר בבדיקה הראשונה, ושניהם מתוחזקים על ידי הוספת שורות לרשימה, ולכן ההבדל נשאר בלתי נראה עד שמישהו מתקין משהו חדש.
הבחירה היא ברירת מחדל, לא תכונה. הכריעו בה לפני שלרשימה יש עשרים רשומות.
קראו את ברירת המחדל מהלקוח, לא מהעלון
WireGuard הופך את ההחלטה לגלויה באופן בלתי רגיל, משום ש-AllowedIPs הוא רשימת הכללה ותו לא. עמית עם 0.0.0.0/0, ::/0 מעביר הכול במנהרה; עמית עם 10.20.0.0/16 מעביר רק אותו. אין תחביר של החרגה, ולכן אם אתם רוצים להשאיר תת-רשת אחת בחוץ, או שתמנו כל קידומת אחרת או שתוסיפו ניתוב מדיניות מחוץ לממשק.
OpenVPN מגיע לאותו מקום מהכיוון ההפוך, כאשר redirect-gateway def1 מתקין מנהרה מלאה והוראות route מפורשות מוסיפות או דורסות קידומות מסוימות. לקוחות מסחריים בדרך כלל מסתירים את שניהם מאחורי תיבת סימון וטבלת יעדים, ולכן קראו איזו מהן הטבלה באמת עורכת לפני שתסמכו על התווית.
השאלה שצריך לשאול אינה איך נקראת תיבת הסימון. השאלה היא מה קורה לחבילה שהיעד שלה אינו מופיע באף אחת מן הרשימות. ענו על כך בכתב ושאר התצורה נגזרת מזה. דלגו על השאלה והכשל הראשון שאין לו הסבר יוכרע בידי מי שיהיה הקרוב ביותר ללקוח באותו יום.
עקבו אחר יישום שאיש לא רשם
בעיצוב של הכללה בלבד היישום הזה הולך ישירות, ברשת המקומית, עם ה-DNS המקומי. בעיצוב של החרגה בלבד הוא עובר דרך המנהרה, בכפוף למה שהשרת מתיר, ולעיתים קרובות זה ההבדל בין כלי SaaS חדש שעובד מהיום הראשון לבין פנייה שאומרת שה-VPN שבר אותו.
אף אחת משתי ברירות המחדל אינה מאובטחת יותר כשלעצמה. הכללה בלבד מצמצמת את מה שהמנהרה נושאת והופכת את הרשת המקומית לדרך של התנגדות קטנה ביותר; החרגה בלבד מניחה שהמנהרה היא הדרך הרגילה ומתייחסת לחריגים כחריגים, וזה קרוב יותר למה שרוב המדיניות הארגוניות באמת מתכוונות אליו.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
שימו לב איזה סוג של אובייקט הפלטפורמה רושמת
VpnService.Builder באנדרואיד חושף רשימת יישומים מורשים ורשימת יישומים אסורים כשתי מודלים נפרדים, וכללי כל יישום בוחרים לפי חבילה ולא לפי יעד. דפדפן שמוצב ברשימה כזו נושא כל יעד שהוא פותח, וזו רזולוציה שונה מטבלת ניתוב והיא אינה יכולה לתקן אתר אחד שבור בתוך יישום שעובד.
לקוחות שולחניים בדרך כלל מערבבים את שני הסוגים בממשק אחד, ולכן בדקו אם השורה שאתם מוסיפים היא חבילה, שם מארח או קידומת. הם נכשלים בדרכים שונות ונפתרים במקומות שונים. שורת שם מארח הופכת בדרך כלל לניתוב בתוספת שם, ואילו שורת חבילה הופכת להחלטת מדיניות בתוך הלקוח. רשמו איזו מהן הוספתם, משום מי שינפה זאת אחר כך יניח את האחרת.
בדקו את מצב הכשל, לא רק את המסלול התקין
יישום שמוחרג מהמנהרה אינו מקבל אוטומטית גישה ישירה נקייה. אם הלקוח אוכף גם כלל חסימה ללא VPN, ייתכן שהתעבורה המוחרגת תושלך לגמרי, מה שנראה כמו יישום שבור ולא כמו החלטת ניתוב. בדקו את המקרה הזה במכוון במקום לגלות אותו מדיווח משתמש.
לאחר מכן בדקו DNS ו-IPv6 כפריטים נפרדים. מנהרה שנושאת רק IPv4 מותירה ליישום בעל תמיכת v6 מסלול עוקף, ו-DNS מפוצל קובע אם שמות פנימיים נפתרים עבור תעבורה שאינה עוברת במנהרה כלל. הריצו יישום ברשימה, יישום שאינו ברשימה, שאילתת שם והתחברות מחדש אחת, ושמרו את התוצאות עם התצורה.
רשמו את ברירת המחדל במקום שבו האדם הבא ימצא אותה
תעדו את ברירת המחדל שנבחרה, את החריגים ואת מי שאחראי להם באותו מקום שבו פרופיל הלקוח נמצא, משום שהמנהל הבא יוסיף רשומה בלי לקרוא את הנימוק הזה. ציינו את התאריך ואת הסיבה לכל חריג, כדי שאפשר יהיה להסיר בביטחון החרגה ישנה לאתר שכבר תוקן. רשימה בלי נימוקים גדלה לנצח.
כשמישהו מדווח על יעד אחד שבור, שנו את החריג ולא את קו הבסיס. הפיכת ברירת המחדל כדי לתקן אתר בודד מעבירה בשקט כל יישום שאינו ברשימה לצד האחר של המנהרה.