לפני ש-charm של Juju הופך ל-VPN שלך: זהות, חוזה, פורטים

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

שלב ראשון: נעלו את הארטיפקט שאתם קוראים עליו

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

juju info CHARM_NAME מדווח על ערוצים, בסיסים וארכיטקטורות ב-Juju 3.6, והתיעוד מציין שלא ניתן לשלב שאילתה של גרסה מסוימת עם המסננים האלה. שאלו על הגרסה בנפרד במקום לבנות שילוב שהפקודה דוחה. קראו גם את הבסיס והארכיטקטורה, כי ערוץ יכול לכסות יותר מאחד.

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

שלב שני: קראו את התצורה כחוזה

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

עקבו אחר הממשקים והפעולות שה-charm באמת חושף. אל תניחו שפעולת הרשמה קיימת רק מפני של-charm אחר עבור אותה תוכנה יש אחת.

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

שלב שלישי: הפרידו את המאזין מהנתיב המועבר

המאזין החיצוני הוא ה-socket שמקבל את המנהרה. העברה היא מה שקורה לתעבורה שבתוכו, ונתיב חזרה הוא מה שמאפשר לתשובות לחזור. charm יכול לספק את הראשון ולהשאיר את השניים האחרים לצוות התשתית.

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

שלב רביעי: חשיפה היא פעולת חומת אש

ב-Juju 3.6, חשיפת יישום מתאימה את כללי חומת האש בענן, וברירת המחדל היא לאפשר תעבורה מכל מקור לפורטים שעומס העבודה פתח. בוררי ה-endpoint וה-CIDR של הפקודה קיימים בדיוק כדי שניתן יהיה לצמצם את ברירת המחדל הזו.

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

שלב חמישי: קבלו בארבעה מבחנים

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

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