SSTP הוא PPP מעל HTTPS, לא דף אינטרנט בפורט 443

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

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

שלב 1: TCP ו-TLS

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

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

שלב 2: בקשת HTTPS

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

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

שלב 3: הודעות בקרה

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

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

שלב 4: PPP משתלט

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

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

לאימות יש כמה תפקידים

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

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

מה בדיקה בדפדפן יכולה להראות ומה לא

טעינת דף בכתובת מוכיחה פתרון DNS, נגישות TCP ושהו מקשיב ומדבר HTTP. היא לא מוכיחה שהשיטה מתקבלת, שהחלפת הבקרה שורדת או שאימות PPP מוגדר. השתמשו בלקוח שמיישם SSTP במקום להמיר פרופיל אחר על ידי שינוי הפורט.

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