Azure VPN Client: פלטפורמת ה-VPN לא הפעילה את החיבור
ייבוא מחדש, תיקון ואיפוס עולים שלושה דברים שונים. טפלו בכשל ההעברה לפי סדר עלות, ואז הפרידו בין בעיית מאגר לבעיית שער.
שורת המצב אומרת שפלטפורמת ה-VPN לא הפעילה את החיבור, הפרופיל מיובא בלי תלונה, והשער בריא לכל השאר. ההודעה הזאת מתארת העברה בתוך Windows, ולא אישור שנדחה, ולכן הסדר השימושי עובר מהשינוי הזול ביותר במצב אל ההרסני ביותר. ייבוא פרופיל מחדש עולה דקה, תיקון החבילה עולה הפעלה מחדש, ואיפוס עולה את כל הפרופילים במחשב. עבודה בסדר שגוי הורסת את הראיות שדרושות כדי להבדיל בין המקרים.
ייבוא מחדש, תיקון, איפוס: שלוש עלויות שונות
שלוש הפעולות אינן חלופיות, ורק אחת מהן הפיכה בלי עבודה. ייבוא מחדש מרענן את הפרופיל ושומר על התקנת האפליקציה. תיקון שומר על הפרופילים המיובאים וכותב מחדש את קובצי החבילה. איפוס מסיר את הפרופילים יחד עם מצב האפליקציה, ולכן אחר כך תייבאו הכול מחדש.
| Action | Keeps | Removes |
|---|---|---|
| Re-import profile | App, other profiles | The stale profile entry |
| Repair package | Imported profiles | Damaged app files |
| Reset app | Nothing local | All profiles and app state |
התחילו בהורדה חדשה של azurevpnconfig.xml בכל פעם שהשער, מאגר הכתובות או שיטת האימות השתנו. פרופיל שמציין שער שנמחק מפיק בדיוק את שורת המצב הזאת, ואין תיקון בצד הלקוח שיתקן קובץ שמצביע למשהו שכבר לא קיים.
לפני כל צעד הרסני, ודאו שהאפליקציה מורשית לפעול ברקע: הגדרות, אפליקציות, אפליקציות מותקנות, Azure VPN Client, אפשרויות מתקדמות. לקוח מושהה לא יכול להשלים את העברת הפלטפורמה.
RasMan הוא השירות שאליו הלקוח מעביר
Remote Access Connection Manager הוא מה שהופך בקשת לקוח לחיבור Windows. הפעילו אותו מחדש מחלון עם הרשאות מוגברות באמצעות net stop rasman ואחריו net start rasman, ואז התחברו שוב לפני שתשנו משהו אחר.
אם זה משחזר את החיבור, קבעו את סוג האתחול כך שהתיקון ישרוד הפעלה מחדש: sc.exe config rasman start= delayed-auto. שירות שפועל עכשיו אך מושבת בעלייה ישחזר את אותה תקלה מחר בבוקר.
שימו לב לשירות שמתחיל ואז נעצר מעצמו. הדפוס הזה מצביע על תלות או על מדיניות, והפעלה מחדש שלו תעבוד דקות בכל פעם, וזה גרוע מכשל נקי מפני שזה נראה כמו בעיית רשת לסירוגין. בדקו ביומן System את שם השירות סביב זמן הניסיון, וודאו שגם התלויות פועלות.
משתמש נוכחי או מחשב מקומי: שני מאגרי אישורים
אם הלקוח נפתח עם רשימת אישורים ריקה, הפרופיל אינו האשם וגם לא השירות. הלקוח קורא את המאגר האישי של המשתמש הנוכחי: פתחו certmgr.msc, הרחיבו Certificates, Current User, Personal, Certificates, וודאו שהאישור שם עם מפתח פרטי.
מאגר המחשב המקומי שנפתח עם certlm.msc הוא מאגר אחר, והתקנה שם לא מספקת לקוח שמחפש במאגר המשתמש. באימות אישורים השער מחזיק רק את המפתח הציבורי של השורש, וכל מכשיר צריך אישור משלו שהונפק מאותו שורש. אישור שהועתק ממכונה אחרת מגיע בדרך כלל בלי המפתח הפרטי שלו, וזה יוצר רשומה שאפשר לבחור אך לא ניתן להזדהות בה.
בורר ריק הוא בעיית מאגר, לא בעיית מנהרה.
אימות אישורים או Azure AD: צורות כשל שונות
לאימות Azure AD תצורת נקודה לאתר צריכה את כתובת ה-URL של הדייר, את מזהה האפליקציה של Azure VPN Client כקהל, ואת מנפיק ה-STS, כאשר מנהל מעניק הסכמה לאפליקציית Azure VPN. שמרו את התצורה, הורידו את החבילה שוב, וייבאו את הקובץ החדש במקום לעשות שימוש חוזר בעותק ישן.
ודאו גם שמאגר כתובות הלקוח לא חופף לרשת הווירטואלית או לטווח מקומי, ושקבוצת האבטחה של הרשת במכונת היעד מתירה את המאגר. שתי הטעויות האלה שורדות כל תיקון בצד הלקוח.
צד המחשב הנייד או צד השער
אל תשפטו את המנהרה לפי בדיקת כתובת ציבורית. חיבור נקודה לאתר לא שולח את כל תעבורת האינטרנט ל-Azure, ולכן כתובת ציבורית שלא השתנתה היא הצפויה כשהמנהרה עובדת כראוי. בדקו במקום זאת כתובת פרטית בתוך הרשת הווירטואלית וקראו את המסלולים האפקטיביים במכונה.
רשמו איזה צעד שחזר את החיבור, את גרסת הלקוח, את תאריך הורדת הפרופיל, ואם אישור או ספק הזהות סיפק את האישור. הרשומה הזאת הופכת את המקרה הבא לבדיקה של שתי דקות, והיא מראה אם הכשלים נודדים לעבר השער במקום להישאר במחשב הנייד.
סדר העבודה: ייבאו מחדש פרופיל עדכני, הפעילו מחדש את RasMan, אפשרו הרצה ברקע, תקנו את החבילה, ואפסו רק אם מאגר האישורים אומת כשלם.