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

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

פרופיל VPN אינו קיצור דרך או סימנייה. זה אובייקט בעל שם במאגר החיבורים של מערכת ההפעלה, שמחזיק את כתובת השרת, סוג המנהרה, שיטת האימות ולעיתים קרובות את המסלולים, סיומות ה-DNS וכללי ההפעלה שקובעים מתי הוא מתחבר. ב-Windows השדות האלה מתמפים לצמתים של ספק שירות התצורה VPNv2, ולכן פרופיל אחד יכול להגיע דרך Intune, Configuration Manager, חבילת אספקה או קובץ XML שיובא ידנית.

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

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

ארבע ההחלטות שמשתמשים לעולם לא צריכים לקבל

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

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

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

שלחו זהות לכל אדם או לכל מכשיר

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

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

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

התאימו את ערוץ המסירה ללקוח

לקוחות מקוריים ושל צד שלישי נשלחים אחרת. פרופילי Windows יכולים להישלח כ-VPNv2 ProfileXML דרך Intune או Configuration Manager, אבל לא כל צומת חשוף בכל משטח ניהול, והגדרות ניתוב, DNS והפעלה משתנות לפי כלי ולפי גרסת Windows. אשרו איזה שדה ניתן לפרוס לפני שמבטיחים פריסה בלי מגע, כי ההפניה לאפשרויות פרופיל מתעדת הגדרות שנתיבי מסירה מסוימים עדיין לא יכולים לקבוע.

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

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

בדקו את המסירה כמשתמש חדש, ואז בדקו התאוששות

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

שאלו את מאגר הפרופילים של המכשיר כדי שהבדיקה תפיק ראיות ולא רושם.

Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod, SplitTunneling
Get-VpnConnection -Name "Corp VPN" | Format-List
Test-NetConnection intranet.example.com -Port 443

אחר כך עברו על האירועים שמשתמשים פוגשים באמת: איפוס סיסמה כפוי, תעודה מחודשת, עדכון לקוח שנדחף ורשת שאיש בפיילוט לא השתמש בה. כל אחד אמור לעבוד או להיכשל כפי שההוראות מתארות. נסו גם רשת שחוסמת את פורט ה-VPN, כי הניסיון הראשון ב-Wi-Fi של מלון הוא המקום שבו הצלחה בבית מפסיקה לעזור. רשמו את גרסת הלקוח ואת ה-build של מערכת ההפעלה לצד כל תוצאה, כי הדוח הבא יגיע בלעדיהם.

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

מאמרים קשורים