SSTP מאחורי פרוקסי שבודק TLS: היכן הפגישה נשברת

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

התחילו במקום שבו הלקוח עוצר

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

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

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

מה SSTP מבקש מהרשת לשאת

SSTP פועל מעל TLS על TCP 443 ואז שולח בקשת HTTP בשם SSTP_DUPLEX_POST, המוגדרת במסמך מפרט SSTP, לנתיב בצורה /sra_{GUID}/. הבקשה מכריזה על אורך תוכן בלתי מוגבל למעשה ומשאירה את הזרם פתוח בשני הכיוונים לכל חיי הפגישה. מסגרות PPP עוברות בתוך הזרם הזה.

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

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

למה בדיקה משנה את הזהות

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

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

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

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

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

בחרו את הנתיב הנתמך

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

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

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