چرا PPP CHAP به‌تنهایی نمی‌تواند نیازمندی MPPE را برآورده کند

پروفایل PPTP که بر رمزنگاری پافشاری می‌کند معمولاً در همان نقطه شکست می‌خورد: PPP روی یک تبادل احراز هویت توافق می‌کند که هرگز مواد کلیدی مورد نیاز MPPE را تولید نمی‌کند. تونل نیمه‌زنده به نظر می‌رسد، گذرواژه پذیرفته می‌شود و پیوند پیش از عبور هیچ ترافیکی قطع می‌شود. دست بردن به فهرست کشویی CHAP تا وقتی چیزی وصل شود، نقص واقعی را پنهان می‌کند، و آن نقص قراردادی میان روش احراز هویت و سیاست حفاظت است. بررسی‌های زیر طوری مرتب شده‌اند که هر یک علتی ارزان‌تر از بعدی را رد کند.

دو مذاکره درون یک اتصال PPTP جریان دارد

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

CHAP ساده همان تبادل چالش-پاسخ در RFC 1994 است که بر یک راز مشترک و هیچ چیز دیگری بنا شده است. MS-CHAPv2 تبادلی متفاوت با پیام‌های متفاوت و خروجی متفاوت است که در RFC 2759 استاندارد شده است. واژه مشترک در دو نام تنها چیز مشترک آن‌ها روی سیم است. هیچ‌یک از دو نام نمی‌گوید تبادل چه تولید می‌کند، و این تنها بخشی است که اهمیت دارد.

به همین دلیل گزینه‌ای که صرفاً CHAP برچسب خورده در یک پروفایل قدیمی مبهم است. وقتی سرور MS-CHAPv2 می‌خواهد و کارخواه CHAP ساده پیشنهاد می‌دهد، کنترل پیوند هنوز می‌تواند کامل شود و گذرواژه هنوز می‌تواند پذیرفته شود. شکست بعدتر می‌رسد، وقتی سرور می‌کوشد کلیدهای حفاظت را از تبادلی استخراج کند که چیزی تولید نکرده است.

روش مورد نیاز را با کلیدهایی که می‌تواند تولید کند هماهنگ کنید

کلیدهای MPPE به‌طور کلی ویژگی PPP نیستند. برای خانواده Microsoft CHAP اشتقاق در RFC 3079 مشخص شده است و به عنوان ورودی خروجی یک تبادل MS-CHAP را می‌گیرد، نه یک راز مشترک. روش‌های EAP از راهی دیگر به همان جا می‌رسند، با این تفاوت که سرور احراز هویت کلیدها را به صورت ویژگی‌های MS-MPPE-Recv-Key و MS-MPPE-Send-Key برمی‌گرداند. CHAP ساده در هیچ‌یک از دو مسیر ظاهر نمی‌شود، و این تمام دلیل وجود این ناسازگاری است.

پیکربندی‌ای که MPPE می‌خواهد اما هر روشی را که می‌تواند کلید تأمین کند رد می‌کند، درونی متناقض است. pppd این تناقض را با رد کردن پیوند حل می‌کند، نه با اختراع کلید، پس نتیجه قابل مشاهده نشستی است که احراز هویت می‌شود و سپس در مرحله شبکه پایان می‌یابد. تلاش دوباره کارخواه تا زمانی که سرور تنها روش‌هایی را که چیزی اشتقاق می‌کنند رد می‌کند، تغییری ایجاد نمی‌کند.

قاعده‌ای که از این نتیجه می‌آید کوتاه است: اگر پروفایل MPPE می‌خواهد، روش باید گونه‌ای از MS-CHAP یا روشی از EAP باشد که سرور کلیدهایش را برمی‌گرداند. رد کردن تنها MS-CHAPv2 این را تحمیل نمی‌کند، چون MS-CHAPv1 هم کلید اشتقاق می‌کند و در دسترس می‌ماند مگر آنکه جداگانه رد شود؛ رد کردن هر دو، CHAP ساده و PAP را باقی می‌گذارد که چیزی اشتقاق نمی‌کنند و نیازمندی را برآورده‌نشدنی می‌کنند. روش پذیرفته‌شده را صریحاً نام ببرید، به جای فهرست کردن روش‌هایی که دوست ندارید. کنار گذاشتن نیازمندی رمزنگاری برای وصل شدن یک کارخواه، تنزل است نه تعمیر.

پیش از ویرایش کارخواه، گزینه‌های سرور را بخوانید

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

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

خروجی را به عنوان یک قرارداد بخوانید، نه فهرستی از پرچم‌ها. خطی که MPPE می‌خواهد اما هر دو گونه MS-CHAP را رد می‌کند را هیچ کارخواهی نمی‌تواند برآورده کند، و نبودِ نیازمندی برای یک روش MS-CHAP در را به روی تبادل‌هایی باز می‌گذارد که کلیدی نمی‌دهند. سپس بررسی کنید چه کسی اصلاً اجازه احراز هویت دارد، که پرونده رازها آن را تعیین می‌کند:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

شکست را بر اساس مرحله PPP پیدا کنید

PPP شکست‌ها را در مرحله‌ها گزارش می‌کند و مرحله می‌گوید کدام بند قرارداد شکسته است. پیوندی که هرگز کنترل پیوند را ترک نمی‌کند مشکل کپسوله‌سازی یا مذاکره دارد، در حالی که پیوندی که احراز هویت می‌شود و سپس می‌میرد معمولاً مشکل سیاست یا کلید دارد. پیوندی که برپا می‌ماند و چیزی حمل نمی‌کند به مسیریابی رسیده است، که تحقیقی دیگر است.

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

پیش از خاموش شدن نقطه پایانی قدیمی، خروج را برنامه‌ریزی کنید

MPPE یک سازوکار تاریخی حفاظت پیوند است و وجودش PPTP را برای استقرار جدید گزینه‌ای معقول نمی‌کند. راهنمایی کنونی Microsoft پیشاپیش بر ضد PPTP و بر ضد L2TP/IPsec با کلید از پیش مشترک برای استقرارهای دسترسی از راه دور جدید توصیه می‌کند. زنده نگه داشتن یک نقطه پایانی قدیمی تصمیمی درباره یک سرویس موجود است، نه الگویی برای بعدی.

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

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