P_CONTROL_HARD_RESET_CLIENT_V2 در گزارش: آیا خطاست؟

این خط هر چند ثانیه تکرار می‌شود و علت همه چیز به نظر می‌رسد: بسته‌ای به نام control hard reset که از کلاینتی می‌آید که هرگز به جایی نمی‌رسد. این خطا نیست. این نخستین پیام یک نشست تازه است و تکرار، نشانهٔ چیز دیگری است که جلوتر شکست می‌خورد. جدا کردن آنچه برچسب می‌گوید از آنچه اتصال پس از آن انجام داد، تمام تشخیص است.

کد عملیات جایگاهی در پروتکل را نام می‌برد

OpenVPN چند نوع بسته را روی یک سوکت چندگانه می‌کند و کد عملیات به گیرنده می‌گوید کدام نوع را در دست دارد. بسته‌های hard-reset نشست را باز می‌کنند، بسته‌های کنترل مواد دست‌دهی را حمل می‌کنند، تأییدها دریافت را تأیید می‌کنند و بسته‌های داده بار تونل را حمل می‌کنند. خواندن نخستین بایت نشان می‌دهد بسته در کجای این تبادل قرار دارد و تعریف‌های بسته در کد منبع هر خانواده را صریح نام می‌برند.

همین است تمام چیزی که می‌گوید. بسته‌ای که به‌عنوان ریست آغازین کلاینت برچسب خورده ثابت می‌کند بسته به نقطهٔ مشاهدهٔ شما رسیده و همتا می‌خواهد نشستی آغاز کند. ثابت نمی‌کند که کلاینت به گواهی شما اعتماد کرده، اعتبارنامه‌اش پذیرفته شده یا کانال داده هرگز قابل استفاده شده است.

پسوند V2 نشانگر نسل پروتکل برای همین خانوادهٔ بسته است، نه نسخهٔ محصول و نه تنظیمی که نصب می‌کنید. هیچ چیز در این نام به ریست کردن تونل، راه‌اندازی دوبارهٔ سرویس یا پاک کردن حافظهٔ نهان اشاره ندارد.

کلاینت در آن لحظه واقعاً چه می‌کند

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

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

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

خطای واقعی پس از ریست کجا پنهان می‌شود

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

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

اگر هیچ طرفی رد شدن را گزارش نکند و تبادل باز هم متوقف بماند، مرز دسترسی‌پذیری است نه اعتماد. دیوار آتشینی که جهت بازگشت را می‌اندازد، دستگاه ترجمهٔ نشانی شبکه‌ای که نگاشتش منقضی می‌شود، یا مشکل MTU که بسته‌های بزرگ‌تر دست‌دهی را از بین می‌برد، همه تبادلی متوقف می‌سازند بی‌آنکه هیچ خطای احراز هویتی باشد.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

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

چرا خاموش کردن بررسی، واکنش اشتباه است

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

در عوض همان مرزی را تغییر دهید که واقعاً شکست خورده است. مشکل اعتماد به مرجع صدور گواهی و نمایه‌ای تعلق دارد که به آن ارجاع می‌دهد. مشکل زمان به ساعت تعلق دارد. مشکل اعتبارنامه به سامانهٔ پشتیبان احراز هویتی تعلق دارد که آن را رد کرده، و همتای دسترسی‌ناپذیر به مسیر میان دو میزبان تعلق دارد.

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