یک کاربر نمی‌تواند به VPN وارد شود: تشخیصی مرحله‌به‌مرحله

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

گزارش را نقطهٔ آغاز بدانید، نه تشخیص. بررسی‌های زیر از ارزان‌ترین آغاز می‌شوند، و هر یک طوری نوشته شده که وقتی شکست بخورد، بررسی را پایان دهد.

مرحله و مُهر زمانی را مشخص کنید

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

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

رویداد هویت همان تلاش واحد را بخوانید

از مدیر بخواهید رکورد احراز هویتی را که با دقیقهٔ ثبت‌شدهٔ شما می‌خواند بیرون بکشد. در استقرار Windows NPS، راهنمای عیب‌یابی NPS مایکروسافت رویداد رد 6273 را همراه با کد دلیلی که با آن می‌آید مستند می‌کند، و این معمولاً کاربر ناشناس، اعتبارنامهٔ بد، ناسازگاری سیاست و تماسی که به دلیلی نامرتبط قطع شده را از هم جدا می‌کند.

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

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

هر بار یک شرط را تغییر دهید، در چارچوب سیاست

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

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

ترمیم را روی مسیر اصلی تأیید کنید

وقتی حلقهٔ شکسته شناسایی شد، تنها همان حلقه را ترمیم کنید و تلاش اصلی را تکرار کنید: همان فرد، همان دستگاه، همان شبکه، همان برنامه. حساب آزمونی که از VLAN مدیریت متصل می‌شود ثابت می‌کند درگاه زنده است، و دربارهٔ صبح سه‌شنبهٔ کاربر چیزی ثابت نمی‌کند. از کاربر بخواهید همان کاری را انجام دهد که شکست خورد، نه کاری ساده‌تر، زیرا ping موفق دربارهٔ اشتراک فایل ردشده چیز کمی می‌گوید.

تیکت را با آنچه کنار گذاشته شد و آنچه تغییر کرد ببندید. آن یادداشت تفاوت میان نجات یک‌باره و چیزی است که مهندس کشیک بعدی می‌تواند دوباره به کار ببرد.