איך לבדוק אם לקוח VPN באמת תומך ב-SSTP

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

התאימו בין המימוש, הגרסה והפלטפורמה

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

ב-Windows סוג המנהרה מגיע מהפלטפורמה ולא מממשק המשתמש, אז שאלו את הפלטפורמה. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress מציג Sstp כאשר הלקוח המקורי ינסה את הפרוטוקול, ומסמך עזר לסוגי חיבור מונה אותו בין סוגי המנהרה המובנים. ב-Linux אין לקוח SSTP מקורי כלל, ולכן השאלה היא אם מימוש נפרד כמו sstpc מחבילת sstp-client מותקן ומעודכן.

קראו את תבנית הפרופיל לפני התווית

פרופילים אינם ניתנים להחלפה, והקובץ שקיבלתם מכריע בדרך כלל את השאלה מהר יותר מכל רשימת תכונות. הוראות OpenVPN, מפתחות WireGuard והגדרות חיבור SSTP מתארים שלושה פרוטוקולים לא קשורים, ואף תיבת ייבוא אינה הופכת אחד לשני. שיתוף פורט TCP 443 אינו מתרגם דבר, כי SSTP, OpenVPN מעל TLS ושירות HTTPS רגיל יכולים לתפוס את אותו פורט ולא לחלוק דבר מעליו.

אם הקובץ הוא .ovpn או תצורת WireGuard, התשובה כבר על השולחן: מהלקוח הזה לא נדרש לדבר SSTP. ייבוא שלו ללקוח שעושה רק SSTP נכשל בשלב הפרופיל, הרבה לפני שמתחיל כל משא ומתן על הפרוטוקול.

מה TLS אינו מוכיח על הפריסה

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

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

עקבו אחרי החיבור בארבעה שלבים

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

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

כשאין תמיכה, החליפו את התוכנית

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

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