פסק זמן ב-SSTP או שגיאת תעודה: איך להבדיל ביניהם

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

שני כשלים, שני חילופים שונים

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

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

שורת היומן בדרך כלל אומרת באיזה משלושת המצבים אתם נמצאים, ולכן כדאי לתעד אותה לפני השינוי הראשון.

פסק זמן פירושו ששלב לא הסתיים מעולם

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

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

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

שגיאת תעודה פירושה שהזהות נדחתה

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

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

איפה השניים מתבלבלים

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

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

שאלת התעודה ושאלת הנגישות מתועדות בנפרד מסיבה.

בדקו שוב עם הלקוח האמיתי, ואז התקדמו פנימה

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

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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