פתרון בעיות ב-RDP

במצבים מסוימים, יכול להיות שלא תצליחו להתחבר למכונה הווירטואלית (VM) של Windows ב-Compute Engine דרך RDP. הסיבות לכך יכולות להיות שגיאות בהגדרה, שגיאות בחיבור לרשת או תהליך הפעלה שלא הושלם.

במסמך הזה ריכזנו טיפים וגישות לפתרון של בעיות נפוצות ב-RDP.

בדיקה שהמכונה הווירטואלית מחוברת לאינטרנט ומוכנה לשימוש

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

יציאה טורית 1

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

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. לוחצים על שם המכונה הווירטואלית שאת היומנים שלה רוצים להציג. הדף עם הפרטים של המכונה הווירטואלית ייפתח.

  3. בקטע logs, בוחרים באפשרות יציאה טורית 1.

  4. בודקים את הפלט של יציאה טורית 1 ומחפשים פלט דומה לזה:

    BdsDxe: loading Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi

UEFI: Attempting to start image.
Description: Windows Boot Manager
FilePath: HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
OptionNumber: 3.

2021/04/13 10:50:22 GCEGuestAgent: GCE Agent Started (version 20210128.00)
2021-04-13T10:50:23.4621Z OSConfigAgent Info: OSConfig Agent (version 20210217.00.0+win@1) started.
2021/04/13 10:50:42 GCEMetadataScripts: Starting startup scripts (version 20200129.00).
2021/04/13 10:50:42 GCEMetadataScripts: No startup scripts to run.

כשהפלט מכיל את הטקסט GCEGuestAgent או GCEMetadataScripts, זה אומר שמערכת Windows מופעלת. עליכם לנסות להתחבר מחדש ל-VM דרך RDP.

יציאה טורית 2

השיטה Serial port 2 מספקת חיבור אינטראקטיבי ל-VM וגם מציגה את הפלט של עמדת שליטה מיוחדת לניהול (SAC). אפשר להשתמש בקונסולה טורית 2 כדי לקבוע אם שירותי המערכת הופעלו.

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. לוחצים על שם המכונה הווירטואלית שאת היומנים שלה רוצים להציג. הדף עם הפרטים של המכונה הווירטואלית ייפתח.

  3. בקטע logs, מרחיבים את האפשרות More ולוחצים על יציאה טורית 2 (console)‎.

  4. בודקים את הפלט של יציאה טורית 2 ומחפשים פלט דומה לזה:

    BdsDxe: loading Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi

UEFI: Attempting to start image.
Description: Windows Boot Manager
FilePath: HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
OptionNumber: 3.

<machine-info>
<name>WINDOWS</name>
<guid>b7ab5000-4000-e000-e000-bc5a738da000</guid>
<processor-architecture>AMD64</processor-architecture>
<os-version>10.0</os-version>
<os-build-number>17763</os-build-number>
<os-product>Windows Server 2019 Datacenter</os-product>
<os-service-pack>None</os-service-pack>
</machine-info>
Computer is booting, SAC started and initialized.
Use the "ch -?" command for information about using channels.
EVENT: The CMD command is now available.
SAC>

כשהפלט מכיל את המחרוזת SAC started and initialized או CMD command is now available, זה אומר שמערכת Windows מופעלת. עליכם לנסות להתחבר מחדש ל-VM דרך RDP.

צילום מסך של ה-VM

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

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

  2. מצלמים את המסך. מידע נוסף זמין במאמר איך מצלמים מסך ב-VM.

  3. בודקים את צילום המסך כדי לקבוע אם המכונה מוכנה.

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

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

אם מערכת Windows לא מתחילה לפעול אחרי כמה דקות, קראו את המדריך פתרון בעיות ב-Windows.

בדיקת הקישוריות בין תחנת העבודה למופע ה-VM

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

curl -v telnet://DESTINATION_IP_ADDRESS:PORT

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DESTINATION_IP_ADDRESS: כתובת ה-IP של ה-VM של Windows
  • ‫PORT: היציאה שהוגדרה להתחברות באמצעות RDP במכונה הווירטואלית של Windows

אפשר גם להשתמש בבדיקות קישוריות כדי לוודא את הקישוריות בין מכונת ה-VM לבין מוצרים ושירותים אחרים של Google Cloud . בנוסף, יכול להיות שכדאי להגדיר יעד מבוצר (bastion host) באותה רשת משנה כדי לבודד בעיות בקישוריות RDP במכונה הווירטואלית.

בדיקת הקישוריות לשרת המטא-נתונים

כדי שמכונת Windows תפעל בצורה תקינה, חשוב שיהיה חיבור לשרת המטא-נתונים (169.254.169.254 או fd20:ce::254). אם המכונה תאבד את הגישה לשרת המטא-נתונים, יכול להיות שהאפליקציות לא יצליחו לקבל את פרטי הכניסה, ולא תוכלו להתחבר למכונה באמצעות RDP.

הודעות ביומני המסוף של יציאה טורית 1 יכולות לספק רמזים לגבי כשלים ברשת או בשירות במהלך ההפעלה. לדוגמה, חפשו שגיאות שמציינות שהמכונה לא יכולה להתחבר לשרת המטא-נתונים (169.254.169.254 או fd20:ce::254).

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

שימוש בסקריפט לפתרון בעיות ב-RDP

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

  1. מתחברים ל-SAC של מכונה וירטואלית של Windows.
  2. פותחים את PowerShell על ידי הקלדת powershell.

  3. מריצים את הפקודה הבאה כדי להפעיל את האבחון:

    powershell -file "C:\Program Files\Google\Compute Engine\diagnostics\rdp_status.ps1" | more

  4. בודקים אם יש תוצאות "FAIL" (נכשל) בפלט ומיישמים את הפתרונות המוצעים.

בדיקת הסיסמה של מכונת Windows

לכל מכונת Windows של Compute Engine חייבת להיות מוגדרת סיסמה מקומית, אם היא לא נמצאת בדומיין או באימג' מותאם אישית. כדי לוודא שאתם משתמשים בסיסמה הנכונה, צריך להתחבר ל-VM באמצעות כלי שורת הפקודה Google Cloud CLI או מסוף Google Cloud . מידע נוסף זמין במאמר התחברות ל-SAC של מכונה וירטואלית של Windows.

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

בדיקה אם אתם משתמשים ב-Windows Server Core

כשאתם מתחברים דרך RDP, אם מופיע חלון של שורת פקודה עם רקע ריק, סביר להניח שאתם משתמשים בהתקנת Windows Server Core. כדי לבדוק זאת, מריצים את הפקודה הבאה:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v InstallationType

כשהפלט מכיל את המחרוזת Server Core, זה אומר שאתם משתמשים במהדורת Windows Core.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    InstallationType    REG_SZ    Server Core

אם אתם צריכים להשתמש בממשק משתמש גרפי עבור עומס העבודה, תוכלו ליצור מכונת Windows Server שכוללת את התקנת Desktop Experience במקום את התקנת Windows Server Core. לחלופין, אתם יכולים לעיין בתיעוד של Microsoft בנושא ניהול שרת Windows Core.

בדיקת הכללים של חומת האש ב-VPC

מערכת Compute Engine מקצה אוטומטית כלל בחומת האש שמאפשר תעבורת RDP בפרויקטים חדשים. אם יש לכם פרויקט קיים, או אם שיניתם את ההגדרות, יכול להיות שלא קיים כלל ברירת המחדל של חומת האש שמאפשר תעבורת RDP. עליכם לוודא שקיים כלל המאפשר להתחבר באמצעות תעבורת RDP לרשת שבה נמצאת המכונה שאתם בודקים.

כדי לבדוק אם הכלל default-allow-rdp קיים בחומת האש בפרויקט, אתם יכולים להיכנס לדף Firewall rules או להריץ את הפקודה הבאה ב-CLI של gcloud:

gcloud compute firewall-rules list

אם הכלל עדיין לא קיים, צריך ליצור כלל חדש באמצעות הפקודה הבאה:

gcloud compute firewall-rules create allow-rdp --allow tcp:3389

אימות כתובת ה-IP החיצונית

עליכם לוודא שאתם מתחברים לכתובת ה-IP החיצונית הנכונה של המכונה. כדי להציג אותה, תוכלו להיכנס לדף VM instance או להריץ את הפקודה הבאה ב-CLI של gcloud:

gcloud compute instances list

פתרון בעיות ב-RDP במכונות וירטואליות בלי גישה ישירה לאינטרנט

כשמתחברים למכונה וירטואלית של Windows שאין לה כתובת IP חיצונית, יכול להיות שחיבור ה-RDP יפסיק להגיב בהודעה Securing remote connection או Configuring remote session, ואז יסתיים הזמן הקצוב לתפוגה. הבעיה הזו מתרחשת בדרך כלל כשמתחברים דרך מנהרת העברת TCP של שרת proxy לאימות זהויות (IAP) למכונה וירטואלית שאין לה גישה ישירה לאינטרנט.

במהלך לחיצת היד בפרוטוקול TLS לאימות ברמת הרשת, ה-API הקריפטוגרפי של Windows‏ (CAPI) מאמת את אישור ה-X.509 שבו משתמש מאזין ה-RDP. כדי לאמת את האישור הזה, CAPI שולח בקשות HTTP יוצאות לנקודות קצה של רשימת אישורים שבוטלו (CRL), של Online Certificate Status Protocol או של Windows Update. מכיוון שהשירות TermService ואימות האישורים פועלים בהקשר של המערכת, הם משתמשים בהגדרות לשרת proxy של WinHTTP ברמת המערכת, ולא בהגדרות לשרת proxy ברמת המשתמש. אם ל-VM אין נתיב ישיר לאינטרנט יוצא או הגדרת שרת proxy של WinHTTP, בקשות ה-HTTP האלה נכשלות בגלל זמן קצוב לתפוגה אחרי 15 עד 30 שניות, וחיבור ה-RDP נכשל.

כדי לפתור את הבעיה, התחברו ל-SAC של ה-VM של Windows והשתמשו באחת מהשיטות הבאות, בהתאם לדרישות הרשת והאבטחה:

הגדרת שרת proxy ל-HTTP ברמת המערכת באמצעות WinHTTP

אם הרשת מנתבת תעבורת נתונים יוצאת דרך שרת proxy ל-HTTP, צריך להגדיר את שרת ה-proxy ברמת WinHTTP כדי שבקשות לאימות אישורים ברמת המערכת ישתמשו בשרת ה-proxy:

  • כדי לציין שרת proxy של WinHTTP באופן ישיר, מריצים את הפקודה הבאה משורת פקודה עם הרשאות ניהול:

    netsh winhttp set proxy PROXY_SERVER:PORT

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROXY_SERVER: כתובת ה-IP או שם המארח של שרת ה-proxy ל-HTTP
    • ‫PORT: מספר היציאה של שרת ה-Proxy ל-HTTP

  • לחלופין, אם כבר מוגדר שרת proxy ברמת המשתמש ב-Windows, מייבאים את ההגדרות ברמת המשתמש ל-WinHTTP באמצעות הפקודה הבאה:

    netsh winhttp import proxy source=ie

השבתת העדכונים האוטומטיים של אישורי הבסיס

אם ה-VM פועל בסביבה מבודדת בלי גישה לאינטרנט או לשרת proxy ל-HTTP, צריך להשבית את העדכונים האוטומטיים של אישורי הבסיס כדי ש-Windows תאמת את האישורים רק באמצעות אישורי בסיס שמותקנים באופן מקומי:

מרשם

מריצים את הפקודה הבאה משורת הפקודה או מסשן PowerShell של SAC:

reg add "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot" /v DisableRootAutoUpdate /t REG_DWORD /d 1 /f

מדיניות קבוצתית

אם אתם מנהלים את המכונה הווירטואלית באמצעות מדיניות קבוצתית, בצעו את הפעולות הבאות:

  1. מריצים את הפקודה gpedit.msc כדי לפתוח את הכלי לעריכת מדיניות קבוצתית מקומית.
  2. עוברים אל Computer Configuration (הגדרות המחשב) > Administrative Templates (תבניות ניהול) > System (מערכת) > Internet Communication Management (ניהול תקשורת באינטרנט) > Internet Communication settings (הגדרות תקשורת באינטרנט).
  3. מגדירים את האפשרות Turn off Automatic Root Certificates Update (השבתת העדכון האוטומטי של אישורי הבסיס) ל-Enabled (מופעל).
  4. אופציונלי: אם העיכובים בחיבור נמשכים כי אישור מותאם אישית כולל נקודות קצה של CRL או של גישה למידע על רשות, אפשר להפחית את זמן הקצוב לתפוגה של אחזור הרשת של CAPI:
    1. ב-Local Group Policy Editor, עוברים אל Computer Configuration ‏> Windows Settings ‏> Security Settings ‏> Public Key Policies.
    2. פותחים את Certificate Path Validation Settings ובוחרים בכרטיסייה Network Retrieval.
    3. בוחרים באפשרות Define these policy settings ומגדירים את שני ערכי הזמן הקצוב לתפוגה של האחזור ל-1 שניות.
  5. כדי להחיל את השינויים, מריצים את הפקודה gpupdate /force משורת פקודה עם הרשאות ניהול.

הגדרת גישה יוצאת לאינטרנט באמצעות Cloud NAT

אם דרישות האבטחה שלכם מאפשרות תעבורת נתונים יוצאת מה-VM לאינטרנט, הגדירו שער Cloud NAT עם נתיב ברירת מחדל לאינטרנט של 0.0.0.0/0, כדי שה-VM יוכל להגיע ישירות לנקודות קצה חיצוניות לאימות אישורים.

שימוש ב-Remote Desktop Services (RDS) של Windows

אם במכונת Windows מותקנת התוכנה Remote Desktop Services (שנקראה בעבר Terminal Services), המערכת אוכפת את התנאים של Client Access Licenses ‏(CALs). כשכללי CAL נאכפים, הנסיונות להתחבר דרך RDP ייכשלו בכל אחד מהתנאים הבאים:

  • השתמשתם בכל הרישיונות שיש לכם
  • הרישיון שלכם מותקן, אבל לא מוגדר או לא מופעל כהלכה
  • תקופת הניסיון של 180 הימים ב-RSD הסתיימה

סימנים המעידים על כך שיכול להיות שאין לכם מספיק רישיונות תקפים כוללים הודעות כמו אלה:

  • הסשן המרוחק הזה נותק כי לא נמצאו שרתי Remote Desktop License זמינים שיכלו לספק רישיון.
  • הסשן המרוחק הזה נותק בגלל בעיות הקשורות לרשיונות של terminal server.
  • הסשן המרוחק הזה נותק כי לא נמצאו רשיונות זמינים לגישת לקוח ל-Remote Desktop למחשב הזה.

אם אתם לא מצליחים להתחבר דרך RDP, אתם יכולים להשתמש במתג ה-admin כדי להתחבר למכונה למטרות ניהול. אפשר לעשות את זה במחשב Windows באמצעות אפליקציית הלקוח המובנית של Remote Desktop Connection.

%SystemRoot%\System32\mstsc.exe /admin

התמונה של Windows Server ו-SQL Server על פי דרישה כוללת שני סשנים בו-זמניים של שולחן עבודה מרוחק לניהול.

כדי לפתור בעיות בהתחברות דרך RDP, אתם צריכים לרכוש רישיונות RDS חדשים למכונה שלכם. למידע נוסף על רישיונות CAL אפשר לעיין במסמכי התיעוד של Microsoft. לחלופין, אם אין לכם צורך ב-Remote Desktop Services, אתם יכולים להסיר את השירות ולהשתמש בחיבורי RDP רגילים.

אימות ההגדרות והמשאבים ברמת מערכת ההפעלה

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

בדיקה שיש למכונה הווירטואלית מספיק משאבים

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

שימוש במעבד (CPU), שימוש בזיכרון, שימוש בדיסק וקיבולת הדיסק

  • שימוש במעבד (CPU): 
    typeperf "\Processor(_Total)\% Processor Time" -sc 5
  • שימוש בזיכרון: 
    typeperf "\Memory\% Committed Bytes In Use" -sc 5
  • היקף השימוש בדיסק: 
    typeperf "\LogicalDisk(*)\% Idle Time" -sc 5
  • נפח הדיסק: 
    fsutil volume diskfree C:

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

  • מעבד (CPU): פחות מ-80%
  • זיכרון: פחות מ-80%
  • מקום בכונן: >20%
  • דיסק לא פעיל: >50%

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

בדיקה של הגדרות מערכת ההפעלה

התחברו ל-SAC של המכונה הווירטואלית והריצו את הפקודות הבאות כדי לוודא שהמכונה מקבלת חיבורים:

  1. בודקים שמתאם האתרנט מופעל:

    • פקודה: 
      netsh interface show interface
    • הצלחה: מצב האדמין מוגדר כמופעל בשם הממשק שמתויג כEthernet
    • נכשל: מצב האדמין מוגדר כ-Disabled בשם הממשק שמתויג כ-Ethernet
    • הפתרון: מפעילים את מתאם האתרנט: 
      netsh interface set interface Ethernet admin=enabled

  2. מוודאים שלמכונה יש הגדרת IP תקינה:

    • פקודה: 
      ipconfig /all
    • הצלחה: במתאם האתרנט Ethernet תוצג כתובת IPv4 של תת-הרשת שאליה הוקצתה המכונה.
    • נכשל: אין כתובת IPv4, או שהכתובת לא תואמת למה שמוצג במסוף Google Cloud .
    • פתרון: עוברים לשלב הבא.

  3. בודקים ש-DHCP מופעל במכונה:

    • פקודה: 
      netsh interface ipv4 show addresses
    • עבר: הפלט בקטע Ethernet מכיל את הערך DHCP Enabled: Yes.
    • נכשל: הפלט בקטע Ethernet מכיל את הערך DHCP Enabled: No.
    • הפתרון: מפעילים את DHCP במתאם האתרנט: 
      netsh interface ipv4 set address Ethernet dhcp

  4. בדיקה ש-'Remote Desktop Service' מופעל:

    • פקודה: 
      net start | find "Remote Desktop Services"
    • הצלחה: Remote Desktop Service
    • כישלון: (Remote Desktop Service לא נמצא בפלט)
    • הפתרון: הפעלה של Remote Desktop Services: 
      net start "Remote Desktop Services"

  5. בדיקה שהאפשרות Remote Connections מופעלת:

    • פקודה: 
      reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
    • הצלחה: ‎fdenTSConnections REG_DWORD 0x0‎
    • כישלון: f‎denTSConnections REG_DWORD 0x1‎
    • הפתרון: מפעילים חיבורים של שולחן עבודה וירטואלי מרחוק במרשם: 
      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /f /v fDenyTSConnections /t REG_DWORD /d 0

  6. בדיקה שהאפשרות Remote Desktop Connections מופעלת בחומת האש של Windows:

    • פקודה: 
      netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)"

    • הצלחה:‎Enabled:Yes, Direction: In, Profiles: Public, Grouping: Remote Desktop, LocalIP: Any, RemoteIP: Any, Protocol:TCP, LocalPort: 3389, RemotePort: Any, Edge traversal: No, Action: Allow‎

    • כישלון: (התקבלו תוצאות בלתי צפויות, למשל: ‎enabled = No)‏

    • הפתרון: מפעילים את כלל ברירת המחדל של חומת האש "Remote Desktop" ב-Windows Firewall: 

      netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

  7. בדיקה של מספר היציאה שמוגדר לחיבורי RDP במכונה המרוחקת:

    • פקודה: 
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
    • הצלחה: ‎PortNumber REG_DWORD [PORT NUMBER]‎
    • כישלון: (התקבל מספר יציאה לא צפוי)

    • הפתרון: מגדירים את מספר היציאה שנדרש ל-RDP במרשם: 

      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /f /v PortNumber /t REG_DWORD /d [PORT NUMBER]

  8. מוודאים שאפליקציה אחרת לא מנסה להשתמש באותה יציאה:

    • פקודה: 
      netstat -ano | find "3389"
    • הצלחה: מחפשים רשומה של יציאת ה-RDP שהוקצתה עם הסטטוס Listening. כדי למצוא את השירות התואם, אפשר להשתמש במזהה התהליך (PID) באמצעות הפקודה הבאה: 
      tasklist /svc | find ""
       כאשר PID הוא המזהה מהפקודה הקודמת. הפלט צריך להחזיר רק את Termservice.
    • נכשל: כל דבר מלבד Termservice משתמש ביציאה שהוקצתה.
    • הפתרון: מגדירים את האפליקציה או השירות כך שישתמשו במספר יציאה אחר.

  9. בדיקה האם לחשבון המשתמש המחובר יש הרשאות לחיבורים מרוחקים:

    • פקודה: 
      net localgroup "Remote Desktop Users"
    • הצלחה: (שם משתמש היעד המקומי או בדומיין נמצא ברשימה שהתקבלה)
    • כישלון: (שם משתמש היעד המקומי או בדומיין לא נמצא ברשימה)

    • הפתרון: מוסיפים את הכלל "Remote Desktop Users" למשתמש בדומיין: 

      net localgroup "Remote Desktop Users" /add [DOMAIN\USERNAME]

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

  10. מוודאים שהגדרות המשא ומתן של אבטחת שרת/לקוח מוגדרות לערך ברירת המחדל:

    • פקודה: 
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
    • הצלחה: ‎SecurityLayer REG_DWORD 0x1‎
    • כישלון: ‎SecurityLayer REG_DWORD 0x0 (או 0x2)‎
    • הפתרון: מגדירים את ערך המשא ומתן של האבטחה ברישום: 
      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 1 /f

  11. אם המכונה מחוברת לדומיין Active Directory אבל אי אפשר ליצור את החיבור, יכול להיות שתקבלו את השגיאה הבאה כשתנסו לגשת למכונה:

    The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA.

    מוודאים שאימות ברמת הרשת (NLA) מוגדר לערך ברירת המחדל:

    • פקודה: 
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
    • הצלחה: ‎UserAuthentication REG_DWORD 0x0‎
    • כישלון: ‎UserAuthentication REG_DWORD 0x1‎
    • הפתרון: מגדירים את הערך של אימות ברמת הרשת (NLA) במרשם: 
      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f

  12. בדיקה שגודל ה-MTU שלכם לא גדול מה-MTU של הרשת:

    • פקודה: 
      netsh interface ipv4 show subinterfaces
    • הצלחה: כשהמספר שמופיע אחרי ה-MTU תואם ל-MTU של רשת ה-VPC.
    • כישלון: כשהמספר שמופיע אחרי ה-MTU גדול מה-MTU של רשת ה-VPC.

    • הפתרון: מגדירים את ה-MTU של הממשק ל-MTU של רשת ה-VPC: 

      netsh interface ipv4 set subinterface Ethernet mtu=MTU_OF_VPC_NETWORK

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

  13. אם אתם מנסים להתחבר ל-VM באמצעות RDP וב-VM מוצג מסך פריסת המקלדת, אתם צריכים לבחור שפה על ידי התחברות ל-Windows SAC. כדי לבחור שפה, מבצעים את השלבים הבאים:

    1. מתחברים ל-SAC.
    2. פותחים את Powershell על ידי הקלדת powershell.

    3. משיגים את מחרוזת השפה הנכונה.

      Get-WinUserLanguageList

    4. מגדירים את הפריסה. מחליפים את LANGUAGE_TAG בפריסת המקלדת הרצויה (לדוגמה, en-US).

      Set-WinUserLanguageList -LanguageList LANGUAGE_TAG -force

    5. מפעילים מחדש את המכונה.

      shutdown -r -t 0

  14. אם מופיעות שגיאות RDP במסך ההתחברות שמוזכרות בהן you need the right to sign in through Remote Desktop Services או you must be granted the Allow log on through Terminal Services right, קבוצת המשתמשים או האדמינים של Remote Desktop הוסרה מההגדרה Local Computer Policy שנמצאת ב-Allow log on through Remote Desktop Services או ב-SeRemoteInteractiveLogonRight.

  15. מוודאים שאין הרשאות חסרות שחוסמות את אימות האישורים:

    • פקודה: 
      icacls.exe "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys"
    • הצלחה: הפלט דומה ל-Everyone:(R,W) BUILTIN\Administrators:(F)
    • נכשל: הפלט לא תואם ל-Everyone:(R,W) BUILTIN\Administrators:(F)

  16. בודקים שהגדרות ההגנה של אנטי-וירוס או נקודת הקצה (endpoint) בצד הלקוח מאפשרות שימוש בשירותים ובמספר היציאה שהגדרתם.

  17. שגיאה בתיקון של CredSSP encryption oracle: אם מופיעה שגיאה שמוזכר בה "CredSSP encryption oracle remediation", ודאו שמותקנים עדכוני Windows האחרונים גם בתחנת העבודה וגם במכונה הווירטואלית.

  18. קוד שגיאה פנימי 0x4: אם החיבור נכשל ומופיע "קוד שגיאה: 0x4", צריך לוודא ש-TLS 1.2 מופעל בשרת. אפשר לבדוק את המרשם בכתובת HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client.

  19. קוד שגיאה 0x108: אם מופיעה ההודעה "קוד שגיאה: 0x108 (שני המחשבים לא הצליחו להתחבר במסגרת הזמן שהוקצבה)", בודקים את מדדי הניטור כדי לראות אם יש ניצול גבוה של המעבד או ניצול זיכרון. אם המשאבים מוצו, כדאי לשנות את סוג המכונה.

אימות מגבלות הזמן הקצוב לתפוגה של סשנים

אם אתם מצליחים ליצור חיבור RDP אבל החיבור מתנתק אחרי זמן מה ומוצגת הודעה על Timer Expired, ודאו שהערכים הבאים הם כמו שצריך:

נתיב הרישום: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

מפתחות רישום:

  • MaxDisconnectionTime
  • MaxIdleTime
  • MaxConnectionTime
  • MaxDisconnectionTime
  • RemoteAppLogoffTimeLimit

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

פתרון בעיות בהפעלת Windows

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

המאמרים הבאים