تغییر ارائه‌دهنده بدون شماره‌گذاری مجدد نشانی‌های VPN سایت

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

دو طرح نشانی که مستقل از هم حرکت می‌کنند

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

تغییر ارائه‌دهنده طرح بیرونی را لمس می‌کند. خودبه‌خود نیازی به تغییر طرح درونی ندارد.

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

تونل بیرونی گفت‌وگوی درونی را حمل می‌کند

در تونل دروازه به دروازه، سرآیند IP بیرونی دو دروازه را نشانی‌دهی می‌کند. سرآیند درونی همچنان نقاط پایانی واقعی برنامه را نام می‌برد. توصیف دروازه به دروازه در RFC 7296 این را مسیریابی عادی می‌داند که ترافیک را از طریق نقاط پایانی تونل تحویل می‌دهد.

به همین دلیل سرور شعبه می‌تواند 10.55.8.20 را نگه دارد در حالی که نشانی عمومی دروازه تغییر می‌کند. بسته درونی اصلاً نشانی ارائه‌دهنده را در خود ندارد.

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

جابه‌جایی ارائه‌دهنده هنوز فهرست بررسی دارد

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

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

هم‌پوشانی نشانی با سایت متصل دیگر یک مسئله برنامه‌ریزی جداگانه است. تغییر ارائه‌دهنده آن را ایجاد نمی‌کند، اما مهاجرت معمولاً زمانی است که آشکار می‌شود.

چه چیزی دوام نمی‌آورد: منبع عمومی و نشست‌ها

نشانی خصوصی پایدار سرور، منبع عمومی پایدار نیست. اگر مرور مستقیماً از ارائه‌دهنده جدید خارج شود، وب‌سایت‌ها نشانی جدیدِ رو به ارائه‌دهنده را می‌بینند.

نگه داشتن آن نشانی به‌صورت پایدار نیازمند طراحی خروجی آگاهانه با دسترس‌پذیری و سیاست خودش است. این با تونل به‌رایگان نمی‌آید.

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

جابه‌جایی را با چهار بررسی تأیید کنید

پس از تغییر، چهار چیز را به ترتیب تأیید کنید: تونل با همتای مورد نظر برقرار است، مسیر درونی به پیشوند شعبه وجود دارد، سیاست جریان برنامه را مجاز می‌کند و برنامه پاسخ می‌دهد. هر یک فرمان خودش را دارد.

روی دروازه Linux، این سه میانه آن فهرست را پوشش می‌دهند:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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