למה RDP קופא כשהמחשב המרוחק מתחבר ל-VPN

אתה בתוך חלון RDP, השולחן על המסך, ואתה לוחץ Connect בלקוח ה-VPN שרץ במכונה המרוחקת ההיא. שניות לאחר מכן החלון קופא ואז נסגר. המנהרה עלתה, וזה בדיוק מה שלוג ה-VPN ידווח, וזו העובדה הכי פחות שימושית בכל התקרית. החיבור מת מפני שהמכונה שדיברת איתה שינתה את הדרך שבה היא עונה לך, לכן בדוק את נתיב החזרה לפני שאתה נוגע במנהרה.

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

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

במחשב המרוחק, לפני שה-VPN מחובר, רשום את החיבורים הקיימים וקרא את כתובת העמית מהטבלה. אחר כך כתוב אותה במקום כלשהו מחוץ למכונה הזו, כי לא תוכל לקרוא אותה לאחר שהחיבור ייפול.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

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

קרא את המסלול שעונה לנקודת הקצה הזו

Windows בוחר ממשק לכל יעד, והפקודה Find-NetRoute מציגה את ההחלטה שהוא היה מקבל עכשיו. הרץ אותה על כתובת העמית לפני ההתחברות, ואז שוב כשהמנהרה למעלה, והשווה את אינדקס הממשק ואת הקפיצה הבאה בשתי התשובות. שינוי ממשק הוא כל הבאג בשורה אחת של פלט.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

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

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

עקוב אחרי שינוי פרופיל חומת האש

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

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

השווה את הפרופיל שמשויך לממשק המנהרה לפרופילים שאליהם מכוונים כללי Remote Desktop. כלל שמופעל רק עבור Domain ו-Private לא עושה דבר לממשק שמסווג כ-Public, ושום תיקון מסלול לא משנה את זה. חלק מלקוחות ה-VPN גם מגבילים לפי תכנון גישה לתת-הרשת המקומית, מה שמייצר אותה צורת כשל מבקרה אחרת.

בדוק את המעבר ממקום שממנו אפשר להתאושש

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

תכנן את החזרה לאחור לפני שאתה מתחיל, למשל משימה מתוזמנת שמריצה rasdial "Work VPN" /disconnect אחרי מרווח מוגדר. זה הופך חיבור שאבד להפסקה של חמש דקות במקום ביקור באתר, וזו הביטוח הזול ביותר בכל הנוהל.

חזור פנימה כשהחיבור כבר נעלם

אם המארח כבר אינו נגיש, הפסק לנסות חיבורי RDP חדשים מאותו לקוח והשתמש בערוץ ההתאוששות שכבר יש לסביבה: RD Gateway, קונסולת היפרוויזר או ממשק ניהול מחוץ לרצועה. בקש מהאדם עם גישה לקונסולה להריץ את אותן פקודות Find-NetRoute ו-Get-NetConnectionProfile, כדי שהראיות ישרדו את ההתאוששות.

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