ניהול מרחוק עם IIS Manager: בדקו קודם את הכתובת של WMSVC עצמו

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

שני מאזינים, שתי בעיות שונות

בקשה לאתר מגיעה לכריכת HTTP.sys של אותו אתר, שמוגדרת לפי אתר ולפי פרוטוקול בתצורת applicationHost. בקשה מ-IIS Manager מגיעה ל-WMSVC, שברירת המחדל שלו היא מענה ב-HTTPS על TCP 8172 והוא מוגדר ברמת השרת. שום דבר בכריכת האתר לא משנה היכן WMSVC מאזין, ושום דבר ב-WMSVC לא משנה באיזו כתובת האתר עונה. הם חולקים מכונה אחת ומאגר תעודות אחד, ושם נגמר הדמיון.

לכן Test-NetConnection מוצלח בפורט 443 אומר לכם שמאזין האתר נגיש, וכלום לגבי הניהול.

מצאו את הכתובת שאליה WMSVC באמת כבול

שאלו את השרת למה הוא מאזין עכשיו, ולא למה הוא הוגדר להאזין לפני שנים. Get-NetTCPConnection -LocalPort 8172 -State Listen מדפיס את הכתובת המקומית, וערך 0.0.0.0 או :: פירושו כל הכתובות, בעוד שכתובת ספציפית פירושה רק היא. אם הכתובת של שרת שונתה, מאזין שעדיין מוצמד לכתובת שהוצאה משימוש הוא בדיוק התקלה שהבדיקה הזו תופסת.

הערך המוגדר נמצא בעמוד Management Service של IIS Manager בצומת השרת, ומאחוריו בקובץ administration.config תחת ספריית התצורה inetsrv. השוו בין השניים: מה שהקובץ אומר, ולמה השקע באמת כבול.

לאחר מכן הריצו Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed מלקוח ה-VPN שנפגע וקראו את הכתובת שנפתרה ואת כתובת המקור שנבחרה. תשובת DNS שונה דרך ה-VPN נפוצה מספיק כדי שכדאי לשלול אותה מוקדם. שמרו בדיוק את שם המארח והפורט האלה בכרטיס, כי השוואה מאוחרת עם שם אחר לא מוכיחה דבר על השינוי שעשיתם.

קראו את כתובת המקור שהשרת רואה

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

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

שנו את הכריכה כשינוי שירות

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

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

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

הפרידו בין נגישות לבין אמון והרשאות

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

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