‏Always On VPN אינו גישה ל-LAN: רשימת בדיקה למשאבים

‏Always On הוא מחזור חיים של חיבור: הפרופיל מתחבר בזמן הכניסה או לפניה ומתחבר מחדש בלי שהמשתמש ילחץ דבר. זה אינו אומר שכל יעד פרטי, פרוטוקול ומשתמש מורשים. השאלה המעשית היא אילו משאבים הפרופיל שנפרס מספק בפועל, והתשובה דורשת בדיקה לכל משאב, לא מבט בתג Connected.

שלב 1: רשמו את המשאב לפני הבדיקה

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

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

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

שלב 2: קבעו איזו מנהרה צריכה לשאת אותו

‏Windows Always On VPN כולל מנהרת מכשיר ומנהרת משתמש, המוגדרות כפרופילים נפרדים עם תעודות ותחומים נפרדים. מנהרת המכשיר נושאת בדרך כלל רק את התשתית הנדרשת לפני הכניסה, כמו ניהול ושירותי תחום; גישה רחבה של העובדים ליישומים שייכת למנהרת המשתמש.

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

שלב 3: אמתו את המסלול לכתובת האמיתית

פתרו את השם פעם אחת ואז בדקו את המסלול: Find-NetRoute -RemoteIPAddress 10.20.5.10 מדווח על הממשק שנבחר, הקפיצה הבאה וכתובת המקור. אם הממשק הוא המתאם הפיזי, הקידומת חסרה בסט המסלולים של המנהרה או שהלקוח הסיר אותה באמצעות מנהרה מפוצלת. השוו להגדרת הפרופיל במקום להוסיף מסלול מקומי.

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

שלב 4: בדקו פתרון שמות פרטיים בנפרד

לשמות פרטיים יש נתיב מדיניות משלהם. הפרופיל יכול לספק כללי NRPT ורשימת חיפוש סיומות DNS, שתקפים כל עוד המנהרה פעילה. קראו עם Get-DnsClientNrptPolicy מה הלקוח קיבל בפועל, ואז בדקו שם וכתובת באותה הפעלה. שמות שנכשלים כשכתובות עובדות מצביעים על הפותר; שניהם נכשלים מצביעים על המסלול.

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

שלב 5: בדקו מסננים, זהות והשער של היישום עצמו

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

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