انتقال یک سرور VPN به IP عمومی جدید: نخست چه چیزی را بررسی کنیم
جایگزینی در محل و انتقال موازی در جاهای متفاوتی می‌شکنند. تنظیمات، NAT و گواهی‌ها را بررسی کنید، سپس ببینید هر کلاینت نام را چگونه حل می‌کند.
تخصیص دوباره یک نشانی یک دقیقه طول می‌کشد. هفته پس از آن جایی است که انتقال می‌شکند، و به‌ندرت جایی که کنسول ارائه‌دهنده پیشنهاد می‌کند. نشانی IP عمومی جدید در چهار جا ارجاع می‌شود: سوکتی که دیمن روی آن گوش می‌دهد، لنگر اعتمادی که کلاینت‌ها بررسی می‌کنند، هر قاعده‌ای که نشانی قدیمی را نام می‌برد، و رکورد DNS که آن‌ها را به هم می‌بندد. دو انتقال از یک پنل کنترل یکسان به نظر می‌رسند اما رفتاری کاملاً متفاوت دارند: تخصیص دوباره نشانی روی ماشینی که خودتان اداره می‌کنید، یا برپا کردن نقطه پایانی دوم و انتقال کلاینت‌ها به آن. بررسی‌های زیر شکست‌های ارزان را اول می‌گذارند، و هر بخش می‌گوید به کدام انتقال مربوط است.
جایگزینی در محل و انتقال موازی کارهای متفاوتی هستند
جایگزینی در محل میزبان، کلیدها، جدول مسیریابی و فهرست کاربران را نگه می‌دارد؛ فقط نشانی تغییر می‌کند. این کاری است که تخصیص دوباره IP شناور انجام می‌دهد، و در چند ارائه‌دهنده مهمان هرگز متوجه نمی‌شود، چون ترجمه جلوی نمونه انجام می‌شود. بازسازی یا تخصیص دوباره توسط ارائه‌دهنده خشن‌تر است: مهمان تغییر را می‌بیند، و هر چیزی که مقدار قدیمی را در حافظه پنهان داشت، همان لحظه آن را می‌آموزد.
نقطه پایانی موازی میزبان دومی است که همان کار را انجام می‌دهد. آن را بسازید، با یک پروفایل آزمایش کنید، و بگذارید قدیمی پاسخ دهد تا جدید در مسیری واقعی خودش را ثابت کند. بها وضعیت است. بدون ورودی‌های peer مشترک، ابطال‌ها و ثبت گزارش، دو شبکه دارید که تصادفاً یک نام را هم‌رسانی می‌کنند.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
هر جایی که نشانی قدیمی نوشته شده را پیدا کنید
با جست‌وجوی متنی شروع کنید، چون فایل‌های تنظیمات نیمه آسان ماجرا هستند. تنظیمات دیمن، تکه‌های دیوار آتش، هدف‌های پایش و هر بستهٔ کلاینت تولیدشده روی دیسک را جست‌وجو کنید. اگر نشانی IPv6 منتشر می‌کنید آن را هم بگنجانید؛ انتقالی که فقط رکورد A را دنبال می‌کند کلاینت‌های دوپشته را روی مسیر قدیمی جا می‌گذارد.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsسپس کرنل را جست‌وجو کنید، چون سامانهٔ در حال اجرا نشانی را در جاهایی نگه می‌دارد که هیچ فایلی از آن‌ها نام نمی‌برد. یک قاعدهٔ NAT مبدأ ایستا، یک ورودی ipset، یک نشانی bind و یک ورودی conntrack از ویرایش تنظیماتی که آن‌ها را حذف کرد عمر بیشتری می‌کنند، و برخی از یک راه‌اندازی دوباره هم جان به در می‌برند چون از مجموعه قواعد ذخیره‌شده بازگشته‌اند. یک لایه بالاتر، گروه‌های امنیتی ارائه‌دهنده، هدف‌های متعادل‌کننده بار و بررسی‌های پایش اصلاً روی فایل‌سیستم شما نیستند.
پیش از تغییر هر چیزی فهرست موجودی را بنویسید؛ همان حکم اسکریپت بازگشت را هم دارد.
کلاینت‌های نام میزبان بهبود می‌یابند؛ کلاینت‌های IP حرفی ساکت می‌شوند
اگر کلاینت‌ها با نام میزبان به سرور می‌رسند، انتقال بیشتر یک مسئلهٔ DNS است، و TTLی که دیروز گذاشتید تعیین می‌کند چقدر بد شود. حل‌کننده‌ها حافظه پنهان می‌کنند، حل‌کننده‌های stub دوباره کش می‌کنند، و بسیاری از کلاینت‌ها نام را فقط در اتصال جدید جست‌وجو می‌کنند، بنابراین یک تونل برقرارشده نشانی آغازین خود را نگه می‌دارد.
اگر نقطه پایانی یک نشانی حرفی باشد، چیزی دوباره حل نمی‌شود و چیزی شکایتی ثبت نمی‌کند. WireGuard نشانی سوکت حل‌شده را ذخیره می‌کند: Endpoint = vpn.example.net:51820 همان لحظه‌ای که wg-quick up اجرا می‌شود IP می‌شود و تا وقتی آن را تغییر دهید همان IP می‌ماند. OpenVPN بخشنده‌تر است: نام میزبان remote را هنگام اتصال حل می‌کند و با resolv-retry infinite هنگام اتصال دوباره DNS را دوباره امتحان می‌کند. با یک IP حرفی، هر دو به ماشینی زنگ می‌زنند که دیگر وجود ندارد.
چیزی که مردم را گمراه می‌کند تصویر آینه‌ای است. کلاینتی که از قبل به نشانی جدید اشاره می‌کند، در حالی که شنوندهٔ قدیمی هنوز پاسخ می‌دهد، هر آزمونی را که از میز خودتان اجرا کنید می‌گذراند. من خودم با این فریب خورده‌ام: نقطه پایانی جدید در یک تلفن با نخستین تلاش بالا آمد، و کلاینتی با پروفایل کهنه فقط زمانی پیدا شد که شنوندهٔ قدیمی خیلی دیرتر خاموش شد.
اعتماد با نشانی جابه‌جا نمی‌شود
WireGuard هویت را از دسترس‌پذیری جدا می‌کند، که جابه‌جایی نشانی را تقریباً بی‌هزینه می‌کند. peerها با کلید عمومی شناسایی می‌شوند، و نقطه پایانی فقط جایی است که بسته‌ها اکنون به آن می‌روند؛ میزبان نقطه پایانی یک peer را از نشانی مبدأ آخرین بستهٔ احرازشده به‌روز می‌کند. peer بی‌کار هنوز دلیلی برای صحبت با مکان جدید لازم دارد، و نشانی را تنها زمانی می‌آموزد که نشستش کهنه شود و تلاش‌های دوبارهٔ handshake جایی دیدنی شکست بخورند. راهنمای سریع WireGuard میدان نقطه پایانی را پوشش می‌دهد.
سرورهای مبتنی بر TLS حالت مقابل هستند. گواهی به یک نام گره خورده است، و کلاینتی که نشانی را می‌گیرد آنچه گرفته را با نام‌های جایگزین موضوع مقایسه می‌کند. با IP به گواهی‌ای وصل شوید که فقط یک SAN از نوع DNS دارد و بررسی شکست می‌خورد: نامی که کلاینت به کار برده در گواهی نیست. صدور دوباره با SAN از نوع IP همان یک اتصال را درست می‌کند و انتقال بعدی را بدتر می‌کند. نگه داشتن نام میزبان در پروفایل و گذاشتن verify-x509-name سر جایش بررسی را سخت‌گیر نگه می‌دارد در حالی که نشانی زیر آن تغییر می‌کند.
سپس بررسی کنید دیمن به چه چیزی گره خورده است؛ سوکتی که به نشانی قدیمی سنجاق شده بی‌صدا شکست می‌خورد. سرور OpenVPN که با local 203.0.113.10 آغاز شده وقتی آن نشانی برود از بالا آمدن امتناع می‌کند، در حالی که شنونده‌ای روی 0.0.0.0 تغییر را مجانی دنبال می‌کند. NAT هم همین‌طور تقسیم می‌شود: MASQUERADE هر نشانی‌ای که ماشین اکنون دارد را دنبال می‌کند، و SNAT --to-source 203.0.113.10 ایستا همچنان به نشانی‌ای بازنویسی می‌کند که دیگر مالک آن نیستید، پس ترافیک بازگشتی ناپدید می‌شود. اگر نشانی جدید با دروازهٔ upstream متفاوتی بیاید، rp_filter را بررسی کنید: فیلترکردن مسیر معکوس ترافیک بازگشتی‌ای را که به رابطی می‌رسد که کرنل انتظارش را نداشت دور می‌ریزد.
ترتیب انتقال و شواهد اینکه کار کرد
یک روز زودتر TTL را پایین بیاورید، شنوندهٔ جدید را برپا کنید، و آن را با پروفایلی که فقط شما دارید ثابت کنید. آزمون از داخل همان شبکه تقریباً هیچ چیز را ثابت نمی‌کند، پس از تلفنی روی شبکهٔ همراه استفاده کنید و چیزی را بیازمایید که تونل باید حمل کند نه پینگ به نقطه پایانی.
در تمام بازه هر دو نشانی را بپایید. wg show all latest-handshakes روی میزبان جدید، یا فایل وضعیت OpenVPN، می‌گوید چند peer واقعاً جابه‌جا شده‌اند. وقتی نقطه پایانی جدید peerهای مورد انتظار را دارد و قدیمی فقط عقب‌مانده‌ها را، شنوندهٔ قدیمی را بازنشسته کنید، قاعدهٔ NAT کهنه را بردارید و نشانی را از دیوار آتش ارائه‌دهنده حذف کنید. برداشتن شنوندهٔ قدیمی همان مرحله‌ای است که جا می‌افتد، و شکافی را می‌بندد که در آن پروفایل کهنه هنوز به شبکهٔ قدیمی می‌رسد.
محرک بازگشت را پیش از شروع به‌صورت نوشتاری تعیین کنید: اگر نقطه پایانی جدید پس از بازهٔ توافق‌شده از هیچ کلاینت واقعی handshake نگیرد، نشانی قدیمی را بازگردانید و توزیع پروفایل‌ها را متوقف کنید. سپس جست‌وجو را دوباره اجرا کنید و تأیید کنید هیچ شنونده‌ای هنوز به نشانی بازنشسته گره نخورده است. دو چیز به انتقال بعدی می‌رسد: یک نام میزبان در پروفایل کلاینت تا تغییر بعدی ویرایش DNS باشد، و فهرست موجودی که کنار یادداشت‌های بازیابی سرور نگهداری می‌شود.