NO_PROPOSAL_CHOSEN در L2TP؟ ابتدا دروازه را اسکن کنید
کلاینتی که پیش از پرسش نام کاربری شکست میخورد هرگز دربارهٔ فاز 1 توافق نکرده است. بهجای چسباندن رشتههای رمز، مجموعهٔ پیشنهادهای دروازه را اسکن کنید.
پرسش نام کاربری هرگز ظاهر نمیشود و کلاینت NO_PROPOSAL_CHOSEN را گزارش میکند. در آن لحظه اعتبارنامهها و کلید از پیش اشتراکشده بیاهمیتاند، زیرا دو طرف بر سر نحوهٔ محافظت از فاز 1 توافق نکردهاند. بیشتر مردم با چسباندن رشتهٔ رمزی که آنلاین پیدا کردهاند پاسخ میدهند. اسکن دروازه به همان پرسش با شواهد پاسخ میدهد و تقریباً به همان اندازه زمان میبرد.
پیام چه چیزی را رد میکند
رد شدن در حالت اصلی رخ میدهد، پیش از هر تبادل L2TP یا PPP، بنابراین نه تونل و نه پایگاه دادهٔ کاربران بررسی نشدهاند. فاز 1 دربارهٔ رمزگذاری، یکپارچگی و یک گروه Diffie-Hellman مذاکره میکند. فاز 2 دربارهٔ پیشنهاد ESP برای داده مذاکره میکند. شکست در فاز 1 با تغییر یک تنظیم PFS در فاز 2 برطرف نمیشود، و یک انجمن IKE کاملشده ثابت نمیکند که پیشنهاد ESP مناسب است.
پیش از ویرایش نحو، بکاند را ثبت کنید: ipsec --version. libreswan و strongSwan برای الگوریتمهای یکسان املای متفاوتی از پیشنهاد را میپذیرند.
سپس رد شدن را در بافت با این فرمان بخوانید: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.
دروازه را برای مجموعهٔ تبدیلهایش اسکن کنید
یک اسکنر مستقیماً از دروازه میپرسد که چه تبدیلهایی را مذاکره خواهد کرد. ابتدا سرویس محلی IPsec را متوقف کنید تا کاوش با کلاینت خودتان رقابت نکند، سپس خطوط SA را بخوانید. با فهرست مانند شواهدی دربارهٔ همتا رفتار کنید، نه مانند منویی که باید یکجا فعال شود.
sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=
دستگاههای قدیمی اغلب 3DES، SHA1 و MODP1024 را ارائه میدهند، زیرا اینها پیشفرضهای زمان عرضهٔ محصول بودند و هیچکس دوباره به آنها نپرداخت. خروجی خام اسکن را نگه دارید، زیرا تنها سند آن است که همتا در آن روز چه ارائه کرده است. اگر این قویترین همپوشانی موجود است، تشدید درست به سمت مالک دروازه است، نه به سمت پیکربندی کلاینتی که رمزنگاری ضعیف را برای همه دوباره فعال میکند.
همپوشانی را بدون خاموش کردن ایمنی تطبیق دهید
فقط تبدیلهایی را وارد کنید که هم در اسکن و هم در سیاست شما ظاهر میشوند. نمونهٔ زیر دروازهای را بازمیتاباند که در فاز 1، 3DES، SHA1 و MODP1024 را ارائه میدهد. به هشدار بکاند توجه کنید: libreswan 4.x گروه modp1024 را کامپایل نمیکند، بنابراین این برای strongSwan یا ساخت libreswan با پشتیبانی DH2 صدق میکند. پیش از نتیجهگیری که کلاینت خراب است، نسخه را بررسی کنید.
Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1
یک علامت تعجب در پایان، یک پیشنهاد را سنجاق میکند. از آن برای جدا کردن یک آزمون استفاده کنید و سپس آن را بردارید تا دروازه بعداً بتواند چیزی قویتر را مذاکره کند.
پیش از تلاش دوباره، دیمن و درگاه را بررسی کنید
NetworkManager-l2tp نمونهٔ xl2tpd خودش را راه میاندازد. اگر سرویس سیستم از قبل مالک UDP 1701 باشد، کلاینت به یک درگاه مبدأ موقت عقب مینشیند، که RFC 3193 آن را مجاز میداند و برخی سرورها بیصدا آن را دور میریزند. پیش از تلاش بعدی، مالک سوکت را بررسی کنید.
sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service
رازهای تولیدشدهٔ کهنه دلیل خاموش دیگری است. فایلهای زیر /etc/ipsec.d/ که به نام یک اتصال قدیمی هستند میتوانند از پروفایلی که آنها را ساخته بیشتر زنده بمانند، پس آنهایی را که چیزی به آنها ارجاع نمیدهد حذف کنید و دوباره تلاش کنید.
در پایان، بررسی کنید که توصیه از کجا آمده است. یک ipsec.conf که برای IKEv1 XAuth نوشته شده، نوع دیگری از VPN را توصیف میکند و پیشنهادش تنها خط اشتباه در یک پروفایل L2TP نیست. مجموعهٔ تبدیلی را که وارد کردید کنار پروفایل ثبت کنید تا نفر بعد کاوش را تکرار نکند.