חריג VPN לרשת הביתית באנדרואיד: נהל עבודה לשירות אחד
החריגו רק את שירות הבית שאישרתם, לא כל נתיב פרטי. כתבו את המדיניות, השתמשו ב-VPN שניתן לעקוף, ואז בדקו את כשל רשת האורחים.
אתם רוצים ששירות ביתי אחד יהיה נגיש בזמן שה-VPN נשאר בתוקף לכל השאר. ההגדרה המפתה היא חריג לנתיב מקומי שמכסה כל כתובת פרטית, וזהו הבקרה השגויה: ברשת המלון או הקפה הבאה היא יכולה להפוך כל דבר שמגיב לעקיפה. נהל העבודה הזה מגביל את החריג לשירות אחד ומוכיח אותו תחת המעברים ששוברים אותו.
הגדירו את החריג כשירות, לא כתת-רשת
רשמו את היישום, את שם המארח והכתובת של היעד, את הפרוטוקול והפורט, את הרשת שבה הדבר מותר, ואת בדיקת הזהות שהשירות עצמו מבצע. ב-NAS עם אימות, התעודה או החשבון הם שמוכיחים שהגעתם למכונה הנכונה. כתובת ב-192.168.0.0/16 לא מוכיחה דבר, כי כל נתב ביתי מחלק את אותם קידומות.
החליטו גם מה פירושו קרוב. שירות ב-VLAN מנותב אינו בתת-הרשת שמחוברת ישירות לטלפון, ו-Wi-Fi לאורחים יכול לחלוק את אותה קידומת פרטית כמו הבית ובכל זאת להיות מכונה אחרת לגמרי. החריג צריך לנקוב בשם השירות ובסביבה, לא רק בטווח הכתובות.
ודאו שבקרת הפלטפורמה מתאימה לדרישה
בונה פרופילי IKEv2 של אנדרואיד חושף setLocalRoutesExcluded(true), והתיעוד שלו דורש VPN שניתן לעקוף: החריג משמעותי רק כאשר הלקוח מאפשר לתעבורה לעקוף את המנהרה. אותו תיעוד מזהיר שהרשת הבסיסית עשויה לספק נתיבים שמשפיעים על החריג, ולכן ההגדרה עוקבת אחרי הרשת שאליה אתם מתחברים ולא אחרי זו שאתם סומכים עליה.
זה גם אינו הבטחה שכל נעילה או תצורה מנוהלת תאפשר למשתמש להפעיל את אותו חריג. חריג נתיב, דגל העקיפה ומדיניות חסימת ההתקן הם בקרות נפרדות, והתקן מנוהל עשוי לאסור את השלישי בעודו מתיר את השניים הראשונים. בדקו את הפרופיל המותקן ואת מדיניות הניהול לפני שתעצבו סביב תיבת סימון.
נהל עבודה: בנו והחילו את החריג
שלב 1: צרו את הפרופיל בנתיב הנתמך לפריסה, בין אם התצורה המנוהלת ובין אם בונה הלקוח. שלב 2: סמנו את ה-VPN כניתן לעקיפה, כי חריג הנתיב המקומי אינו אפקטיבי בלעדיו. שלב 3: הפעילו את חריג הנתיב המקומי. שלב 4: השאירו את האימות של השירות עצמו ואת אימות התעודה פעילים; החריג עוסק בניתוב, לא באמון. שלב 5: שמרו והתחברו מחדש כדי שהפרופיל יוחל.
החזרה לאחור היא אותו נתיב בסדר הפוך: נקו את החריג, אחר כך נקו את העקיפה, ואז התחברו מחדש. אל תטליאו נתיב או וו חומת אש ישירות על ההתקן. דמון הרשת הוא הבעלים של הכללים האלה, וכלל ידני עלול להחמיץ משפחת כתובות אחרת, התחברות מחדש או מעבר רשת. אם התצורה המותקנת אינה יכולה לבטא את המדיניות, שמרו על החסימה המחמירה עד שהבעלים יאשר עיצוב אחר.
בדקו את ארבעת המקרים החשובים
השתמשו בבקשות בלתי מזיקות ורשמו את התוצאה הצפויה לפני הרצת כל מקרה. המטריצה שלמטה היא מבחן הקבלה, לא הצעה: אם מקרה חסום כלשהו מצליח, החריג רחב מן המדיניות.
| Case | Network | Destination | Expected |
|---|---|---|---|
| 1. Approved service | Home Wi-Fi | The NAS | Reachable and authenticated |
| 2. Other local device | Home Wi-Fi | A printer | Denied by VPN policy |
| 3. Same private prefix | Hotel or cafe Wi-Fi | 192.168.1.10 | Denied |
| 4. Transition | VPN drop, Wi-Fi to cellular | The NAS | No silent direct path |
מקרה 3 הוא זה שתופס עקיפה רחבה של תת-רשת פרטית, ומקרה 4 תופס לקוח שהחיל את החריג רק בזמן ההתחברות. הריצו את מקרה 4 כשהאחיזה ב-VPN מנותקת והטלפון הועבר לרשת סלולרית, ואז התחברו מחדש וודאו שהחריג חוזר בלי אתחול. תיעוד ה-API של הנתיב המקומי מפרט את דרישת העקיפה שהופכת את שלב 2 לחובה.
תעדו את החריג וסקרו אותו
הרשומה המתוחזקת צריכה לנקוב בשם השירות, בסביבה שהצדיקה אותו, בבעלים ובתאריך. מקומי מתאר יחס ניתוב, לא רמת אמון, והרשת הבאה שהטלפון יצטרף אליה אינה הרשת שבה אושר החריג.
סקרו את הרשומה לאחר עדכון מערכת, עדכון לקוח או מעבר דירה. הריצו שוב את מקרה 3 בכל חידוש של החריג, כי פרופיל שצמצם פעם את העקיפה לשירות אחד יכול להתרחב בשינוי ברירת מחדל אחד.