פורט בשדה הכתובת של VPN ב-Windows עובד רק עם SSTP

השדה שם שרת אינו host:port. ל-PPTP, ל-L2TP ול-IKEv2 יש פורטים קבועים; SSTP מקבל פורט רק ככתובת https:// מלאה, והעברת 443 נקייה יותר.

שרת VPN עונה על TCP 10443, ללקוח המובנה של Windows יש את פרטי הכניסה הנכונים, והחיבור בכל זאת נופל אחרי הפוגה שנראית כמו פסק זמן של DNS. הסיבה היא בדרך כלל שדה הכתובת: הקלדת vpn.example.com:10443 בשדה שם שרת או כתובת גורמת ל-Windows לקרוא את כל המחרוזת כשם מארח, כי התיבה הזו אינה קלט host:port כללי. אם אפשר בכלל לבטא שם פורט תלוי בסוג המנהרה שהפרופיל משתמש בו, ורק אחד מארבעת הסוגים מתייחס לערך כאל משהו שהוא יודע לנתח.

מדוע שדה הכתובת אינו תיבת host:port

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

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

שלושת הסוגים עם פורט קבוע

PPTP מתחבר ל-TCP 1723 ואז נושא את המנהרה ב-GRE, פרוטוקול IP 47. L2TP/IPsec משתמש ב-UDP 1701 למנהרה וב-UDP 500 ו-4500 ל-IPsec, כאשר 4500 הוא פורט המעבר ב-NAT. IKEv2 משתמש גם הוא ב-UDP 500 ו-4500. אף אחד מהפרופילים האלה לא מציג שדה פורט בשום מקום בממשק, ואף אחד לא ינהל משא ומתן על פורט לא תקני.

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

SSTP צריך כתובת, לא שם

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

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

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

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

תחביר יצרן שמודבק לאותה תיבה

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

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

הוכיחו את הפורט, ואז קראו את השלב שנכשל

לפני שאתם מאשימים את הפרופיל, ודאו שמשהו מקבל TCP בפורט הזה מרשת הלקוח:

Test-NetConnection vpn.example.com -Port 10443

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

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

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