פרופילים עוברים; רשימות משתמשים נשארות מאחור. צוות שעובר בין 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, ולא מכשל אימות.

השאירו את נתיב השחזור הישן חי עד ש-המחליף יעבור בדיקת גישה נדחית וגם בדיקה מוצלחת. כתבו את המפה הסופית בעמוד אחד: כל דרישה, החפץ שמספק אותה היום והחפץ שיספק אותה אחר כך.

מאמרים קשורים