מ-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 אתם כותבים את הנחיות הדחיפה בעצמכם, מחליטים אם redirect-gateway שייך לשרת או ללקוח, ומאשרים שהעברה ו-NAT קיימים במארח. לחיצת יד שהסתיימה לא מספרת לכם דבר על העברה, על תרגום כתובות או על הנתיבים שהלקוח קיבל בפועל.

התנהגות לכל לקוח דורשת client-config-dir בתוספת קובץ שנקרא על שם ה-common name של תעודת הלקוח, ועמית מאתר לאתר דורש רשומות iroute עבור הקידומות שמאחוריו. אם השם שגוי, האפשרויות מתעלמות בלי שגיאה. בדקו עם לקוח אחד שאינו בייצור בבריכת הכתובות שלו, ואז קראו את הכתובת שהוקצתה לו, את הנתיבים שקיבל ואת הגדרות הפותר שאיתן סיים.

סדרו את המעבר כך שהשירות הישן יוכל לחזור

הריצו את המאזין החדש בפורט או בכתובת אחרים, והשאירו את הישן משרת תנועה בזמן שאתם מוכיחים את התחליף. שני דמונים על אותו שקע אינם תכנית חזרה.

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

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

העבודה תמה כאשר משתמש שלא ראה מעולם את הפורטל הישן יכול להירשם, להתחבר, להגיע לכתובת הפנימית המיועדת ולהיפסל בצורה נקייה. כל מה שלפני כן הוא הכנה.