چرا OpenVPN پس از بیدار شدن لپ‌تاپ می‌میرد؟

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

پیش از خودکارسازی، بیدار شدن را بازتولید کنید

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

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

قلاب خواب systemd در واقع کجا زندگی می‌کند

بسیاری از راهنماهای قدیمی به /etc/pm/sleep.d اشاره می‌کنند، پوشه‌ای که مالکش pm-utils است و خواب مبتنی بر systemd هرگز آن را مشورت نمی‌کند. systemd قلاب‌ها را از /usr/lib/systemd/system-sleep/ و /etc/systemd/system-sleep/ می‌خواند و نخست فاز و سپس عملیات را می‌فرستد، پس pre و post تنها مقادیری هستند که قلاب بر آن‌ها شاخه می‌زند. نسخه محلی را زیر /etc نگه دارید به‌جای ویرایش یک فایل بسته، و یادتان باشد اسکریپت در میانه گذار با دسترسی root اجرا می‌شود، پس باید سریع بازگردد.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart تنها وقتی به واحدی دست می‌زند که از پیش فعال باشد، پس تونلی که عمداً خاموش کرده‌اید در سراسر بیدار شدن خاموش می‌ماند. --no-block مانع می‌شود قلاب در حالی که کلاینت گفت‌وگو می‌کند منتظر بماند، و این وقتی مهم است که شبکه هنوز بالا نیامده. با هم، دو پرچم یعنی قلابی که بی‌صدا شکست می‌خورد به‌جای اینکه کل توالی بیدار شدن را نگه دارد. وقتی واحد از پیش متوقف است اصلاً هیچ اتفاقی نمی‌افتد، که دقیقاً همان نتیجه‌ای است که آنجا می‌خواهید.

سرویس را بازیابی کنید، tun0 را به حال خود بگذارید

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

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

زمان‌بندی‌ای را که کنترل نمی‌کنید مدیریت کنید

انجمن بی‌سیم و DHCP اغلب پس از اجرای قلاب تمام می‌شوند، پس راه‌اندازی دوباره ممکن است شکست بخورد در حالی که هنوز مسیری به سرور وجود ندارد. کمی برای آن نشانی صبر کنید، یک بار دیگر تلاش کنید و نتیجه را ثبت کنید.

تجزیه نام مسابقه‌ای جداست، چون پشته شبکه میزکار ممکن است DNS را پس از بالا آمدن تونل بازیابی کند. جست‌وجوها را جداگانه با resolvectl query internal.example بیازمایید به‌جای استنتاج از یک مسیر سالم. تونلی که درست مسیریابی می‌کند و چیزی را حل نمی‌کند مشکل DNS است، نه مشکل قلاب.

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