Cisco Secure Client اتصال VPN را از یک نشست RDP مسدود میکند
کلاینت گذرواژه شما را میپذیرد و سپس به این دلیل که نشست از طریق RDP آمده است، از ساخت تونل خودداری میکند. این سیاست پروفایل است، نه خطای احراز هویت.
ورود موفق میشود و با این حال تونل بالا نمیآید. این ترکیب مردم را سردرگم میکند، چون آن را مشکل احراز هویت میخوانند و بعد یک بعدازظهر را صرف بازنشانی اعتبارنامههایی میکنند که هرگز مشکل نبودهاند. Cisco Secure Client میتواند دقیقاً به این دلیل که تلاش از یک نشست Remote Desktop آمده است، از برقراری VPN خودداری کند، و این تصمیم را سیاست در سمت کلاینت میگیرد.
این موضوع کجای جریان اتصال ظاهر میشود
کلاینت را از بالا دنبال کنید. پروفایل بارگذاری میشود، اعتبارنامهها جمعآوری میشوند و احراز هویت کامل میشود. سپس، پیش از ساخت هر تونلی، کلاینت تنظیمات نشست و برقراری خود را در برابر محیطی که در آن قرار دارد ارزیابی میکند.
در آن لحظه سه چیز را یادداشت کنید: متن دقیق پیام، نسخه کلاینت و نام پروفایلی که در کلاینت نمایش داده میشود. این سه، شکایت مبهم را به درخواست پشتیبانیای تبدیل میکند که کسی میتواند روی آن اقدام کند. از گفتگو تصویر بگیرید، چون پیامهای طولانی در گزارش کوتاه میشوند. زمان را هم ثبت کنید تا مدیر بتواند آن را با سرور مرکزی تطبیق دهد.
تنظیمی که واقعاً تصمیم میگیرد
سیاست Windows VPN Establishment کنترل مربوطه است و دو مقدار مستند دارد: فقط کاربران محلی، و اجازه دادن به کاربران راه دور. دومی برقراری تونل از یک نشست Remote Desktop را در تنظیمات پشتیبانیشده مجاز میکند. اولی وضعیت پیشفرض در بسیاری از پروفایلهای سازمانی است.
آن را با Windows Logon Enforcement اشتباه نگیرید، که راهنمای پروفایل آن را سیاستی جداگانه درباره نشستهای ورود مستند میکند. یکی تعیین میکند کدام نشست میتواند تونل بسازد، دیگری رفتار همزمان یا پیش از ورود را تعیین میکند. تغییر مورد اشتباه هیچ اثر قابل مشاهدهای ندارد.
پروفایلی را بخوانید که واقعاً اعمال شده است
در استقرار مدیریتشده کلاینت پروفایل خود را از سرور مرکزی یا از مکانی مدیریتشده دریافت میکند و نسخهای که روی دیسک ویرایش میشود غالباً همان نسخه معتبر نیست. به همین دلیل یک تغییر محلی XML میتواند درست به نظر برسد و چیزی را تغییر ندهد.
از مدیر بپرسید دستگاه کدام پروفایل و کدام سیاست گروهی را دریافت میکند، نه اینکه کدام فایل روی لپتاپ وجود دارد. این دو پس از ارتقای نسخه غالباً با هم اختلاف دارند. نسخه کهنه در پوشه محلی هنوز در ویرایشگر باز میشود و هنوز درست به نظر میرسد. فقط چیزی نیست که کلاینت اعمال کرده است.
مسیر RDP پس از بالا آمدن تونل
اجازه دادن به برقراری راه دور تضمین نمیکند که نشست Remote Desktop شما دوام بیاورد. وقتی تونل مسیرها یا قواعد دسترسی محلی را تغییر میدهد، نشستی که شما را وارد کرده است میتواند مسیری را که آن را نگه میدارد از دست بدهد.
پیش از تغییر یک کانال بازیابی برنامهریزی کنید: دسترسی به کنسول، مسیر مدیریت خارج از باند، یا رویه مستند اتصال دوباره. تصمیمگیری بعد از تغییر معمولاً به معنای سفری به سمت دستگاه است.
برای دور زدن سیاست از ترفندهای دزدیدن نشست، ابزارهای کنترل از راه دور جایگزین یا گذرواژه نوشتهشده در یک اسکریپت استفاده نکنید. اگر سازمان این گردش کار را مجاز نمیداند، گام درست مسیر مدیریتی است که از آن پشتیبانی میکند.
چه چیزی برای مدیر بفرستید
متن پیام، نسخه کلاینت، نام پروفایل فعال، نوع نشستی که با آن متصل شدید و اینکه آیا تلاش از کنسول محلی رفتار متفاوتی دارد را به او بدهید. زمان دقیق را هم اضافه کنید.
همین مقایسه آخر است که وقت صرفهجویی میکند، چون رد شدن به دلیل سیاست نشست را از خرابی سراسری دستگاه جدا میکند.
پس از یک تغییر تأییدشده بررسی کنید
پس از بهروزرسانی پروفایل، یک نشست RDP تازه برقرار کنید و دوباره متصل شوید، سپس دنباله قطع اتصال را عمداً اجرا کنید. تأیید کنید تونل بالا میآید، مسیر مدیریت دوام میآورد و حساب شما همچنان میتواند به دسکتاپ وارد شود.
پذیرش VPN، دوام نشست و اجازه ورود به Windows سه بررسی جداگانه هستند. عبور از یکی درباره دو مورد دیگر چیزی نمیگوید.