تغییر ارائه‌دهنده VPN: نام میزبان را برنامه‌ریزی کنید، نه فقط IP را
یک رکورد DNS جدید نشست‌های موجود را جابه‌جا نمی‌کند. برنامه‌ریزی کنید چه کسی نام را کنترل می‌کند، هر کلاینت چه زمانی آن را حل می‌کند و نقطه پایانی قدیمی را چگونه بازنشسته می‌کنید.
رکورد DNS شما درست است، جایگزین سالم است، و با این حال برخی کلاینت‌ها ساعت‌ها نشانی قدیمی را شماره‌گیری می‌کنند. چند مورد بلافاصله در برابر نامی که حل می‌شود و هرگز پاسخ نمی‌دهد شکست می‌خورند. هر دو نتیجه از یک شکاف می‌آیند: نام میزبان تغییر می‌دهد که کلاینت چه چیزی را جست‌وجو می‌کند، نه زمانی که آن را جست‌وجو می‌کند، و نه چیزی که وقتی پاسخ می‌رسد به آن اعتماد می‌کند.
نشانه: رکورد درست، تونل‌های کهنه
پروفایلی که یک نام را ذخیره می‌کند کلاینتی نیست که مدام آن را حل کند. بیشتر کلاینت‌ها یک بار آن را حل می‌کنند، هنگام اعمال پیکربندی یا وقتی تونل بالا می‌آید، و سپس تا پایان نشست از همان نشانی استفاده می‌کنند. یک TTL طولانی روی آن دلیل آن است که تغییر باید حول اتصال‌های مجدد برنامه‌ریزی شود، نه حول ویرایش DNS.
هیچ‌کدام از این دو رفتار نقص نیست، و همین نشانه را گیج‌کننده می‌کند. کلاینت با پاسخی کار می‌کند که پیش‌تر گرفته است، و هیچ چیز در سمت سرور نشان نمی‌دهد آن پاسخ کدام بوده است. اتصال مجدد را در پنجره نگهداری بگنجانید و به کاربران بگویید چه خواهند دید، یا پنجره را صرف پاسخ دادن به تیکت‌ها کنید. صف گزارش‌های یکسان نتیجه معمول است.
چه کسی نام را کنترل می‌کند و کلاینت چه چیزی را تأیید می‌کند
کنترل ناحیه تعیین می‌کند که مهاجرت چقدر سریع می‌تواند پیش برود. رکورد را نزد ثبت‌کننده‌ای نگه دارید که می‌توانید واردش شوید، و بنویسید چه کس دیگری می‌تواند آن را تغییر دهد.
اعتماد از نام پیروی نمی‌کند. کلاینت مبتنی بر TLS ممکن است هویت گواهی یا نامی سنجاق‌شده را بررسی کند، در حالی که WireGuard کلید عمومی همتا را احراز می‌کند و نام میزبان را کاملاً نادیده می‌گیرد. همین تفاوت تعیین می‌کند که آیا ویرایش DNS کافی است یا هر پروفایل به اثر انگشت تازه نیاز دارد. تغییر رکورد هرگز نباید نقطه پایانی را مجاز کند که کسی آن را تأیید نکرده است.
دسترسی مدیریتی و بازیابی را از نام عمومی کلاینت دور نگه دارید. از دست دادن حساب میزبانی نباید رکوردی را هم از شما بگیرد که کلاینت‌ها را هدایت می‌کند. مسیر بازیابی را جایی ذخیره کنید که به ارائه‌دهنده‌ای که ترک می‌کنید وابسته نباشد.
هر کلاینت چه زمانی نام را دوباره می‌خواند
زمان حل، ویژگی هر کلاینت است، پس پیش از وعده دادن یک پنجره تغییر، پیاده‌سازی‌ای را که واقعاً توزیع می‌کنید بررسی کنید. wg-quick نقطه پایانی را هنگام بالا آمدن رابط حل می‌کند و آن نشانی را تا راه‌اندازی مجدد تونل نگه می‌دارد. کلاینت OpenVPN هنگام اتصال نام را جست‌وجو می‌کند، و اینکه هنگام اتصال مجدد دوباره نگاه کند یا نه به گزینه‌هایش بستگی دارد.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
کلاینت‌های موبایل غافلگیری معمول‌اند، چون ممکن است نشانی حل‌شده را در خواب یا تغییر شبکه نگه دارند. رکوردهای A و AAAA را فقط وقتی منتشر کنید که جایگزین در هر دو خانواده پاسخ دهد. نشانی‌ای که در یک خانواده پاسخ می‌دهد چیزی درباره دیگری اثبات نمی‌کند، و رکورد AAAA مرده به هر تلاش یک مهلت اضافه می‌کند. رفتار حل را برای هر کلاینتی که پشتیبانی می‌کنید مستند کنید، سپس روی دستگاه‌هایی که مردم واقعاً استفاده می‌کنند آزمایش کنید.
اتصال مجدد در بیشتر کلاینت‌ها اقدامی از سوی کاربر است و سرور نمی‌تواند آن را تحمیل کند. آن مرحله را در یادداشت نگهداری بنویسید، با خطی درباره آنچه کاربر هنگام وقوع خواهد دید.
بر پایه شواهد تغییر دهید، سپس نقطه پایانی قدیمی را بازنشسته کنید
پیش از تغییر، هر لایه را در جایگزین اثبات کنید: شنونده پاسخ می‌دهد، دیوار آتش پورت را عبور می‌دهد، مسیرها درست برمی‌گردند، نام به نشانی جدید حل می‌شود و هویتی شناخته‌شده پذیرفته می‌شود. شنونده‌ای که اتصال را می‌پذیرد با شنونده‌ای که دست‌دهی را کامل می‌کند یکی نیست، پس دست‌دهی را آزمایش کنید نه پورت را. فهرست ابطال فعلی را کنار پیکربندی نگه دارید، چون نسخه پشتیبان بازیابی‌شده فهرست همتا را همان‌طور که بود بازمی‌سازد و دسترسی‌ای را که قبلاً بسته‌اید دوباره باز می‌کند. ثبت کنید با کدام هویت آزمایش کردید، چون «کار می‌کند» شاهدی نیست که کسی بتواند تکرارش کند.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesدر طول گذار، تلاش‌های اتصال را در هر دو نقطه پایانی برای همان هویت زیر نظر بگیرید. کلاینتی که هنوز خود را در برابر نشانی قدیمی احراز می‌کند، پروفایل یا پاسخی ذخیره‌شده است که هرگز جابه‌جا نشده. نقطه پایانی قدیمی را بر اساس برنامه‌ای تاریخ‌دار بازنشسته کنید، چون دو سرویس که یک هویت را می‌پذیرند دو در را باز می‌گذارند.
آزمون تغییر یک نشست برنامه از طریق نقطه پایانی جدید است، نه ping. وقتی آن نشست کار کند و نقطه پایانی قدیمی در یک چرخه کامل اتصال مجدد هیچ تلاش مجازی ثبت نکند، جابه‌جایی تمام شده است.