SSTP נכשל היכן ש-HTTPS בדפדפן מצליח: מדוע
SSTP פועל בתוך TLS בפורט 443, אך אינו בקשת אינטרנט. בדקו TCP, זהות TLS, חילופי SSTP ואימות PPP כשלבים נפרדים.
הדפדפן פותח את שם המארח של ה-VPN דרך HTTPS בלי תלונה, ולקוח SSTP עדיין מסרב להתחבר. אין שום דבר סותר בצמד הזה. SSTP משתמש ב-TLS כתובלה חיצונית ואז מריץ את הבקשה שלו ואת מטען ה-PPP בתוך אותו חיבור, כך שטעינת דף מוצלחת מוכיחה רק דבר צר אחד: המארח עונה ל-GET בפורט 443. הלקוח שואל שאלה אחרת, והשרת עשוי לענות עליה רע.
הדף נטען והמנהרה לא
אנשים פונים למבחן הדפדפן מפני שהוא מהיר, ואז מתייחסים לתוצאה כהוכחה שהשרת נגיש ומוגדר. זו הוכחה לגבי GET לנתיב ששורת הכתובת פתחה, לא יותר. שיחת ה-VPN מתחילה אחרי אותה לחיצת יד של TLS, אבל שולחת שיטה ונתיב שדף אינטרנט לעולם אינו משתמש בהם. לכן תשובה 200 לדפדפן אינה אומרת דבר על קיומה של נקודת הקצה של SSTP.
הפרידו בין שתי התצפיות והחיפוש מתקצר. התעבורה ושרשרת האישורים עובדות, ומשהו בחילופי הפרוטוקול מעליהן לא. זו חקירה שונה מפורט שבור או אישור שפג, והיא דורשת ראיות אחרות.
מה הלקוח SSTP באמת שולח
הלקוח שולח בקשת HTTP בשיטה SSTP_DUPLEX_POST לנתיב /sra_{GUID}/, ואז משאיר את גוף החיבור פתוח כזרם דו-כיווני הנושא מסגרות PPP. שרת תואם עונה HTTP/1.1 200 ומפסיק להתנהג כשרת אינטרנט. כל דבר אחר הוא חתימה: 405 או 404 פירושו שנקודת הקצה אינה שם, 301 או 302 פירושו שמשהו מפנה מחדש את הבקשה, ו-FIN מיידי פירושו שפרוקסי או שרת סגרו את הזרם.
לכן היעד חייב להיות שרת SSTP ולא שרת אינטרנט עם אישור TLS מוברג. השיטה, הנתיב והגוף ארוך הטווח הם דרישות פרוטוקול, ולכן פרוקסי הפוך אינו יכול להוסיף אותם רק באמצעות תצורה. פרוקסי שמעביר HTTPS רגיל באופן מושלם עדיין עשוי לסרב לשיטה שאינו מזהה.
היכן פרוקסי או שרת אינטרנט שובר את הזרם
מתווך בודק את שורת בקשת ה-HTTP לפני שהוא מעביר משהו, ושיטה מותאמת עם נתיב לא שגרתי עשויה להיכשל בכלליו. התקנים מסוימים מגישים דף רגיל תוך שהם דוחים או מפריעים למנהרה, ולכן הלקוח מדווח על חיבור שמתחיל ואז מת במקום דחייה נקייה. אחרים מקבלים את הבקשה ואז מיישמים פסק זמן של גוף או של חוסר פעילות שאותו PPP keepalives אינם שורדים. שניהם נראים זהים מצד הלקוח, ולכן השלב שנכשל חשוב יותר מטקסט השגיאה.
שיתוף פורט 443 בין אתר אינטרנט ל-SSTP הוא בחירת ניתוב, לא הבטחה שכל הקפיצה מטפלת בשתי השיחות באותה דרך. אם מאזן עומסים, חומת אש או מסיים TLS נמצא בנתיב, הוסיפו אותו לרשימת החשודים לפני שתיגעו בתצורת ה-VPN.
בדקו את השלבים בנפרד
הריצו את הבדיקות לפי הסדר ועצרו בכשל הראשון, כי כל שלב שולל שכבה אחרת. בדיקת ה-TLS שלמטה מפרידה בין זהות האישור לבין כל מה ש-SSTP עושה. החליפו את שם המארח בנקודת הקצה שלכם וקראו את ה-subject ואת השרשרת שהיא מדפיסה.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comלאחר מכן מפו את הראיות הנותרות לשלבים במקום לנחש משגיאת הלקוח. הטבלה שלמטה היא רשימת הבדיקה לציטוט בכרטיס, עם החתימה שמפרידה בין כשל אחד לבא אחריו.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
תעדו בכרטיס את השלב האחרון שהצליח במקום לכתוב "לא ניתן להתחבר". מפרט MS-SSTP מתעד את הבקשה ואת חילופי ה-PPP שאחרי לחיצת היד של TLS, וזה המקור לכך שמבחן בדפדפן אינו יכול להחליף אף אחד מהם.
קודם זהות, אחר כך PPP
זהות TLS ואימות PPP הם רציפים, לא חלופיים, וערבוב ביניהם שולח אנשים להגדרת שרת שגויה. הלקוח מאמת קודם את אישור השרת ואת ייעודו המיועד, ואז PPP מנהל משא ומתן על מצבו ומאמת את המשתמש בשיטת אתגר-תגובה או EAP. בעיית אישור מייצרת שגיאה שונה מסיסמה שנדחתה, ואף אחת מהשגיאות אינה מתארת את השלב שהאחרת מכסה.
החלפת שם המארח בכתובת, או לחיצה מעבר לאזהרת האישור, מסירה את הבדיקה שהייתה מזהה את השלב הכושל במקום לתקן אותו. השאירו את האזהרה וקראו אותה. גם אל תאפסו סיסמת PPP כשחילופי ה-HTTP מעולם לא הגיעו להתנהגות SSTP, כי פרטי הכניסה מעולם לא התבקשו.