L2TP NO_PROPOSAL_CHOSEN: کدام مرحله واقعاً شکست خورد؟
اعلان می‌گوید یک پیشنهاد رد شده است، نه کدام یکی. گزارش بک‌اند را برای یافتن مرحله بخوانید، سپس مجموعه‌ها را با کسی که دروازه را اداره می‌کند مقایسه کنید.
NO_PROPOSAL_CHOSEN پیش از آنکه هر نام کاربری PPP بررسی شود می‌رسد، که واقعیتی سودمند است و همچنین دلیل گمراه‌کننده بودن پیام. این پیام گزارش می‌دهد که یک طرف پیشنهادی را رد کرده است؛ گزارش نمی‌دهد کدام پارامتر اختلاف داشته، و هیچ نمی‌گوید که آیا رد شدن هنگام ساختن انجمن IKE رخ داده یا بعدتر هنگام مذاکره بر سر حفاظت ترافیک. پشت این دو احتمال دو اصلاح متفاوت ایستاده است، و تنها یکی از آن‌ها به کادر تیک PFS مربوط می‌شود که مردم نخست به سراغش می‌روند.
یک پیام، دو مجموعه پیشنهاد
ترتیب IKEv1 L2TP/IPsec دو مذاکره پیاپی دارد. مرحله 1 انجمن امنیتی IKE را از یک الگوریتم رمزنگاری، یک الگوریتم یکپارچگی و یک گروه Diffie-Hellman می‌سازد. سپس مرحله 2 بر سر این مذاکره می‌کند که ترافیک چگونه محافظت شود، و شرط PFS به همان گفت‌وگوی دوم تعلق دارد.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
چون مرحله‌ها پیاپی‌اند، جای شکست به شما می‌گوید کدام فهرست را مقایسه کنید. تمام ارزش تشخیصی پیام همین است، و ارزش دارد پیش از دست زدن به هر تنظیمی آن را بیرون بکشید.
چرا کادر تیک PFS نمی‌تواند مرحله 1 را تعمیر کند
غیرفعال کردن PFS ویژگی‌ای از مرحله 2 را تغییر می‌دهد. اگر طرفین هرگز بر مرحله 1 توافق نکرده باشند، گفت‌وگوی ESP هرگز رخ نمی‌دهد، پس کادر تیک هیچ اثری بر رد شدن ندارد، و به همین دلیل تغییر آن همان خطا را با زمان‌مهر دیگری تولید می‌کند.
اشتباه معکوس به همان اندازه رایج است. یک انجمن IKE موفق ثابت نمی‌کند که پیشنهاد ESP پذیرفتنی است، و قطعاً ثابت نمی‌کند که گروه مرحله 2 مطابقت دارد. تونل مدیریت برقرارشده را فقط شاهدی بر مرحله 1 بدانید. مردم خط سبز را «تونل برپاست» می‌خوانند، سپس یک ساعت را در مرحله نادرست می‌گذرانند چون چیزی به آن‌ها نگفته بود که مذاکره دوم آغاز نشده است.
پیش از انتخاب الگوریتم‌ها گزارش را بخوانید
پیام‌های بلافاصله پیش از رد شدن را از بک‌اندی که واقعاً اتصال را اداره می‌کند جمع کنید و آن‌ها را با همان تلاش متناظر کنید. بدون این تناظر، تاریخچه اتصال دیگری را می‌خوانید و از آن نتیجه می‌گیرید.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanاز آن خطوط به دو پرسش پاسخ دهید: آیا انجمنی برای مرحله 1 برقرار شد، و کدام تبادل شکست خورد. این دو پاسخ جست‌وجو را به یک فهرست ویژگی محدود می‌کند. اعلانی برهنه بدون زمینه پیرامون نمی‌تواند چنین کند، هرچند وسوسه‌انگیز است که پیشنهادی را از یک رشته انجمن امتحان کنید. کپی کردن یک رشته کارآمد از ماشینی با بک‌اند متفاوت معمولاً یک رد شدن را با رد شدنی دیگر، کمی دیرتر، جایگزین می‌کند.
نحو بک‌اند سفر نمی‌کند
پیش از مقایسه هر چیز، نسخه NetworkManager-l2tp و نسخه بک‌اند IPsec را ثبت کنید. Libreswan و strongSwan نه نحو پیشنهاد را شریک‌اند و نه مجموعه الگوریتم یکسان را، پس رشته‌ای که در یکی کار می‌کند در دیگری خطای نحوی است. بک‌اند نصب‌شده ممکن است IKEv1 را نیز بر اساس سیاست رد کند، و در آن صورت هیچ پیشنهادی هرگز پذیرفته نخواهد شد.
README پروژه آن تفاوت‌های بک‌اند را مستند می‌کند و فیلدهای مرحله 1 و مرحله 2 را جدا نگه می‌دارد. آن را به‌عنوان مستند ساختار بخوانید، نه دعوتی برای فعال کردن هر رمز تاریخی و یک گروه ضعیف، چون اتصالی که تنها با این کار موفق می‌شود همان اتصالی نیست که از شما خواسته‌اند بسازید.
بر سر مجموعه توافق کنید، سپس مرحله‌ها را بررسی کنید
از اپراتور دروازه بپرسید کدام مجموعه‌های IKE و ESP پشتیبانی و تأیید شده‌اند، سپس آن پاسخ را با پیشنهادهای واقعی کارخواه مقایسه کنید نه با پرونده پیکربندی آن. اگر اختلاف دقیقاً درباره PFS مرحله 2 است، بر یک گروه پشتیبانی‌شده یا سیاستی با تأیید صریح بدون PFS توافق کنید. سیاست را از نام خطا استنتاج نکنید.
وقتی تنها هم‌پوشانی به رمزنگاری‌ای نیاز دارد که سازمان دیگر نمی‌پذیرد، تصمیم به دروازه یا به مهاجرت پروتکل تعلق دارد. گستردن رشته کارخواه تا وقتی چیزی مذاکره کند، راهی است برای تحویل یک ضعف شناخته‌شده با یک تیک سبز در کنار آن.
پس از اصلاح ناسازگاری واقعی، برقراری IPsec را پیش از بررسی L2TP و PPP تأیید کنید، و هر رد شدن احراز هویت بعدی را متعلق به مرحله بعد بدانید. سپس تمدید را در فرایند آزمون تأییدشده بیازمایید، چون برقراری نخستین انجمن هیچ چیزی درباره بقیه عمر آن نمی‌گوید.