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

نسخه پشتیبان فایل برمی‌گرداند، نه اختیار

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

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

هویت سرور و هویت کلاینت به دو شکل متفاوت شکست می‌خورند

در WireGuard هویت سرور همان کلید خصوصی در wg0.conf است، پس کپی کردن آن فایل روی میزبان دوم در دسترس، دو سرور با هویت یکسان و بی‌خبر از هم می‌سازد. هرکدام فهرست همتایان خود را نگه می‌دارد. همتایی را روی میزبان جدید حذف کنید و قدیمی همچنان می‌پذیردش؛ wg show را روی یکی بررسی کنید و نیمی از حقیقت را می‌بینید. کلاینت‌ها هم خودشان جابه‌جا نمی‌شوند: پروفایل یک Endpoint دارد، پس دستگاه همچنان با نشانی‌ای صحبت می‌کند که برای آن پیکربندی شده بود، که ممکن است همان میزبانی باشد که می‌خواستید بازنشسته کنید.

OpenVPN در همان لایه با گواهی سرور، کلید خصوصی آن و کلید ایستای tls-auth یا tls-crypt تکرار می‌شود. هر سه را کپی کنید و کلاینت نمی‌تواند نمونه‌ها را از هم تشخیص دهد؛ اگر هر دو در دسترس باشند، اتصال دوباره ممکن است روی هرکدام بیفتد، و هر فایل گزارش داستانی ناقص تعریف می‌کند. مرجع صدور گواهی نسخه عمیق‌تر است. درخت easy-rsa بازیابی‌شده منبع دوم حقیقت است که می‌تواند برای هر نامی که به آن بدهید گواهی معتبر صادر کند.

کلاینت‌ها هم تکرار می‌شوند، معمولاً در خود مهاجرت. کپی کردن یک پروفایل روی دستگاه یدکی «فقط برای آزمایش» دستگاه دومی با همان کلید و همان نام مشترک می‌سازد. با duplicate-cn هر دو نشست می‌توانند همزمان برپا بمانند، و تخصیص نشانی ایستا در ccd یا ifconfig-pool-persist می‌تواند با دستگاه اصلی تداخل کند. این دو ماشین با یک هویت است، و هیچ چیز در پیکربندی سرور آن‌ها را از هم جدا نمی‌کند.

برای نقطه پایانی قدیمی یکی از سه وضعیت را انتخاب کنید

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

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

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

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

فهرست کنید بازیابی چه ادعایی دارد در برابر آنچه اکنون مجاز است. در WireGuard، wg show wg0 کلید، نقطه پایانی، آخرین دست‌دهی و شمارنده‌های انتقال هر همتا را می‌دهد، که برای یافتن دستگاهی که دیگر مالکش نیستید کافی است. آن را به‌صورت زنده با wg set wg0 peer <key> remove حذف کنید، سپس پیکربندی را هم ویرایش کنید، وگرنه همتا در آغاز بعدی برمی‌گردد. wg show wg0 allowed-ips مشکل دوم را آشکار می‌کند: دو همتا روی یک نشانی، یا نشانی‌ای که پیش‌تر بازتخصیص داده‌اید.

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

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

اگر آخرین به‌روزرسانی پیش از ابطال باشد، سرور هنوز گواهی‌ای را که ابطال کرده‌اید محترم می‌شمارد. OpenVPN 2.4 و بعد از آن فایل CRL را برای هر اتصال جدید دوباره می‌خوانند، پس جایگزینی فایل نشست‌های جدید را متوقف می‌کند، اما تونل‌های برقرار تا بازمذاکره باقی می‌مانند؛ پیش‌فرض reneg-sec 3600 ثانیه است، و کم کردن آن یا راه‌اندازی دوباره سرویس همان چیزی است که تغییر را همین حالا به شما می‌دهد. نسخه‌های قدیمی‌تر ممکن است فایل را به این اتکاپذیری برنگیرند، پس وقتی نمی‌توانید رفتار آن نسخه را تأیید کنید دوباره راه‌اندازی کنید. راهنمای wg(8) حذف همتا و نحو allowed-ips استفاده‌شده در بالا را پوشش می‌دهد.

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

با کلاینتی که ابطال کرده‌اید بررسی کنید

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

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

مقالات مرتبط