از Access Server به OpenVPN Community: چه چیزهایی باید بازسازی شود
Access Server سیاست را نگه می دارد و Community OpenVPN از شما می خواهد آن را بنویسید. پیش از کپی کردن حتی یک گواهی، هویت، مسیرها و ابطال را نقشه برداری کنید.
Access Server و Community OpenVPN یک پروتکل را می فهمند و تقریبا هیچ چیز دیگری را به یک شکل. دست دادن، مذاکره رمز و صفحه داده تونل سازگار هستند، بنابراین یک کلاینت اغلب می تواند بدون ویرایش پروفایل خود به هر یک متصل شود. تفاوت در این است که پیکربندی متعلق به کیست: یکی لایه مدیریتی دارد که سیاست را می نویسد و اجرا می کند، دیگری یک فایل پیکربندی و مجموعه ای از قلاب ها به شما می دهد و انتظار دارد خودتان تصمیم بگیرید.
همین تمایز، برنامه مهاجرت است. هر چیزی که محصول قدیمی به جای شما تصمیم گرفته باید در جایی از استقرار جدید به یک تصمیم صریح تبدیل شود.
جایی که دو استقرار دیگر قابل تعویض نیستند
در Access Server، رابط مدیریت وب مالک کاربران، گروه ها، مجوزهای هر کاربر، صدور گواهی و بسته پروفایلی است که شخص دانلود می کند. دیمن زیرین توسط همان لایه پیکربندی می شود، بنابراین سرویس در حال اجرا محصول وضعیت ذخیره شده ای است که به ندرت دستی ویرایش می کنید. در Community OpenVPN، فایل پیکربندی خود وضعیت است: شنونده، مرجع صدور گواهی، قلاب احراز هویت و هر گزینه فشرده را نام می برد و هیچ چیز آن را برای شما بازنویسی نمی کند. بنابراین همان ماشین TLS زیر دو مدل مالکیت بسیار متفاوت قرار می گیرد.
یک نقشه کوتاه شکاف را ملموس می کند. کاربران و گروه ها فقط در پایگاه داده قدیمی وجود دارند تا زمانی که دوباره بسازیدشان. بسته های پروفایل به یک فایل پیکربندی به علاوه گواهی هایی تبدیل می شوند که خودتان توزیع می کنید. مجوزهای هر کاربر به دایرکتیوهایی در client-config-dir تبدیل می شوند. رابط مدیریت به هر فرایندی تبدیل می شود که برای صدور گواهی و ویرایش فایل انتخاب می کنید.
این نقشه را قبل از دست زدن به سرور بنویسید. هر ردیفی که نمی توانید پر کنید ویژگی ای است که در آستانه از دست دادن آن هستید، و از دست دادن بی صدا همان چیزی است که مهاجرت را دو هفته بعد به قطعی تبدیل می کند.
هویت با فایل های گواهی منتقل نمی شود
گواهی های مرجع قدیمی ممکن است در سرویس جدید درست تجزیه شوند و باز هم هویت اشتباه باشند، چون محصول قدیمی آن ها را با وضعیت حسابی جفت می کرد که سرویس جدید نمی بیند. اول تصمیم بگیرید که استقرار جدید فقط با گواهی احراز هویت می کند، یا با افزونه ای که به PAM یا RADIUS می رسد، یا با ترکیبی، سپس بررسی کنید که هر گزینه ویژگی های لازم را حفظ می کند. گواهی مشترک بدون هویت هر کاربر یک اعتبارنامه برای همه دارندگان آن است. ابطال هم باید از روز اول کار کند، که در Community OpenVPN یعنی فایل CRL که crl-verify به آن ارجاع می دهد به علاوه فرایندی که آن را دوباره می سازد.
ثبت نام را قبل از تغییر برنامه ریزی کنید نه بعد از آن. گواهی های جدید، مسیر ابطال آزمایش شده و روش مستند برای غیرفعال کردن یک نفر پیش نیاز هستند نه کار بعدی. اگر احراز هویت چندعاملی از یکپارچگی محصول قدیمی می آمد، جایگزین را صریح نام ببرید، چون افزونه ای که نصب نشده باشد در بدترین لحظه به صورت بسته شکست می خورد.
مسیریابی و حل نام از نویسنده پیکربندی پیروی می کنند
مسیرها، تنظیمات DNS و رفتار تونل کامل در هر دو محصول گزینه های فشرده هستند، اما فقط یکی آن ها را برای شما محاسبه می کند. در Community OpenVPN دایرکتیوهای push را خودتان می نویسید، تصمیم می گیرید redirect-gateway روی سرور باشد یا کلاینت، و تأیید می کنید که ارسال بسته و NAT روی میزبان وجود دارد. یک دست دادن تمام شده هیچ چیزی درباره ارسال، ترجمه آدرس یا مسیرهایی که کلاینت واقعا دریافت کرده به شما نمی گوید.
رفتار هر کلاینت به client-config-dir نیاز دارد به علاوه فایلی به نام common name گواهی کلاینت، و یک همتای سایت به سایت به ورودی های iroute برای پیشوندهای پشت آن نیاز دارد. اگر نام گذاری اشتباه باشد، گزینه ها بی هیچ خطایی نادیده گرفته می شوند. با یک کلاینت غیرتولیدی در استخر آدرس خودش آزمایش کنید، سپس آدرسی که به آن داده شد، مسیرهایی که گرفت و تنظیمات resolver که با آن تمام کرد را بخوانید.
تغییر را طوری ترتیب دهید که سرویس قدیمی بتواند برگردد
شنونده جدید را روی پورت یا آدرس دیگری اجرا کنید و قدیمی را در حین اثبات جایگزین به ترافیک سرویس دهی نگه دارید. دو دیمن روی یک سوکت برنامه بازگشت نیست.
هر بار یک گروه را جابه جا کنید، با گواهی ها، استخر و مسیرهای خودش، و مسیر بازگشت را تمرین کنید نه اینکه در میانه یک حادثه کشفش کنید. بازگشتی که فقط وقتی کار می کند که سرویس جدید اول متوقف شود هنوز بازگشت است، اما باید وقتی هیچ چیز در آتش نیست آزمایش شود.
در پایان، ویژگی هایی را که معادل مستقیم ندارند فهرست کنید و سرنوشت هر یک را کتبا تعیین کنید: دانلود پروفایل خودخدمتی، پرچم های مجوز هر کاربر، خود رابط مدیریت، گزارش اتصال زنده. جایگزین کردن آن ها با یک فرایند دستی مستند پاسخ مشروعی است. خالی گذاشتن ردیف نیست.
کار وقتی تمام است که کاربری که هرگز پنل قدیمی را ندیده بتواند ثبت نام کند، متصل شود، به آدرس داخلی مورد نظر برسد و پاک ابطال شود. همه چیز پیش از آن آماده سازی است.