روتر یا رایانهٔ جداگانه به‌عنوان سرور VPN شما: چگونه انتخاب کنید
یک VPN میزبانی‌شده روی روتر یک ماشین را صرفه‌جویی می‌کند اما چرخهٔ راه‌اندازی مجدد آن را شریک می‌شود. پیش از انتخاب میزبان، مالکیت به‌روزرسانی‌ها، مسیرهای شبکهٔ خصوصی و بازیابی را مقایسه کنید.
هم روتر و هم یک رایانهٔ کوچک می‌توانند یک VPN را پایان دهند و تصمیم به‌ندرت به توان عملیاتی بستگی دارد. تصمیم به این بستگی دارد که ساعت دو بامداد چه کسی به‌روزرسانی را اعمال می‌کند، وقتی آن جعبه راه‌اندازی مجدد می‌شود چه چیز دیگری متوقف می‌شود، و آیا وقتی خود تونل خراب شده هنوز می‌توانید به یک کنسول برسید. به این سه پرسش برای هر نامزد پاسخ دهید و انتخاب معمولاً خودش را تحمیل می‌کند. رویهٔ زیر مقایسه را به فهرست کوتاهی از چیزهایی تبدیل می‌کند که می‌توانید پیش از تعهد بررسی کنید.
با آنچه باید هنگام شکست تونل برپا بماند شروع کنید
شکستی که باید برایش طراحی کرد همان است که در آن فرایند VPN می‌میرد و شما باز هم باید به میزبان برسید. روی روتر، تونل و دروازهٔ اینترنت یک سرنوشت دارند: یک تغییر پیکربندی بد می‌تواند هر دو را از کار بیندازد و مسیر بازیابی اغلب یک بازنشانی فیزیکی است. روی یک رایانهٔ جداگانه، دروازه به کار خود ادامه می‌دهد و میزبان همچنان از طریق LAN در دسترس است. کدام یک از این نتایج را می‌توانید تحمل کنید بیش از هر فهرست ویژگی تصمیم می‌گیرد.
پاسخ را به شکل یک جمله بنویسید: اگر میزبان VPN راه‌اندازی مجدد شود، خانه یا دفتر چه چیزی را از دست می‌دهد؟ اگر پاسخ شامل تمام دسترسی به اینترنت باشد، یک دامنهٔ خرابی مشترک را پذیرفته‌اید و باید آن را آگاهانه بگویید نه اینکه بعداً کشفش کنید.
سرویس دوم روی همان دستگاه یک کنسول یدکی نیست. منبع تغذیه، فرم‌ور و حساب مدیر را شریک می‌شود.
سطوح نگهداری‌ای را که هر میزبان اضافه می‌کند بشمارید
روتر فرم‌ور سازنده را با آهنگ انتشار خودش می‌آورد و ویژگی VPN معمولاً یک ماژول درون تصویری بسیار بزرگ‌تر است. رایانه یک سیستم‌عامل، یک مدیر بسته، یک هسته و مجموعه‌ای از سرویس‌ها می‌آورد که اکنون مالک آن هستید. هر دو نیاز به وصله دارند و پرسش واقعی این است که وقتی تازگی از بین رفت کدام آهنگ را نگه می‌دارید.
روی میزبان Linux آن آهنگ را به جای امیدوار بودن، قابل مشاهده کنید. systemctl list-timers کارهای زمان‌بندی‌شده را نشان می‌دهد و apt list --upgradable نشان می‌دهد چه چیزی در انتظار است. یادداشت کنید کدام به‌روزرسانی‌ها به راه‌اندازی مجدد نیاز دارند، زیرا میزبان VPNی که راه‌اندازی مجدد می‌شود یک قطعی است مگر اینکه برایش برنامه ریخته باشید. روتری که مسیر به‌روزرسانی خودکار ندارد به جای آن به یک ورودی تقویم نیاز دارد که کنترل ضعیف‌تری است اما صادقانه.
حساب‌ها را هم بشمارید. هر ورود اضافی مدیر روی میزبان VPN یک اعتبارنامهٔ دیگر برای چرخش و یک مسیر دیگر برای لغو است.
مسیر شبکهٔ خصوصی را دنبال کنید، نه برچسب روی جعبه را
کلاینت‌ها اهمیتی نمی‌دهند که سرور کجا اجرا می‌شود؛ برایشان مهم است که پیشوندهای محافظت‌شده در دسترس باشند و مسیر بازگشتی وجود داشته باشد. سرور را جایی بگذارید که مسیریابی ساده‌ترین است، که معمولاً یعنی مستقیماً روی بخشی که منابع را نگه می‌دارد. یک رایانهٔ پشت روتر همچنان به هدایت پورت نیاز دارد و منابع آن LAN همچنان به مسیری بازگشتی به زیرشبکهٔ تونل نیاز دارند.
پیش از سرزنش کلاینت، هدایت را روی میزبان بررسی کنید. sysctl net.ipv4.ip_forward باید 1 گزارش کند و nft list ruleset یا iptables -S نشان می‌دهد آیا رابط تونل اصلاً اجازهٔ هدایت دارد. یک قاعدهٔ masquerade غایب از سمت کلاینت دقیقاً مانند یک تونل خراب به نظر می‌رسد.
همچنین تعیین کنید تونل نباید به چه چیزی برسد. سروری که روی روتر قرار می‌گیرد هر زیرشبکه‌ای را که آن روتر مسیریابی می‌کند می‌بیند و این اغلب بیش از آن است که سیاست دسترسی در نظر دارد. روی یک میزبان جداگانه همان جداسازی به فاصلهٔ یک قاعدهٔ دیوار آتش است و شعاع آسیب یک کلاینت به‌خطرافتاده کوچک‌تر است. توصیف دروازهٔ IPsec در RFC 7296 این را مسئلهٔ مسیریابی و سیاست می‌داند، نه سخت‌افزار، و هیچ‌یک از این دو شکل به‌طور پیش‌فرض ایمن‌تر نیست تا زمانی که سیاست نوشته شود.
کنسولی برای بازیابی نگه دارید که به تونل وابسته نیست
کنسولی که با آن VPN را تعمیر می‌کنید نمی‌تواند خود VPN باشد. یک نشانی LAN، یک کنسول سریال یا یک کنسول ارائه‌دهنده نگه دارید که وقتی تونل قطع است کار می‌کند و دست‌کم یک بار پیش از نیاز به آن از آن استفاده کنید. مسیر خارج از باندی که هرگز تمرین نشده باشد یک طرح است نه یک توانایی.
از پیکربندی نسخهٔ پشتیبان در جایی بگیرید که خود میزبان نتواند پاکش کند. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn کلیدها و تعریف‌های سرویس را می‌گیرد و نسخهٔ کپی باید از ماشین خارج شود. قواعد دیوار آتش و فهرست کلاینت‌ها را هم بگنجانید، زیرا بازیابی کلیدها بدون فهرست همتاها سروری می‌سازد که هیچ‌کس نمی‌تواند به آن بپیوندد. بایگانی را جایی نگه دارید که کنسول بازیابی به آن برسد.
گام بازگردانی را در همان یادداشت بنویسید. تغییر پیکربندی بدون بازگشت مستند یک تغییر دائمی است، هر قصدی که بوده باشد.
انتخاب را با یک راه‌اندازی مجدد و یک به‌روزرسانی تأیید کنید
آرایش را همان‌گونه که خراب می‌شود بیازمایید، نه آن‌گونه که در یک روز خوب کار می‌کند. میزبان را راه‌اندازی مجدد کنید، یک به‌روزرسانی در انتظار را اعمال کنید و تأیید کنید تونل بدون گام‌های دستی بازمی‌گردد.
پس از راه‌اندازی مجدد، سه چیزی را بررسی کنید که بیشتر از همه می‌شکنند. systemctl is-active wg-quick@wg0 گزارش می‌دهد آیا رابط برگشته است، ss -lunp نشان می‌دهد آیا چیزی به پورت گوش می‌دهد و wg show همتایی با دست‌دهی کامل را فهرست می‌کند. سرویسی که فعال است اما دست‌دهی ندارد یعنی دیوار آتش یا مسیر اشتباه است، نه دیمن.
بررسی را از یک کلاینت در شبکه‌ای متفاوت از شبکه‌ای که از آن پیکربندی کردید تکرار کنید. اگر تونل از راه‌اندازی مجدد، به‌روزرسانی و تغییر شبکهٔ کلاینت جان سالم به در ببرد، انتخاب میزبان فعلاً روشن است. اگر نه، قطعهٔ گم‌شده معمولاً یک گام مستند است نه یک جعبهٔ دیگر.