OpenVPN Access Server در برابر Community: چه چیزی واقعاً منتقل میشود
Community Edition و Access Server پروتکل OpenVPN را شریکاند، اما لایه مدیریت را نه. مقایسه کنید چه چیزی جابهجا میشود، چه چیزی باید از نو ساخته شود و چه کسی از آن پشتیبانی میکند.
پروفایلها منتقل میشوند؛ فهرست کاربران جا میماند. تیمی که بین Access Server و Community Edition جابهجا میشود، یک ساعت پس از انتقال با این شکاف روبهرو میشود، وقتی اولین کلاینتش احراز هویت میکند و بعد نه سیاست گروهی دارد، نه مسیر هر کاربر و نه بازنشانی رمز بهصورت خودسرویس. هر دو محصول به یک پروتکل سخن میگویند و یک کلاینت را میپذیرند، و دقیقاً به همین دلیل شکاف در زمان برنامهریزی نامرئی میماند. آنچه واقعاً انتخاب میکنید لایه مدیریت و افرادی است که مالک آناند.
تصمیم را پرسشی از جنس انبارشمارى بدانید، نه جدول ویژگیها. بپرسید چه کسی کاربر میسازد، چه کسی گواهیها را باطل میکند، و چه کسی ساعت 02:00 تلفن را جواب میدهد.
چرا فایل .ovpn پیکربندی را با خود نمیبرد
یک پروفایل .ovpn رابطه یک کلاینت با یک سرور را توصیف میکند: میزبان راهدور، پروتکل، CA، گواهی و کلید کلاینت، و هر ماده tls-crypt درونخطی. آن فایل را در نصب تازهای بیندازید و کلاینت باز هم دستدادن را کامل میکند، پس مهاجرت تمامشده به نظر میرسد. چیزی در آن کاربران، گروههایشان، مسیرهای ثابتشان یا سیاستی را که تعیین میکرد چه کسی اصلاً اجازه اتصال دارد فهرست نمیکند. آن سوابق در انبار خود سرور زندگی میکنند و دو محصول آنها را در شکلهای متفاوت نگه میدارند.
در Community Edition معادلها فایلهایی هستند که خودتان نگه میدارید: ورودیهای client-config-dir با گزینههایی برای هر کلاینت مانند ifconfig-push و iroute، یک CRL برای باطلسازیها، و کلید tls-crypt. Access Server همان مفاهیم را در پایگاه داده خود نگه میدارد و آنها را از طریق کنسول وب و ابزار خط فرمان sacli در دسترس میگذارد. مفاهیم یکبهیک تناظر دارند؛ مصنوعات اصلاً جابهجا نمیشوند.
پروفایلها رفتاری را هم قاچاقی وارد میکنند که هیچکس تا وقتی تغییر نکند متوجهش نمیشود. کلاینتی با redirect-gateway def1 تمام مرور را از سرور میفرستد؛ آن را به نصبی بدون آن خط ببرید و شکایت این است که اینترنت خراب شده. ناسازگاری CA یا تنظیم نادرست remote-cert-tls بلند شکست میخورد، که نتیجه خوبی است. کلید tls-crypt غایب بهصورت مهلت خاموش شکست میخورد، که خوب نیست.
لایه مدیریت چه چیزی را در اختیار دارد
آنچه پروتکل نیست را بشمارید: ساخت حساب، بازنشانی رمز، تخصیص گروه، ثبت MFA، حقهای اتصال، و ردیف حسابرسی که پاسخ میدهد چه کسی کِی متصل شد. Community Edition هیچیک از اینها را مستقیم فراهم نمیکند. شما یک بکاند احراز هویت انتخاب میکنید، PAM، LDAP یا RADIUS را از طریق افزونه یا auth-user-pass-verify وصل میکنید، و بقیه را خودتان نگه میدارید. Access Server درگاه کاربر، کنسول مدیریت و یکپارچهسازی با ارائهدهندگان هویت رایج را عرضه میکند. هیچکدام از دو چیدمان بهطور پیشفرض امنتر نیست، چون سیاست هنوز باید توسط کسی نوشته شود که شبکه را میشناسد.
حقهای اتصال تیزترین تفاوت عملیاتی است. Access Server بر اساس شمار اتصالهای همزمان مجوز میگیرد و آن شمار را در نرمافزار اعمال میکند. در Community Edition سقف جهانی یک خط max-clients است، در حالی که هر چیز بهازای کاربر یا گروه یعنی کار بیشتر با client-config-dir و اعمال خودتان. تیمی که اشتهایی به این نگهداری ندارد، دقیقاً همین را میخرد وقتی بابت محصول تجاری پول میدهد.
مجوز و پشتیبانی: ردیفی که هیچکس بودجهاش را نمیبندد
Community Edition رایگان و متنباز است. Access Server تجاری است و رده رایگانش تاریخی شمار کمی از اتصالهای همزمان را با مجوز پرداختی بالاتر از آن پوشش داده است. هر رقمی که در پاسخ فروم قدیمی نقل شود اکنون کهنه است، پس پیش از برآورد هزینه پروژه شرایط فعلی فروشنده را بررسی کنید. مقایسه صادقانه ساعتهای صرفشده برای ساخت مدیریت کاربر، MFA و پایش در سمت جامعه را به ردیف مجوز در سمت تجاری میافزاید.
مالکیت پشتیبانی همان تقسیم را دنبال میکند. با Community Edition شما مسیر ارتقا برای هر کلاینت عجیب و هر بهروزرسانی هسته هستید. با Access Server فروشندهای برای تماس دارید و ریتم انتشار آن را به ارث میبرید، چه با پنجره تغییرات شما جور باشد چه نه.
بررسیهایی که باید پیش از انتقال انجام شوند
پیش از انتقال در هر جهت، انبارشمارى کنید که سرور در حال اجرا واقعاً چه نگه میدارد. در سمت Access Server فهرست کاربران و تخصیص گروهها را صادر کنید و یادداشت کنید کدام حسابها به MFA وابستهاند. در سمت Community Edition گواهیهای صادرشده، CRL و هر فایل زیر client-config-dir را فهرست کنید. دو فهرست را خط به خط مقایسه کنید، چون تفاوت میان آنها همان کار مهاجرت است.
کلاینتهای نماینده را وقتی سرویس قدیمی هنوز کار میکند بیازمایید. openvpn --config client.ovpn --verb 4 در پیشزمینه دستدادن، مسیرهای ارسالی و گزینههای DNS را چاپ میکند، و openssl x509 -in client.crt -noout -subject -enddate نشان میدهد کلاینت واقعاً کدام گواهی را ارائه میدهد. کلاینتی که متصل میشود اما به میزبان داخلی نمیرسد شکافی در مسیر یا در iroute دارد، نه شکست احراز هویت.
مسیر بازیابی قدیمی را زنده نگه دارید تا وقتی جانشین هم آزمون دسترسی ردشده را بگذراند و هم آزمون موفق را. نقشه نهایی را در یک صفحه بنویسید: هر نیاز، مصنوعی که امروز آن را برمیآورد، و مصنوعی که بعداً برمیآورد.