چرا کلاینت OpenVPN شما پس از یک بار پایان مهلت خاموش می‌ماند
کلاینتی که در نخستین پایان مهلت خارج می‌شود، میزبانی بر جای می‌گذارد که آنلاین به نظر می‌رسد و چیزی حمل نمی‌کند. گزینه پروفایل و سیاست راه‌اندازی مجدد را جداگانه اصلاح کنید.
دوشنبه صبح: تونلی که جمعه بالا آمده بود رفته است، رابط هنوز فهرست شده، و هیچ چیز در ژورنال نمی‌گوید کسی متوجه شده است. میزبان آنلاین است، داشبورد سبز است، و هر چه آخر هفته فرستاده از رابط فیزیکی بیرون رفته است. اینجا دو تصمیم مستقل غایب است: یکی درباره اینکه آیا فرایند کلاینت از یک خطای گذرا جان سالم به در می‌برد و دیگری درباره اینکه آیا چیزی بالاتر از آن فرایند را پس از خروج دوباره راه می‌اندازد. اصلاح تنها یکی، شکاف دیگر را باز می‌گذارد.
از آنچه یونیت واقعاً انجام داده شروع کنید، نه از آنچه پایش ادعا می‌کند. systemctl status openvpn-client@office و journalctl -u openvpn-client@office -n 50 دلیل خروج و آخرین خطی را که کلاینت پیش از رفتن نوشته نشان می‌دهند.
فرایند پیش از آنکه کسی متوجه شود خارج شد
کلاینتی که بی‌خطا ناپدید می‌شود معمولاً عمداً خارج شده است. پروفایل این رفتار را تعیین می‌کند، نه مدیر سرویس: ping-exit فرایند را به محض اینکه طرف مقابل از پاسخ دادن باز می‌ایستد پایان می‌دهد، در حالی که ping-restart فرایند را نگه می‌دارد و درون آن دوباره متصل می‌شود. محدودیت‌های نشست و تایمرهای بی‌فعالیتی از بیرون همان تصویر را می‌سازند: بی‌تونل و بی‌هشدار.
دو directive پینگ نمی‌توانند همزمان در یک پروفایل باشند، پس یکی را انتخاب کنید و انتخاب را ثبت کنید. به سرور هم نگاه کنید، چون ping-exit خودش نشست را می‌بندد هر چه کلاینت خواسته باشد، و تنها ژورنال سرور ثبت می‌کند چه کسی این تصمیم را گرفته است.
انتخاب میان ping-exit و ping-restart
برای لپ‌تاپ یا سایت دوردستی که باید خودش را درمان کند ping-restart را انتخاب کنید، و ping-exit را برای مواردی نگه دارید که تونل مرده باید فرایند را متوقف کند تا چیز دیگری بتواند به آن واکنش دهد. اعداد کمتر از رابطه مهم‌اند: ping 10 با ping-restart 60 یعنی ده ثانیه سکوت پیش از یک کاوش و شصت ثانیه پیش از راه‌اندازی مجدد، که در پیوند موبایل دارای افت تهاجمی و در پیوند سیمی معقول است. دلیل را کنار خط بنویسید، وگرنه خواننده بعدی فرض می‌کند مقادیر پیش‌فرض عمدی بوده‌اند.
سپس تأیید کنید که واقعاً همان فرایند خارج شده است. یونیتی که در حالی که تونل مرده است فعال گزارش می‌دهد، خرابی دیگری است که پایین‌تر بررسی می‌شود.
نظارتی که واقعاً یونیت را دوباره راه می‌اندازد
روی میزبان systemd کوچک‌ترین تغییر پایدار یک فایل drop-in است: Restart=on-failure و RestartSec=10 در /etc/systemd/system/[email protected]/restart.conf. فایل drop-in تنها زمانی خوانده می‌شود که systemd تعاریف خودش را دوباره بارگذاری کند، پس پس از آن systemctl daemon-reload را اجرا کنید. به جای فرض اینکه مقدار رسیده، با systemctl show -p Restart -p ExecMainStatus openvpn-client@office بررسی کنید. نمونه در نام فایل باید همان پروفایلی باشد که یونیت واقعاً بارگذاری می‌کند، پس فایلی که برای office نوشته شده برای openvpn-client@home هیچ کاری نمی‌کند.
on-failure یک حالت را نادیده می‌گیرد: خروج پاک با وضعیت صفر. بعضی مسیرهای برچیدن این‌گونه پایان می‌یابند، پس وضعیت ثبت‌شده را بخوانید نه اینکه به عبارت یک صفحه راهنما اعتماد کنید. اگر کلاینت شما با صفر تسلیم شود، به Restart=always نیاز دارید، و هزینه‌اش این است که پروفایل واقعاً خراب مدام برمی‌گردد تا حد نرخ شروع فعال شود و ژورنال پر شود.
Restart=always پس از توقف عمدی هم فعال می‌شود. برای نگهداری از systemctl stop استفاده کنید، و اگر یونیت باید در حین کار شما پایین بماند آن را ماسک کنید.
نشت را وقتی تونل پایین است بگیرید
نظارت تونل را برمی‌گرداند؛ اما مانع خروج ترافیک در زمانی که تونل نیست نمی‌شود. persist-tun دستگاه و مسیرهایش را در میان اتصال‌های دوباره نگه می‌دارد، که راحت است و پنجره‌ای باز می‌کند. دستگاه می‌ماند، مسیرها هنوز به آن اشاره می‌کنند، و بسته‌ها بی‌حفاظت و بی‌گزارش بیرون می‌روند. این یک انتخاب سیاستی است، نه یک پیش‌فرض خنثی.
وقتی میزبانی به هیچ روی نباید بسته بی‌حفاظت بفرستد، تنها دیوار آتش می‌تواند آن را تضمین کند. قاعده خروجی‌ای که رابط تونل و نشانی سرور VPN را مجاز می‌داند و همه‌چیز دیگر را دور می‌ریزد، پس از مرگ کلاینت هم برقرار می‌ماند، و هیچ چیز در پیکربندی خود کلاینت نمی‌تواند ترافیکی را که کلاینت حمل نمی‌کند فیلتر کند.
با متوقف کردن عمدی کلاینت آن را بیازمایید. systemctl stop openvpn-client@office و سپس curl -m 5 https://example.com را اجرا کنید، که باید از راه پیوند فیزیکی شکست بخورد نه موفق شود. موفقیت یعنی قاعده دیوار آتش غایب است یا بیش از حد مجاز.
دوباره وصل شوید، تأیید کنید که تونل دوباره ترافیک حمل می‌کند، و تنها پس از آن بررسی را به پایش اضافه کنید. پرس‌وجوی ip addr از cron برای دستگاه tun نظارتی است که بیشتر از همه شکست می‌خورد، چون با persist-tun دستگاه بیش از نشست زنده می‌ماند و کاوشگر در حالی که چیزی حمل نمی‌شود سلامت گزارش می‌دهد.