آزمایش بازیابی سرور VPN پس از راه‌اندازی مجدد: ابتدا چه چیزی را بررسی کنیم

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

چهار مالک، چهار آزمون متفاوت

پیش از راه‌اندازی مجدد، مشخص کنید چه چیزی قرار است تونل را برگرداند. آزمونی که اجرا می‌کنید و اصلاحی که اعمال می‌کنید هر دو به آن پاسخ وابسته‌اند، و چهار مالک رایج وجود دارد: یک واحد systemd برای سرویس VPN، یک واحد نمونه wg-quick برای رابط WireGuard، یک runtime کانتینر، یا یک پروفایل مدیر شبکه. اگر نمی‌توانید مالک را نام ببرید، متوقف شوید و آن را پیدا کنید، زیرا آزمون راه‌اندازی مجدد بدون مسیر راه‌اندازی مورد انتظار فقط به شما می‌گوید که چیزی رخ داده است.

هر مالک پیکربندی خود را جای دیگری نگه می‌دارد. سرور OpenVPN که با systemd مدیریت می‌شود پیکربندی خود را هنگام شروع می‌خواند، پس هر چه در زمان بوت در فایل باشد همان اجرا می‌شود. رابط wg-quick نشانی‌ها، مسیرها و DNS خود را از همان فایل می‌گیرد، یعنی رابطی که دستی از یک پوسته بالا آورده شده و هرگز به‌عنوان واحد فعال نشده برنمی‌گردد. کانتینر نقطه ورود خود را برمی‌گرداند اما تغییرات فایروال میزبان را نه، مگر اینکه آن تغییرات بیرون از کانتینر باشند.

اول خط پایه، وگرنه نتیجه هیچ معنایی ندارد

وضعیت کارکرد را در حالی که کار می‌کند ثبت کنید: نشانی‌ها روی تونل، مسیرهای زیرشبکه کلاینت، قواعد NAT یا ارسال، سوکت شنود، و sysctl ارسال. ip addr show wg0، ip route، nft list ruleset یا iptables-save، ss -lunp و sysctl net.ipv4.ip_forward روی بیشتر میزبان‌ها کافی است.

ثبت کنید که سرویس چگونه برای شروع پیکربندی شده، نه فقط اینکه در حال اجراست. systemctl is-enabled wg-quick@wg0 و systemctl is-active wg-quick@wg0 به پرسش‌های متفاوتی پاسخ می‌دهند، و وضعیت فعال‌شده همان چیزی است که در زمان بوت اهمیت دارد، چنان‌که در systemctl(1) توضیح داده شده است. برای OpenVPN، بررسی کنید میزبان از کدام الگو استفاده می‌کند، زیرا openvpn@server و openvpn-server@server واحدهای متفاوتی با پیش‌فرض‌های متفاوت هستند.

راه‌اندازی مجدد را اجرا کنید و نخستین خطا را بخوانید

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

سرویس می‌تواند فعال باشد در حالی که تونل غیرقابل استفاده است، و این رایج‌ترین قبولی کاذب است. اگر واحد فقط منتظر network.target باشد نه network-online.target، راه‌اندازی می‌تواند پیش از آنلاین شدن شبکه کامل شود. فایل‌های ارجاع‌شده مانند گواهی‌ها، کلیدها یا یک CRL می‌توانند در آن لحظه ناخوانا باشند زیرا یک mount یا مسیر اسرار هنوز آماده نیست. هیچ‌یک از این دو مشکل در systemctl status دیده نمی‌شود تا زمانی که ژورنال واحد را بخوانید.

از بیرون میزبان آزمایش کنید. کلاینتی در همان LAN می‌تواند از مسیری موفق شود که هیچ کلاینت راه‌دوری هرگز استفاده نمی‌کرد، و یک نشست SSH به دستگاه چیزی درباره تونل اثبات نمی‌کند. متصل شوید، یک نام داخلی را باز کنید، به منبع خصوصی برسید، سپس یک بار دیگر متصل شوید تا تأیید کنید که وضعیت ابطال و کلیدها هنوز معتبرند.

سه شرطی که اصلاح شما را تعیین می‌کند

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

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

نتیجه را در runbook ثبت کنید

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

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