OpenVPN پس از خطای TLS مدام تلاش را تکرار می‌کند: چگونه متوقفش کنیم

کلاینت متصل می‌شود، در جریان مذاکرهٔ TLS شکست می‌خورد، صبر می‌کند و همان سرور را با همان نتیجه دوباره امتحان می‌کند. زیر نظر ناظری که فرایند شکست‌خورده را دوباره راه می‌اندازد، این تلاش‌ها به حلقه‌ای بی‌پایان در ژورنال تبدیل می‌شوند و نخستین سطر تشخیصی از دسترس خارج می‌شود. OpenVPN گزینه‌ای دارد که آن شکست مذاکره را به جای یک تلاش دیگر به خروجی دیدنی تبدیل می‌کند. این تنظیمی برای تشخیص و نظارت است، نه تعمیر، پس آن را با سیاستی جفت کنید که واقعاً بگذارد فرایند پایین بماند.

حلقه‌ای که نخستین خطا را پنهان می‌کند

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

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

پیش از تغییر هر چیزی، یک چرخهٔ کامل ثبت کنید. نشانی راه دور، مرحلهٔ TLS یادشده در خطا و اینکه آیا فرایند اصلاً خارج می‌شود را یادداشت کنید.

سازوکار تکرار در پسِ حلقه

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

گزینهٔ --tls-exit تنها حالت مذاکره را تغییر می‌دهد. راهنما آن را خروج در شکست مذاکرهٔ TLS توصیف می‌کند که باریک‌تر از خروج در هر خطاست. مهلت‌ها، شکست‌های مفسر و ردهای احراز هویت رفتار خودشان را نگه می‌دارند.

واداشتن کلاینت به خروج در شکست TLS

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

ناظر تصمیم می‌گیرد آن خروج دیدنی باشد یا نه. واحد systemd با Restart=always یا Restart=on-failure کلاینت را دوباره راه می‌اندازد، پس حلقه ادامه می‌یابد و گزینه به نظر می‌رسد کاری نمی‌کند. پیش از سرزنش کلاینت، سیاست را بررسی کنید:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no فرایند را پایین نگه می‌دارد، و Restart=on-failure پس از وضعیت غیرصفر همچنان دوباره راه می‌اندازد. اگر می‌خواهید شکست دیدنی باشد اما سرویس از فروپاشی‌های بی‌ربط بازیابی شود، Restart=on-failure را تنظیم کنید و برای توقف طوفان راه‌اندازی مجدد از StartLimitBurst و StartLimitIntervalSec بهره ببرید. سپس وضعیت واحد را بخوانید تا آخرین کد خروج را تأیید کنید: systemctl status آن را گزارش می‌کند و ژورنال نخستین خطا را بالای راه‌اندازی‌های مجدد نگه می‌دارد.

تصمیم را در واحد یا در یادداشت‌های پروفایل بنویسید. پروفایلی که در شکست TLS خارج می‌شود، اگر علت ثبت نشده باشد، برای نفر بعد شبیه یک حادثه به نظر می‌رسد. مشخص کنید کدام شکست‌ها باید فرایند را متوقف کنند و کدام‌ها باید تکرار شوند.

اثبات آن با یک نقطهٔ پایانی یک‌بارمصرف

برای دیدن این رفتار پیش از اعتماد به آن، پروفایل را کپی کنید و کپی را به نقطهٔ پایانی‌ای نشانه بگیرید که اتصال TCP را می‌پذیرد اما هرگز OpenVPN صحبت نمی‌کند. شنونده‌ای که پاسخ می‌دهد و سپس ساکت می‌ماند کافی است. با tls-exit کلاینت باید هنگام شکست دست‌دادن پایان یابد؛ بدون آن همان پروفایل باید به چرخش ادامه دهد. از کپی استفاده کنید، هرگز از پروفایل کاری.

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

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

مراحلی که این گزینه هرگز به آن‌ها نمی‌رسد

رد احراز هویت مرحله‌ای بعدی است. اگر سرور حساب را ارزیابی کند و ردش کند، TLS پیش‌تر مذاکره شده است، پس tls-exit عمل نمی‌کند. تنظیمات تکرار احراز هویت جای بعدی برای بررسی است و دلیل سرور از آخرین سطر کلاینت مهم‌تر است. گذرواژهٔ نادرست و گواهی ناموجود می‌توانند پیام‌های مشابه در سمت کلاینت بسازند.

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

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