انتقال OpenVPN از TAP به TUN: ترتیبی از مهاجرت که کار می‌کند

جایگزین‌کردن dev tap با dev tun تغییر می‌دهد که تونل چه چیزی را حمل می‌کند، نه فقط نامش را. یک رابط TAP قاب‌های Ethernet را به پل تحویل می‌دهد، پس کارخواه‌ها طوری رفتار می‌کنند که گویی به سوئیچ دفتر وصل شده‌اند. یک رابط TUN بسته‌های IP را حمل می‌کند، پس کارخواه‌ها به مسیر نیاز دارند و طرف مقابل به راه بازگشت. کارخواه‌ها، طرح نشانی و مسیر بازگشت شبکه محلی همه باید با این تغییر جابه‌جا شوند.

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

فهرست کنید چه چیزی واقعاً به Ethernet وابسته است

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

این فهرست همان فهرست پذیرش هم هست. هر موردی که نتوانید مهاجرت دهید به یک استثنای مستند یا دلیلی برای زنده نگه داشتن یک بخش کوچک TAP تنها برای همان بار کاری تبدیل می‌شود.

طرح نشانی و مسیر بازگشت را بسازید

پیشوندی برای کارخواه‌ها انتخاب کنید که با شبکه محلی، محدوده قدیمی پل یا هر شبکه‌ای که کارخواه از قبل به آن می‌رسد همپوشانی نداشته باشد.dev tun، topology subnet و server 10.78.0.0 255.255.255.0، اما این یک قطعه است، نه یک نمایه کارا. سیاست تأییدشده TLS، هویت، انتقال و دسترسی را پیرامون آن نگه دارید و پیشوندی را به کار ببرید که آزاد بودنش را بررسی کرده‌اید.

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

روی یک شنونده جداگانه آزمایش کنید

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

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

کارخواه‌ها را در گروه‌هایی با امکان بازگردانی جابه‌جا کنید

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

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

پل را تنها پس از پذیرش بازنشسته کنید

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

مهاجرت زمانی تمام می‌شود که مدل دسترسی مسیریابی‌شده برای فهرست کار کند، نه زمانی که یک رابط TAP از خروجی ip link ناپدید شود.