شنوندهٔ OpenVPN 2.5 روی DD-WRT مرده است؟ پیکربندی‌ای را که ساخته بخوانید

شنوندهٔ مرده روی DD-WRT معمولاً یعنی سرویس هنگام تجزیهٔ پیکربندی‌اش خارج شده است، نه اینکه قاعده‌ای در فایروال درگاه را بسته باشد. OpenVPN 2.5 چند مقدار پیش‌فرض را که پیکربندی‌های قدیمی‌تر به آن‌ها تکیه داشتند سخت‌تر کرد، و پیکربندی تولیدشده‌ای که روی نسخهٔ قدیمی کار می‌کرد ممکن است پیش از آنکه سوکت اصلاً باز شود رد شود. دلیل در گزارش خود روتر است و ورودی در فایل تولیدشده. خواندن هر دو با این ترتیب از هر ضبط بسته‌ای سریع‌تر است.

سرویس همان فایروال نیست

این تفکیک مهم است چون هر دو خرابی از بیرون یکسان به نظر می‌رسند: کارخواه یک دست‌دهی می‌فرستد و چیزی برنمی‌گردد. یکی فرایندی است که اجرا نمی‌شود و دیگری فرایندی است که اجرا می‌شود و فیلتر می‌کند.

پیش از تغییر هر چیزی آن‌ها را با دو بررسی جدا کنید، چون ویرایش فایروال روی سرویس مرده فقط یک متغیر دوم اضافه می‌کند.

پیکربندی‌ای را که DD-WRT ساخته بخوانید

DD-WRT متنی را که در رابط وب تایپ کرده‌اید به OpenVPN نمی‌دهد. یک پیکربندی تولیدشده در /tmp/openvpn/openvpn.conf می‌نویسد و سرویس را با همان فایل اجرا می‌کند، پس فیلدهای رابط و هر متن Additional Config پیش از آنکه OpenVPN آن‌ها را ببیند ادغام می‌شوند. اگر به‌جای فایل تولیدشده خود فرم را اشکال‌زدایی کنید، قصدی را می‌خوانید نه ورودی واقعی. پیش از آنکه راه‌اندازی مجدد /tmp را پاک کند، آن فایل را جایی ماندگار کپی کنید.

فایل تولیدشده را با آنچه در نظر داشتید مقایسه کنید، به‌ویژه جایی که رابط دستوری را می‌نویسد که هرگز انتخاب نکرده‌اید. فهرست کشویی‌ای که گزینه‌ای منسوخ بیرون می‌دهد در فرم نامرئی و برای سرویس کشنده است.

اگر فایل تولیدشده خالی است یا وجود ندارد، سرویس حتی به مرحلهٔ اجرا نرسیده و مشکل بالادست OpenVPN است.

چه چیزی را OpenVPN 2.5 دیگر نمی‌پذیرد

OpenVPN 2.5 ncp-ciphers را با data-ciphers جایگزین کرد و حداقل نسخهٔ پیش‌فرض TLS را به 1.2 رساند. همچنین رفتار فشرده‌سازی را تغییر داد تا همتایی که فشرده‌سازی پیشنهاد می‌دهد رد شود مگر آنکه پیکربندی صریحاً اجازه دهد، و نام گزینه‌های قدیمی‌تر مانند ns-cert-type را به سود remote-cert-tls منسوخ اعلام کرد. هر یک از این تغییرها پیکربندی‌ای را که قبلاً کار می‌کرد به شکست تجزیه یا مذاکره تبدیل می‌کند.

شیوهٔ خرابی به دستور بستگی دارد. گزینهٔ ناشناخته یا حذف‌شده سرویس را در شروع متوقف می‌کند، همان شنوندهٔ مردهٔ شما. ناسازگاری در مذاکره سرویس را در حال اجرا می‌گذارد و کارخواهان را رد می‌کند، که از سمت کارخواه شبیه مشکل فایروال به نظر می‌رسد.

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

پیش‌نیازهای ویژهٔ Broadcom

در نسخه‌های Broadcom دستگاه تونل باید پیش از استفادهٔ سرویس وجود داشته باشد. بررسی کنید که ماژول tun بارگذاری شده و /dev/net/tun موجود است، چون نبودن دستگاه خرابی راه‌اندازی‌ای می‌سازد که هیچ ربطی به گواهی‌ها ندارد. همین برای اسکریپت‌های کمکی که DD-WRT برای مسیرها و DNS می‌سازد هم صادق است: اگر نباشند یا اجراشدنی نباشند، سرویس می‌تواند اجرا شود و باز هم تنظیم خود را تمام نکند.

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

سپس سرویس عادی را بازگردانید، چون سرویس پیش‌زمینه و اسکریپت init بر سر درگاه با هم کشمکش می‌کنند.

پیش از اشکال‌زدایی کارخواهان ثابت کنید شنونده وجود دارد

فرایند و سوکت را جداگانه تأیید کنید: یک فرمان برای سرویس در حال اجرا و دیگری برای درگاه UDP بسته‌شده روی نشانی مورد انتظار. فرایندی بدون سوکت یعنی هنوز در حال تنظیم است یا به رابط نادرست بسته شده. این جفت آزمون سودمندی است دقیقاً چون یک نیمه بدون نیمهٔ دیگر نمی‌تواند درست باشد.

اشکال‌زدایی سمت کارخواه فقط پس از وجود شنونده معنا دارد. آن‌گاه بررسی کنید که رمز و تنظیمات TLS کارخواه با فهرست data-ciphers سرور و کمینهٔ نسخهٔ آن می‌خواند و درگاه واقعاً به روتر فرستاده می‌شود.

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