RDP נעצר אחרי התקנת לקוח VPN? חומת האש אשמה
מתקין VPN צרכני יכול לשנות את פרופיל חומת האש של Windows ולנתק את RDP. חזרו דרך סוכן האורח, ואז צמצמו את הכלל לפורט 3389.
דקות ספורות אחרי שמתקין לקוח VPN צרכני מסיים, הפורטל עדיין אומר שה-VM פועל, כתובת ה-IP הציבורית לא השתנתה, ו-RDP לא מגיב. אנשים בדרך כלל מניחים שה-VM קרס או שקבוצת האבטחה של הרשת השתנתה, ושתי ההנחות בדרך כלל שגויות. מה שהשתנה הוא פרופיל חומת האש של Windows שבו המכונה נמצאת, וכלל ה-RDP שהתאים קודם כבר לא מתאים. התיקון מתחיל בהשגת מעטפת דרך נתיב שאינו תלוי ב-RDP.
ה-VM פועל, והכלל הפסיק להתאים
כללי חומת האש ב-Windows נושאים קבוצת פרופילים, וכלל שמוגבל לפרטי או לתחום אינו משפיע כל עוד המכונה נמצאת בפרופיל הציבורי. מתקיני VPN מוסיפים מתאמים ומסלולים, ורבים מהם מקשים את הציבורי כתופעת לוואי. המאזין נשאר קשור ל-3389 והחבילות עדיין מגיעות, אבל אי-ההתאמה של הפרופיל משליכה אותן.
מצב החשמל והנגישות הם עובדות נפרדות, ו-VM פועל עם פורט סגור נראה מבחוץ בדיוק כמו כזה שקרס.
בדקו את הפורט לפני שמשנים משהו. ניסיון התחברות ל-3389 שמסתיים בפסק זמן בזמן שפקודת סוכן האורח עדיין מחזירה פלט מצביע על חומת האש של המארח. פורט שמגיב בעוד RDP עדיין נכשל פירושו שהתקלה נמצאת מעל שכבת הרשת, והתיקון הזה לא ייגע בה. רשמו איזה משני המקרים ראיתם, כי שאר התוכנית תלויה בזה.
שני שערים נסגרים באופן בלתי תלוי
מדיניות הפלטפורמה פועלת ראשונה: קבוצת האבטחה של הרשת רואה את החבילה לפני האורח. הסדר הזה הופך רשומת NSG מושלמת לחסרת תועלת כשהמארח משליך את החבילה, וכלל מארח פתוח לחסר תועלת כשהפלטפורמה דוחה אותו. התייחסו אליהם כשני שערים נפרדים ובדקו כל אחד לבדו.
קראו את הכללים היעילים של ה-NSG בפורטל או ב-CLI, ואז השוו אותם לכללים של האורח עצמו. אל תניחו שהשינוי האחרון שאתם זוכרים הוא זה שנכנס לתוקף.
לקוח צרכני יכול גם להתקין מנהל התקן סינון או מתג השבתה שחוסם תעבורה מתחת לחומת האש של Windows. אם כללי חומת האש נראים נכונים והפורט עדיין נכשל, השכבה הזו היא החשודה הבאה.
השתמשו בסוכן האורח כדרך חזרה
שני מאפייני הרצה מרחוק, Run Command ו-Custom Script Extension, פועלים בתוך האורח דרך סוכן הפלטפורמה. אף אחד מהם לא זקוק ל-RDP, ולכן טעות חומת האש לא משפיעה עליהם. שניהם מחזירים את פלט הסקריפט, מה שהופך אותם לערוץ אבחון וגם לערוץ תיקון.
קראו את הפרופיל הפעיל ואת כלל ה-RDP לפני שתשנו מי מהם:
Get-NetConnectionProfile
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile
הפעלה מחדש של כללי כניסה בפרופיל הזה היא אמצעי זמני, לא יעד. השתמשו בה כדי לקבל הפעלה, ואז סגרו את הפרצה כראוי:
Set-NetFirewallProfile -Name Public -AllowInboundRules True
המתג הזה פותח כל כלל כניסה בפרופיל, לא רק RDP. לאחר שיש הפעלה, החליפו אותו בכלל מצומצם והחזירו את ההגדרות שאתם באמת רוצים. אם גם הסוכן אינו זמין, קונסולה סדרתית או דיסק שנבנה מחדש הם חלופת הגיבוי, וזו הסיבה המעשית לשמור על בריאות הסוכן.
צמצמו את הפרצה לפני שתסגרו את ההפעלה
שינוי הפרופיל הזמני הוא דלת שנשארת פתוחה לכל כלל כניסה בפרופיל הזה. החליפו אותו בכלל שמוגבל לכתובת המקור שלכם ולפורט RDP, ואז אשרו שהפרופיל חזר למצב המיועד. עשו זאת כל עוד ההפעלה בידכם, כי הטעות הבאה אולי לא ניתנת לביטול מרחוק. החזיקו נתיב ניהול שני, כמו Bastion או קונסולה סדרתית, במהלך השינוי.
אשרו את התוצאה מתחנת העבודה שלכם בבדיקת פורט, ומתוך האורח ברשימת הכללים:
Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter
הפעילו רישום של חומת האש למשך הבדיקה. שורה אחת על חבילה שנזרקה שמציינת 3389 והפרופיל הפעיל עונה על השאלה מהר יותר מאתחול נוסף.
מנעו מהמתקין הבא לעשות זאת שוב
אם למארח הזה אין סיבה להריץ את הלקוח, הסירו אותו. לקוח מותקן הוא הזמנה קבועה לעדכון הבא לשכתב את הפרופיל שוב, והאדם הבא ינפה את אותה תקלה מהפורטל.
צלמו תמונת מצב של הדיסק לפני שתתנו למשהו לשכתב הגדרות רשת, והחזיקו נתיב ניהול שני מוכן לפני שתזדקקו לו.
רשמו מה המתקין שינה: מתאמים, מסלולים, פרופילים של חומת האש, מנהלי התקן סינון ושירותים. הרשומה הזו הופכת את התקרית הבאה לתבנית מוכרת במקום חקירה חדשה. כשהמכונה זקוקה למנהרה לשירות אחד בדיוק, שימו את הלקוח בתחנת העבודה שלכם או בנו קישור בין אתרים במקום להתקין בשרת מוצר למחשבים ניידים. לקוחות צרכניים מיועדים למחשבים ניידים, ושרת שאתם מנהלים מרחוק אינו כזה.