L2TP: سیگنال مرگبار 15، NO_PROPOSAL_CHOSEN و نبود modp1024

اتصال شما قفل می‌کند، کلاینت خارج می‌شود و آخرین خط روی صفحه death_handler: Fatal signal 15 received است. آن خط از قطع شدن خبر می‌دهد، نه از علت. یک خط بالاتر در گزارش IPsec تقریباً همیشه NO_PROPOSAL_CHOSEN وجود دارد و این جفت به فاز 2 تبادل اشاره می‌کند، جایی که دو طرف گزینه‌های رمزگذاری و هش را مقایسه می‌کنند و وقتی هیچ گزینه مشترکی ندارند متوقف می‌شوند. در آن مرحله اعتبارنامه‌ها هنوز ارسال نشده‌اند، پس تایپ دوباره گذرواژه نمی‌تواند نتیجه را تغییر دهد.

معمولاً دو چیز آن اشتراک را در یک کلاینت لینوکس خالی می‌کند. ممکن است دیمن محلی دیگر گروه Diffie-Hellman مورد درخواست پروفایل را پیاده‌سازی نکند، یا پروفایل یک پیشنهاد فاز 1 را در فیلد فاز 2 داشته باشد. هر دو ردپایی در گزارش می‌گذارند و هیچ‌کدام مشکل حساب نیست.

این دو پیام در واقع چه می‌گویند

IKE در چند مرحله مذاکره می‌کند. فاز 1 یک کانال محافظت‌شده می‌سازد و الگوریتم‌های خودش را انتخاب می‌کند؛ فاز 2، یعنی SA فرزند، ترافیک را با مجموعه‌ای جداگانه حمل می‌کند. NO_PROPOSAL_CHOSEN همان اعلانی است که پاسخ‌دهنده وقتی هیچ‌یک از ترکیب‌های پیشنهادی قابل قبول نیست برمی‌گرداند و به شکل [ HASH N(NO_PROP) ] درون تبادل INFORMATIONAL ظاهر می‌شود.

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

پیش از دست زدن به اعتبارنامه‌ها مذاکره را بخوانید

سطح گزارش را جایی که دیمن می‌نویسد بالا ببرید و سپس در حالی که خروجی را می‌پایید دوباره وصل شوید. روی میزبان NetworkManager افزونه L2TP آن سطح را به بک‌اند می‌دهد و پیام‌ها بسته به توزیع در journal یا در فایل کلاسیک syslog می‌نشینند. هر یک از این دو تبادل را نشان می‌دهد: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' یا tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

خطی که pluto را نام می‌برد از libreswan می‌آید، charon از strongSwan، و هر دو همان وضعیت را با واژه‌های متفاوت توصیف می‌کنند. شکلی که ارزش جست‌وجو دارد آن است که گروه گمشده را نام می‌برد، مثلاً algorithm 'modp1024' is not supported، چون خطای مبهم را به خطای مشخص تبدیل می‌کند.

modp1024 کجا رفت

گروه 2 Diffie-Hellman به‌قدری ضعیف است که چند توزیع از نسخه 3.30 به بعد کامپایل آن را در libreswan متوقف کردند. آن‌گاه پروفایلی که سال‌ها پیش نوشته شده، یا از راهنمای دروازه‌ای برداشته شده که فقط aes128-sha1-modp1024 را فهرست می‌کند، از دیمن محلی چیزی می‌خواهد که اصلاً نمی‌تواند انجام دهد. ساخت‌های تازه‌تر NetworkManager-l2tp این نتیجه را محتمل‌تر می‌کنند: از 1.2.16 مجموعه را با پیشنهادهایی به سبک Windows 10 و iOS جایگزین می‌کنند و به‌محض تشخیص libreswan، modp1024 را کنار می‌گذارند. طرف مقابل اغلب بی‌تقصیر است و همچنان دقیقاً همان گروهی را ارائه می‌دهد که پیکربندی کرده‌اید.

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

دو تعمیر با دامنه اثر متفاوت

تعمیر ارزان این است که الگوریتم‌ها را دستی ثابت نکنید. هر دو فیلد پیشنهاد را در ویرایشگر خالی کنید و بگذارید افزونه مجموعه‌ای را انتخاب کند که طرف دور می‌پذیرد؛ اگر دروازه گروه‌های مدرن را پشتیبانی کند، مذاکره بدون کار بیشتری کامل می‌شود.

تعمیر دوم دروازه قدیمی را با نصب strongSwan در دسترس نگه می‌دارد، که بسته‌هایش در بیشتر توزیع‌ها هنوز گروه 2 را پیاده‌سازی می‌کنند. این یک تعویض دیمن است، پس هزینه دارد: پیش از حذف آن بررسی کنید آیا تونل‌های دیگر روی میزبان به پیکربندی libreswan وابسته‌اند، و در Fedora انتظار ردهای SELinux میان NetworkManager و افزونه strongSwan را داشته باشید. آن ردها در گزارش حسابرسی بیرون می‌آیند نه در ردپای IKE، و همین باعث می‌شود تونل درست پس از نصب موفق خراب به نظر برسد. ترتیبی که کار می‌کند این است: اول dnf install strongswan، سپس rpm -e libreswan.

رشته‌های پیشنهادی سازگار، و تله‌های پیرامونشان

وقتی فیلدها باید دستی پر شوند، فاز 1 و فاز 2 مقادیر متفاوتی می‌گیرند. جفتی که در برابر طرفی به سبک Meraki کار می‌کند، در فاز 1 aes128-sha1-modp1024 را با 3des-sha1-modp1024 در پشت آن ارائه می‌دهد، هر دو با علامت تعجبی بسته شده‌اند که مجموعه را سخت‌گیر می‌کند، پس فقط همان پیشنهادها فرستاده می‌شوند.

سپس فاز 2 به aes128-sha1 و 3des-sha1 باریک می‌شود با همان نشانه سخت‌گیر و بدون هیچ پسوند Diffie-Hellman. خطی در فاز 2 که -modp1024 را حمل می‌کند مقداری از فاز 1 در فیلد نادرست است و پاسخ‌دهنده آن را در هر تلاش دوباره رد می‌کند. آن خط را در پروفایل دومی کپی کنید و پروفایل دوم هم به همان شکل شکست می‌خورد، و این‌گونه یک غلط تایپی به حادثه‌ای در کل ناوگان تبدیل می‌شود.

خطاهای دیگر همان پنجره را می‌پوشند بی‌آنکه ناسازگاری پیشنهاد باشند. در KDE ممکن است نوع L2TP با افزونه نصب‌شده فهرست شود در حالی که هر اتصال فوراً می‌میرد، چون ویرایشگر اتصال و کمک‌کننده‌های زمان اجرا به‌صورت بسته‌های جداگانه عرضه می‌شوند. میزبان‌های بی‌نمایشگر می‌توانند پروفایلی از یک میزکار سالم را دوباره به کار ببرند: آن را از /etc/NetworkManager/system-connections/ کپی کنید، حالت را روی 600 بگذارید و سپس nmcli con reload را اجرا کنید. آن را با nmcli con up id work-l2tp بالا بیاورید، چون شکل خالی UUID می‌خواهد، و هر ورودی کهنه ifname را حذف کنید، وگرنه مدیر Could not find source connection پاسخ می‌دهد در حالی که همه‌چیز دیگری درست است.

یک کلید از پیش اشتراکی می‌تواند به‌صورت متن آشکار یا به‌صورت 0s و سپس base64 ذخیره شود؛ هر دو شکل کار می‌کند، اما مقدار باید بایت‌به‌بایت با دروازه بخواند، از جمله فاصله‌های انتهایی که همراه آن کپی کرده‌اید.