چرا RDP وقتی رایانه دور به VPN وصل می‌شود یخ می‌زند

شما داخل پنجره RDP هستید، میزکار روی صفحه است و در کلاینت VPN که روی همان ماشین دور اجرا می‌شود Connect را می‌زنید. چند ثانیه بعد پنجره یخ می‌زند و سپس بسته می‌شود. تونل بالا آمد، دقیقاً همان چیزی که گزارش VPN ثبت می‌کند، و این کم‌فایده‌ترین واقعیت در کل حادثه است. نشست مرد چون ماشینی که با آن حرف می‌زدید شیوه پاسخ دادن به شما را تغییر داد، پس پیش از دست زدن به تونل مسیر بازگشت را بررسی کنید.

نقطه پایانی را که نشست شما واقعاً استفاده می‌کند ثبت کنید

آدرسی که در کلاینت RDP تایپ می‌کنید لزوماً آدرسی نیست که رایانه دور به آن پاسخ می‌دهد. NAT، یک RD Gateway یا متعادل‌کننده بار در جلوی میزبان می‌توانند آن را بازنویسی کنند، و مسیر بازگشت را آدرس مبدئی تعیین می‌کند که ماشین دور روی اتصال برقرارشده می‌بیند. اگر اینجا اشتباه کنید، دنبال مسیری می‌روید که هرگز دخیل نبوده است.

روی رایانه دور، پیش از اتصال VPN، نشست‌های برقرارشده را فهرست کنید و آدرس همتا را از جدول بخوانید. سپس آن را جایی بیرون از آن ماشین بنویسید، چون پس از افتادن نشست نمی‌توانید آن را بخوانید.

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

با آن آدرس مثل چیزی رفتار کنید که باید دسترس‌پذیر بماند. اگر آدرس خصوصی روی یک VLAN مدیریت است، تونل باید آن مسیر را رها کند. اگر آدرس عمومی است، پاسخ باید از همان رابطی بیرون برود که درخواست را داخل آورده است.

مسیری را بخوانید که به آن نقطه پایانی پاسخ می‌دهد

ویندوز برای هر مقصد یک رابط انتخاب می‌کند و 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

نمایه تونل کامل یک مسیر پیش‌فرض از طریق تونل نصب می‌کند، همان‌طور که راهنمای مسیریابی 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 حفظ می‌شود، یا مدیریت به کانالی منتقل می‌شود که به مسیر پیش‌فرض میزبان وابسته نیست. هر دو قابل دفاع‌اند؛ یک مسیر میزبان با دروازه حدسی نه. بنویسید کدام را انتخاب کردید و آدرس همتایی را که باید دوام می‌آورد ثبت کنید.