شکست L2TP/IPsec: IPsec، احراز هویت تونل یا ورود PPP را جدا کنید

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

سه مرحله احراز هویت، سه هویت متفاوت

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

اتصال کنترلی L2TP می‌تواند یک تبادل چالش و پاسخ دوم و جداگانه اضافه کند که با رازی مشترک اداره می‌شود و هر دو سر باید آن را داشته باشند.

RFC 2661 آن احراز هویت اتصال کنترلی را اختیاری می‌کند و همین توضیح می‌دهد که چرا یک اشتباه یکسان در دو سرور نشانه‌های متفاوتی می‌دهد. استقرارهایی که هرگز راز تونل را تنظیم نکرده‌اند این مرحله را کاملاً رد می‌کنند؛ آن‌هایی که آن را فقط در یک طرف تنظیم کرده‌اند پیش از آنکه PPP حتی پیشنهاد شود شکست می‌خورند. سپس PPP کاربر را با PAP، CHAP یا MSCHAPv2 احراز هویت می‌کند و نام را به مخزن حسابی می‌سپارد که می‌تواند محلی، در chap-secrets یا روی RADIUS باشد. رمز عبور نادرست در آن نقطه هنوز شما را با تونلی سالم و نشستی شکست‌خورده رها می‌کند.

پیش از ویرایش پیکربندی، نقطه توقف را بخوانید

با ipsec --version شروع کنید تا بدانید خروجی وضعیت به strongSwan تعلق دارد یا به Libreswan. سپس گزارش سرور را بخوانید نه پنجره سمت کاربر را، چون سرور ثبت می‌کند کدام مرحله رد کرده است.

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

مواد کلیدی و رمزهای عبور را بیرون از آن چسباندن نگه دارید؛ نام مرحله مسیر کار را تعیین می‌کند و کلید از پیش مشترک لو رفته تکلیف را با پیامدهای بدتر باز می‌کند.

گام یک: آیا IPsec رابطه امنیتی دارد؟

روی strongSwan دستور ipsec statusall و روی Libreswan دستور ipsec whack --status را اجرا کنید و به‌دنبال یک رابطه فرزند برقرارشده با شمارنده‌های غیرصفر بگردید. ip xfrm state نمای هسته را در هر دو نشان می‌دهد. اگر جفت SA نصب‌شده‌ای شمارنده‌هایش بالا برود، مرحله اول تمام است و می‌توانید جلو بروید.

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

تا وقتی رابطه وجود ندارد بایستید. تغییر گزینه‌های PPP در آن نقطه هیچ چیزی را دگرگون نمی‌کند و ایراد واقعی را از نفر بعدی پنهان می‌کند.

گام دو: آیا اتصال کنترلی L2TP احراز هویت شد؟

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

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

تنها نشستی که مذاکره PPP را آغاز می‌کند واقعاً از مرحله تونل گذشته است.

گام سه: آیا PPP حساب را رد می‌کند؟

شکست PPP از بیرون متفاوت دیده می‌شود: تونل برقرار است، نشست آغاز می‌شود و شبح شکست روش احراز هویت یا رد حساب را ثبت می‌کند. روشی را که در آن پیام نام برده شده بخوانید. PAP و CHAP به دلایل متفاوتی شکست می‌خورند و سروری که یکی را رد کند، کاربری را که فقط همان را پیشنهاد می‌دهد رد خواهد کرد.

روی سرور Linux پرونده گزینه‌هایی را که شبح به PPP می‌دهد، معمولاً /etc/ppp/options.xl2tpd، بررسی کنید و تأیید کنید کدام روش‌ها پذیرفته می‌شوند و حساب‌ها کجا حل می‌شوند. نامی که در RADIUS هست ولی در پرونده رازهای محلی نیست، تمیز شکست می‌خورد و مانند رمز عبور بد به نظر می‌رسد. سپس بررسی کنید که کلاینت روشی را پیشنهاد می‌دهد که سرور می‌پذیرد، نه روشی قوی‌تر که سرور از مذاکره بر سر آن خودداری می‌کند. عوض کردن کلید از پیش مشترک برای تعمیر این مرحله یک بعدازظهر را هدر می‌دهد و هیچ چیزی را تغییر نمی‌دهد.

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