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

چهار خرابی که شبیه یکی هستند

مراحل مرتب‌اند: نام به نشانی خصوصی‌ای که طراحی در نظر دارد تبدیل می‌شود، درگاه به مصافحه TCP پاسخ می‌دهد، میزبان اتصال را طبق خط‌مشی خودش می‌پذیرد و ورود نشست موفق می‌شود. هر مرحله مرحله بعدی را غیرقابل‌آزمون می‌کند، به همین دلیل تغییر تنظیمات RDP پیش از سامان یافتن شبکه فقط سر و صدا ایجاد می‌کند. نشانه از دید کاربر در هر چهار حالت یکسان به نظر می‌رسد. تنها پیام کلاینت آنها را جدا می‌کند.

یک وب‌سایت داخلی سالم هیچ‌یک از این چهار را اثبات نمی‌کند. اثبات می‌کند که میزبانی در همان شبکه روی درگاه دیگری با سرویس دیگری پاسخ داده است. آن را شواهدی درباره مسیریابی و نه بیشتر بدانید.

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

آیا چیزی روی 3389 گوش می‌دهد؟

با نام شروع کنید، چون نامی که به نشانی اشتباه تبدیل شود همه آزمایش‌های بعدی را بی‌اعتبار می‌کند. از حل‌کننده تونل بپرسید نام چه معنایی دارد، سپس پاسخ را با نشانی خصوصی‌ای که طراحی در نظر دارد مقایسه کنید، نه با یک پاسخ موفق. نامی که به نشانی عمومی تبدیل شود تمام مشکل است و هیچ تغییری در RDP آن را درست نمی‌کند:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

سپس درگاه را آزمایش کنید نه میزبان را. یک مصافحه TCP کامل روی 3389 دسترسی را از هر چیزی که بالاتر از آن است جدا می‌کند:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

این آزمایش را از LAN و از تونل اجرا کنید، چون تفاوت بین دو نتیجه خرابی را در مسیر VPN موضع‌یابی می‌کند. دو فایروال در مسیر قرار دارند و اشتباه گرفتنشان آسان است: شبکه باید اجازه دهد نشانی تونل کلاینت به میزبان برسد و فایروال خود میزبان باید همان مبدأ را روی درگاه شنونده اجازه دهد. قاعده‌ای که به زیرشبکه LAN محدود شده، مخزن کلاینت‌های VPN را پوشش نمی‌دهد و این رایج‌ترین علت یک وقفه زمانی است که فقط کاربران راه دور گزارش می‌کنند. دامنه قاعده را بررسی کنید نه وجود آن را.

مسیر بازگشت هم همان بررسی را می‌خواهد. پاسخ‌ها به مسیری بازگشتی به مخزن کلاینت‌ها نیاز دارند نه به LAN، و ترجمه‌ای پیش از میزبان مبدأیی را که گزارش شما نشان می‌دهد تغییر می‌دهد. اگر درگاه در یک جهت پاسخ دهد و در جهت دیگر نه، نیمهٔ گمشده معمولاً مسیر بازگشت است.

پیش از خواندن پیکربندی، پیام را بخوانید

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

این قابلیت می‌تواند برای دستگاه فعال باشد در حالی که دسترسی به گروه‌های مشخصی محدود است، و شنونده می‌تواند به گونه‌ای مقید شود که نشانی‌ای را که از آن آمده‌اید کنار بگذارد. احراز هویت سطح شبکه دریچه‌ای اضافه می‌کند که پیش از بارگذاری دسکتاپ شکست می‌خورد و متن خطای آن با گذرواژه اشتباه متفاوت است. پیام کلاینت را با گزارش رویداد میزبان مقایسه کنید، چون پیام دریچه را نام می‌برد و گزارش حساب را.

ورود به نشست مرز خودش را دارد

احراز هویت متعلق به سرویس دسکتاپ است نه VPN. هویت تونل و حساب دسکتاپ اعتبارنامه‌های جداگانه با خط‌مشی‌های قفل جداگانه هستند، بنابراین یک تونل سالم فقط اثبات می‌کند که تونل شما را پذیرفته است. قفل کردن حساب دسکتاپ به تونل آسیبی نمی‌زند و برعکس آن هم درست است.

هر دو را دست‌نخورده نگه دارید. وقتی مسیر خصوصی نیست، مسیر را درست کنید، چون منتشر کردن شنونده در اینترنت یک باگ دسترسی را با یک دسکتاپ در معرض عوض می‌کند. بررسی‌های هویت نشست را هم برای عبور از هشدار گواهی‌ای که همزمان ظاهر شده ضعیف نکنید. گواهی خودامضا روی شنونده RDP به‌طور طراحی هشدار تولید می‌کند، پس پذیرش آن یک تصمیم است نه یک قدم.

پیش از تلاش دوباره، تلاش‌ها را بشمارید. آستانه‌های قفل دسکتاپ ورودهای ناموفق را جدا از خرابی‌های VPN می‌شمارند و کلاینتی که با زمان‌سنج دوباره تلاش می‌کند می‌تواند آستانه را رد کند در حالی که شما هنوز در حال ویرایش یک قاعده هستید. این همان سازوکار تلاش‌های موازی است که حساب‌ها را پس از تغییر گذرواژه قفل می‌کند.

نشست چه چیزی را می‌تواند جابه‌جا کند و کجا می‌ماند

گردش‌کار تأییدشده خروج را پیش از نیاز بیاموزید. بستن پنجره ممکن است فقط نما را قطع کند در حالی که نشست طبق خط‌مشی پیکربندی‌شده‌اش ادامه می‌یابد، که روی میزبان مشترک یا حسابرسی‌شده مهم است. وقتی خط‌مشی انتظار دارد، از داخل نشست خارج شوید.

سپس تصمیم بگیرید نشست چه چیزی می‌تواند حمل کند، چون کلیپ‌بورد، درایوهای هدایت‌شده، هدایت چاپگر و انتقال فایل همه داده را بین سیستم محلی و دور جابه‌جا می‌کنند آنجا که خط‌مشی اجازه می‌دهد. برنامه منتشرشده‌ای که در سمت دور اجرا می‌شود به‌طور خودکار مرز بدون دانلود نیست، و نشستی که فقط‌خواندنی به نظر می‌رسد باز هم می‌تواند کلیپ‌بورد حمل کند. وظیفه واقعی را آزمایش کنید نه اتصال را: فایل را باز کنید، برنامه را به کار ببرید و هدایتی را که لازم دارید تأیید کنید. راهنمای Microsoft برای دسترسی به دسکتاپ راه دور از بیرون گزینه‌های پشتیبانی‌شده در معرض قرار گرفتن را توصیف می‌کند و مرجع بهتری از یک شنونده عمومی است که تحت فشار اضافه شده باشد.

مقالات مرتبط