SSTP תפס את פורט 443: למה Apache לא עולה

Apache מפסיק לענות על 443 אחר הצהריים שבו מישהו מפעיל חיבורי VPN נכנסים, ויומן השגיאות שלו מאשים את ה-bind במקום את ההזמנה שמאחוריו. Windows Routing and Remote Access מפעיל SSTP באותו רגע, והמאזין של SSTP תובע את TCP 443 דרך מחסנית ה-HTTP לפני ששום לקוח מאמת את עצמו. התביעה נשארת בתוקף גם כשהתעודה חסרה, השם שגוי או שכל handshake נדחה, כך ש-VPN שאיש אינו יכול להתחבר אליו עדיין תופס את הפורט. קראו קודם את טבלת ההאזנה; ה-PID שמחזיק ב-443 הוא שקובע איזו מהתיקונים שלמטה בכלל פתוחה בפניכם.

ההזמנה שורדת תעודה שבורה

SSTP עוטף את PPP בתוך הפעלת TLS, ולכן הוא זקוק ל-443 ולכן הוא עובר דרך פרוקסי שמפילים מנהרות אחרות. המאזין אינו socket שהשירות VPN פותח לעצמו: SstpSvc רושם אותו אצל מנהל ההתקן של HTTP בגרעין, כך שהפורט נשאר מוזמן כל עוד השירות פועל. הרישום הזה אינו מתייעץ עם התעודה לעולם, כלומר שם שפג, subject לא מתאים או היעדר תעודה לגמרי משאירים את 443 תפוס. הכשלים מתפצלים אז לשני כיוונים: handshakes נדחים נוחתים ביומן System תחת RasSstp, בעוד ששרת האינטרנט יכול רק לדווח שלא הצליח לבצע bind.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

השורה הראשונה מחזירה את ה-PID המחזיק; השנייה שמה את השירות שמאחוריו, והתשובה היא בדרך כלל שירות ה-HTTP או מחסנית ה-RRAS. כאשר tasklist עונה בתהליך מארח משותף, קראו את עמודת השירות במקום לנחש משם התהליך.

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

IIS חולק את מנהל ההתקן, Apache פותח socket

IIS מוסר את ה-bindings שלו לאותו מנהל התקן גרעיני שבו משתמש SSTP, ומנהל ההתקן הזה מפריד חיבורים נכנסים לפי שם מארח וקידומת URL, כך שאפשר לבקש משני השירותים לרצות את 443 בלי שאחד מהם ייכשל. Apache ו-nginx עושים את ההיפך: הם קוראים ל-bind על ה-socket שלהם, ומערכת ההפעלה מסרבת מפני שהכתובת כבר תפוסה. שום דבר באף אחד מהשניים אינו שגוי; ההבדל טמון ב-איזה API מחזיק בפורט. זו גם הסיבה לכך שהפעלת ה-VPN מפילה אתר אחד על מארח אחד ומשאירה אתר זהה על מארח אחר ללא פגע.

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

בחרו איזה שירות שומר על 443

פורט המאזין חי בערך רישום יחיד, DWORD עשרוני תחת מפתח הפרמטרים של Sstpsvc. שנו את הערך, הפעילו מחדש את Routing and Remote Access, ואשרו מטבלת ההאזנה שהפורט הישן פנוי.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

בחרו פורט ששום דבר אחר במארח אינו רוצה, והקלידו אותו בעשרוני: reg add שומר את ה-DWORD בדיוק כפי שנכתב, כך שערך שנועד כמשושה-עשר נוחת כפורט אחר. אם השאילתה אומרת שהערך אינו קיים, השורה השנייה יוצרת אותו. Restart-Service RemoteAccess מפיל את כל מי שמחובר, וזה שווה תכנון. הריצו שוב את בדיקת ההאזנה לאחר מכן, מפני שרשומה מיושנת על 443 משמעה שהשירות שמר על הרישום הישן שלו.

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

התנועה האחרת שומרת על 443 אצל IIS ומתייחסת ל-Apache כאל backend שהפרוקסי מעביר אליו. היא משמרת את ברירת המחדל של SSTP ומשאירה בעלים אחד לפורט, במחיר כותרות מועברות, כתובת לקוח שהאפליקציה אינה רואה עוד ישירות, ו-backend שחייב לדבר בפרוטוקול שהפרוקסי באמת שולח.

הוכיחו את הבעלים, התעודה וה-handshake לפי הסדר

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

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

השורה הראשונה שמה את ה-PID שמחזיק ב-443, וזה אמור להיות השירות שזה עתה הגדרתם. השנייה מפרטת תעודות מכונה עם ה-subjects שלהן, כך ששם שאינו תואם לכתובת בפרופיל הלקוח בולט מיד. שאילתת האירועים מחזירה רשומות SSTP אחרונות, ו-handshake שלעולם אינו מגיע לאימות PPP משאיר רשומה שונה מזו שמאומתת ואז נדחית. השלב האחרון נראה רק בלקוח, שם הרשומה מדווחת מחובר או נוקבת בשגיאת PPP.

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