ה-VPN המובנה של Windows אינו מגיע לשער SSL של ספק: מדוע

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

ארבעה סוגים ודיאלוג אחד

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

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

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

אם הפרופיל אומר SSTP והשער אינו שרת RRAS, אי-ההתאמה כבר הוכחה. שום עבודה על תעודות או חומת אש לא תשנה אותה.

SSTP ו-TLS של ספק נראים זהים בפורט 443

SSTP עוטף הפעלת PPP בתוך TLS ונע על TCP 443. במערך של Microsoft מסיים אותה RRAS, שמציג תעודת שרת שהלקוח מאמת. התקן Fortinet, Citrix או Pulse גם מסיים TLS בפורט 443, והפורטל שלו נפתח בכל דפדפן בלי תלונה.

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

גם הבלבול ההפוך קורה. פרופיל שהוגדר כ-SSTP מול שרת RRAS אמיתי יכול להיכשל באימות התעודה בזמן שהפורטל תקין, וזו בעיית תעודה ולא בעיית פרוטוקול.

שגיאות שמופיעות לפני שקיימת מנהרה

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

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

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

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

פרופיל מחובר עדיין יכול לשבור הכול

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

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

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

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

אמתו את האינסטלציה, ואז את הסוג

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

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

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

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