MSCHAPv2 پروتکل VPN نیست: اول درباره تونل بپرسید
یک گذرواژه و واژه MSCHAPv2 با هم اتصالی نمی‌سازند. بپرسید کدام تونل تبادل را حمل می‌کند، سپس نمایهٔ کارخواه را با آن تطبیق دهید.
نام‌های کاربری و گذرواژه‌ها درون یک حامل سفر می‌کنند و MSCHAPv2 تنها نام روشی را می‌آورد که سفر می‌کند. پیش از انتخاب نمایهٔ کارخواه بپرسید کدام تونل آن را حمل می‌کند، زیرا همان رشتهٔ حساب در چیدمان‌هایی ظاهر می‌شود که حتی یک خط کد هم مشترک ندارند. هر نمایه‌ای که به شما می‌دهند هر دو تصمیم را رمزگذاری می‌کند، حتی وقتی برگهٔ دستورالعمل فقط یکی از آن‌ها را چاپ می‌کند. ترتیب زیر همان چیزی است که یک اپراتور بدون حدس زدن می‌تواند پاسخ دهد و شما بدون گرفتن بسته می‌توانید بررسی کنید.
احراز هویت درون یک تونل سوار می‌شود
یک VPN دو تصمیم می‌گیرد که مانند یکی به نظر می‌رسند: چگونه دو طرف یک کانال محافظت‌شده می‌سازند و چگونه یک شخص هویت خود را درون آن اثبات می‌کند. تصمیم دوم روی برگهٔ دستورالعمل چاپ می‌شود زیرا همان است که انسان تایپ می‌کند. تصمیم اول تعیین می‌کند آیا اصلاً هیچ کارخواهی کار می‌کند و همان است که مردم از آن می‌گذرند. از اپراتور بخواهید نخست حامل و سپس روش را نام ببرد، دقیقاً به همین ترتیب. دو اتصال می‌توانند همان نام حساب و همان گذرواژه را بخواهند بی‌آنکه زیر کادر ورود هیچ پیاده‌سازی مشترکی داشته باشند.
به همین دلیل تنظیماتی که از گوشی سالم یک همکار کپی شده‌اند ممکن است روی گوشی شما شکست بخورند، حتی وقتی سرور هر دو اعتبارنامه را می‌پذیرد. اعتبارنامه هرگز تفاوت نبود؛ نمایه‌ای که دور آن پیچیده شده بود تفاوت بود. هر دو طرف درست می‌گویند و هیچ چیز متصل نمی‌شود معمولاً همین سردرگمی است و به‌محض نام بردن حامل برطرف می‌شود.
سه جایی که همان روش ظاهر می‌شود
در PPP گام احراز هویت تا وقتی پیوندی وجود داشته باشد صبر می‌کند و RFC 2759 MS-CHAPv2 را همان گام تعریف می‌کند، به همین دلیل این روش در L2TP و در استقرارهای قدیمی‌تر PPTP ظاهر می‌شود. تونل نخست پایان می‌یابد و گفت‌وگوی PPP درون آن رخ می‌دهد، پس یک مرحلهٔ ناموفق PPP می‌تواند تونل را در گزارش سرور برپا نشان دهد. این دو مرحله را جدا بخوانید پیش از آنکه نتیجه بگیرید اعتبارنامه‌ها رد شده‌اند. بنابراین کارخواهی که برای L2TP پیکربندی شده می‌تواند کاملاً درست باشد و با این حال کارخواه نادرست برای دروازه‌ای باشد که فقط IKEv2 سخن می‌گوید.
IKEv2 به‌جای آن EAP-MSCHAPv2 را درون تبادل کلید می‌گذارد، پس همان اعتبارنامه در لحظه‌ای متفاوت شکست می‌خورد و به‌صورت خطای احراز هویت و نه خطای نشست ظاهر می‌شود. نمایهٔ IKEv2 سکوی Android نمونهٔ روزمره است و به‌جای گزینه‌های PPP گواهی یا شناسهٔ سرور می‌خواهد. نام حساب در هر دو چیدمان یکسان است، پس نمی‌تواند بگوید کدام را دارید. تنها فهرست پروتکل‌های پشتیبانی‌شدهٔ اپراتور این را روشن می‌کند.
یک VPN مبتنی بر TLS چیدمان سوم را اضافه می‌کند، با کادرهای نام کاربری و گذرواژهٔ خودش و بدون هیچ MS-CHAPv2 در هیچ جای تبادل. پس دیدن کادر گذرواژه هیچ شاهدی بر پروتکل پشت آن نیست، زیرا فرم طوری ساخته شده که آشنا به نظر برسد. پروتکل را از مستندات سرور تأیید کنید، نه از شکل پنجرهٔ کارخواه.
پاسخ‌هایی که واقعاً به آن‌ها نیاز دارید
درخواست را به‌صورت فهرست بفرستید، زیرا پاسخ نصفه‌ونیمه به فهرست دشوار است. پروتکل تونل، روش درون آن و کارخواهی را که اپراتور روی سکوی شما پشتیبانی می‌کند بخواهید. سپس هویت و تنظیمات اعتماد دروازه، قالب حساب و آنچه پس از برپا شدن اتصال باید در دسترس باشد را بخواهید.
سه پاسخ نخست تعیین می‌کند آیا اصلاً نمایهٔ کارآمدی می‌گیرید. سه پاسخ آخر تعیین می‌کند آیا آن نمایه کاری را که لازم است انجام می‌دهد. پاسخ را ضمیمهٔ تیکت نگه دارید، زیرا نفر بعدی همان شش پرسش را خواهد پرسید. جایی که پاسخ نیست، آن شکاف را تصمیمی بدانید که اپراتور هنوز نگرفته، نه چیزی که شما بتوانید استنتاج کنید.
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
بازبینی دروازه را سست نکنید
سرور نیز هویت خود را به کارخواه اثبات می‌کند و این نیمهٔ تبادل تزئینی نیست. خاموش کردن بازبینی گواهی تا یک نمایهٔ لجباز متصل شود هر نقطهٔ پایانی را که پاسخ دهد می‌پذیرد، از جمله نقطه‌ای که هیچ‌کس قصد رسیدن به آن را نداشت. همچنین یک ناسازگاری واقعی را پنهان می‌کند به‌جای حل آن، و این شکست را به لحظه‌ای دیرتر و کم‌آشکارتر می‌راند. نمایه‌ای که بازبینی را خاموش می‌خواهد، نمایه‌ای است که به چیزی اشاره می‌کند که نمی‌تواند بازبینی کند.
ناسازگاری معمولاً یک نام است، زیرا گواهی‌ای که برای یک نام میزبان صادر شده وقتی نمایه نشانی را می‌گیرد شکست می‌خورد. نام را بگیرید نه اینکه بازبینی را خاموش کنید. یک مرجع صدور گواهی خصوصی وقتی شکست می‌خورد که ریشه هرگز به دستگاه داده نشده باشد، و راه‌حل توزیع آن ریشه از مسیر تأییدشده است. محیط‌های مدیریت‌شده انتظار دارند اپراتور هویت و لنگر اعتماد را تأمین کند و نمایه به هر دو ارجاع دهد. وقتی کادر غایب است، مصنوع را بخواهید نه اینکه از بازبینی کنار بکشید.
نمایه را تطبیق دهید، سپس هر مرحله را اثبات کنید
وقتی حامل شناخته شد، فرایند مستند آن کارخواه را دنبال کنید و فقط کادرهایی را که می‌خواهد وارد کنید. کادرهای اضافی که چون وجود دارند پر می‌شوند همچنان مقدار نادرست‌اند و دیرتر از کادرهای الزامی شکست می‌خورند. نمایه را پس از نخستین اتصال موفق بدون تغییر ذخیره کنید تا ویرایش بعدی با چیزی که می‌دانیم کار می‌کند مقایسه شود.
سپس مرحله‌به‌مرحله بررسی کنید: تونل برپا می‌شود، کاربر احراز هویت می‌شود، نشانی و مسیرهای تخصیص‌یافته ظاهر می‌شوند و یک سرویس مجاز پاسخ می‌دهد. هر مرحله خط گزارش خودش را روی سرور می‌گذارد و خواندن آن‌ها به ترتیب شکایت مبهم را به یافتهٔ مشخص تبدیل می‌کند. اگر سکو دیگر چیدمانی را که اپراتور توصیف می‌کند پشتیبانی نکند، این گفت‌وگویی دربارهٔ مهاجرت است نه دلیلی برای روشن کردن همهٔ گزینه‌های قدیمی روی دستگاه. حامل، روش و نمایه سه پاسخ جداگانه‌اند و اتصالی که کار می‌کند هر سه را هماهنگ دارد.