VPN ב-Windows מדווח שההתקן חסר: תקנו לפי הסדר

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

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

התחילו בשירותים, לא בפרטי ההתחברות

שלושה שירותים עומדים מאחורי חיבור Windows מקורי: Telephony, Remote Access Connection Manager ו-Remote Access Auto Connection Manager. שלושתם חייבים לפעול עבור פרופיל חיוג יוצא, וכל אחד מהם יכול להישאר מושבת על ידי סקריפט ניקוי קודם או תמונת מערכת מוקשחת. הגדירו את אלה שבשימוש ל-Manual או Automatic במקום להשאירם ב-Disabled, והפעילו אותם לפני נגיעה בכל דבר אחר. Routing and Remote Access הוא רכיב אחר שמארח חיבורים נכנסים, ולכן הפעלתו אינה תנאי מוקדם לחיוג יוצא.

Get-Service -Name TapiSrv,RasMan,RasAuto | Format-Table Name,Status,StartType
Get-WinEvent -LogName System -MaxEvents 30 | Where-Object { $_.ProviderName -match 'Ras|RemoteAccess' }

שירות שמתחיל וחוזר מיד ל-Stopped הוא תקלה שונה מזו שהושבתה סתם כך. רשומת האירוע המתאימה מציינת את הרכיב שסירב להמשיך.

לאחר מכן בדקו את המיניפורטים שמאחורי הפרופיל

התקנה עובדת מפרטת התקני WAN Miniport עבור הפרוטוקולים שבהם היא יכולה להשתמש, כולל PPTP, L2TP, IKEv2 ו-PPPoE. אם הרשומות האלה חסרות או מושבתות, אין ל-Windows למה לקשור את החיבור, והפרופיל ממשיך לדווח על התקן חסר. פתחו את Device Manager עם התקנים מוסתרים גלויים והרחיבו את Network adapters כדי לראות את המלאי האמיתי ולא את המסונן. הפעלת מנהל החיבורים מרשימה לעיתים קרובות את ההתקנים האלה מחדש, ולכן תקלת שירות יכולה לחקות חומרה חסרה.

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

כאשר SSTP מתחיל ונעצר בתוך שניות

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

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

בנו רשומה אחת מחדש ובדקו אותה לבדה

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

rasdial "Office VPN"
rasdial "Office VPN" /disconnect
Get-PnpDevice -Class Net | Where-Object FriendlyName -like '*WAN Miniport*'

חיבור שנוצר ואז לא נושא דבר כבר עבר את התיקון הזה. במארח Hyper-V, הפעלת NetBIOS over TCP/IP במתאם הווירטואלי היא החלק החסר בכמה מקרי SSTP מתועדים, ובדיקתה לא עולה דבר. סיסמה שפגה מתוקנת בעת חיבור, מכיוון שהספרייה לומדת את הערך החדש רק לאחר התחברות מוצלחת. רשמו איזה שלב נכשל לפני שתמשיכו, מכיוון שבנייה מחדש של נתיב התקן בתגובה לשגיאת אימות מייצרת רק טרחה ולא התקדמות.

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