מסלול מכשיר OpenVPN: בעל התצורה או סקריפט אתחול?
מסלול סניף ששורד אתחול אחד עדיין יכול להיעלם לאחר שמירה מה-GUI או עדכון קושחה. השוו בין בעל התצורה הנתמך לבין סקריפט טלאים.
אתם מוסיפים מסלול סניף, הוא עובד, ואז עדכון קושחה או שמירה מממשק האינטרנט מסירים אותו. שני תיקונים נראים סבירים באותה מידה באותו רגע: לשים את המסלול במקור התצורה הנתמך של המכשיר, או להוסיף אותו לקובץ שנוצר מסקריפט אתחול. הם מתנהגים אותו דבר במשך שבוע ומתפצלים בעדכון השני. מאמר זה משווה מה כל אחד מהם באמת מחזיק.
שני המועמדים מחזיקים בדברים שונים
מקור התצורה הנתמך הוא כל מה שהמכשיר מתייחס אליו כקלט: שדה GUI, פרופיל מיובא, תיקייה מתועדת לכל לקוח, מסד נתוני הגדרות שחבילת הניהול קוראת. הקובץ server.conf שנוצר הוא פלט. עריכת פלט עובדת עד שהמחולל רץ שוב, וזה קורה בשמירה, באתחול ובעדכון.
גישת הסקריפט מתקנת את הפלט הזה לאחר שהמחולל מסיים. זו טכניקה לגיטימית למעבדה, והיא ברירת המחדל השגויה למשרד סניף, כי היא הופכת את המסלול לתלוי בהתאמת טקסט במקום בשדה מתועד.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
מה המכשיר מייצר מחדש, ומתי
חבילות ניהול בדרך כלל שומרות הגדרות במסד נתונים או בקבוצת תבניות ומפיקות את תצורת הדמון באתחול. שמירה מממשק האינטרנט לעתים קרובות כותבת מחדש את כל הקובץ במקום לתקן שורה. אם השינוי שלכם חי בקובץ הזה, הוא נעלם כעת, ושום דבר לא רושם אזהרה, כי מנקודת המבט של המכשיר דבר לא אבד.
לעטיפות אתחול יש מצב כשל שני. grep אחרי הנחיה עם ריווח מסוים מפסיק להתאים לאחר שינוי תבנית, והסקריפט בשקט לא עושה דבר. גרוע מכך, עדכון קושחה יכול להחליף את העטיפה בגרסה חדשה ולקחת איתו את הטלאי. אז יש לכם מסלול שהתקיים שנה ונעלם במהלך תחזוקה שאיש לא קישר לניתוב.
מה הבעלים הנתמך חייב לבטא
קידומת סניף צריכה שלוש הצהרות, לא אחת. הלקוח חייב ללמוד את המסלול, השרת חייב לדעת איזה לקוח מאומת מחזיק בקידומת, וצד הסניף חייב להחזיר תעבורה לכתובת המנהרה שניתנה לו. במונחי OpenVPN זה אומר route נדחף, iroute תואם שנקשר ללקוח, ונתיב חזור בצד השני.
כאן ממשקי מכשירים מטעים. תיבת סימון שכותרתה „לאפשר ללקוחות לגשת ל-LAN של השרת“ מתארת תעבורה לכיוון הרשת של השרת עצמו. הסניף שלכם הוא הכיוון ההפוך: רשת מאחורי לקוח אחד, נגישה מצד השרת. אותה תווית אינה מרמזת על תמיכה בכך, והנחיה תקפה בקובץ אינה הבטחה שהחבילה תשמור עליה.
כשאין בקרה נתמכת
לפעמים הגרסה המותקנת באמת לא יכולה לבטא מסלול ייחודי לעמית. אז האפשרויות הכנות הן שער אחר שאתם שולטים בו, או מצב אתר-לאתר נתמך בשני הקצוות. שני הקצוות חייבים לדבר אותו. דף מוצר שאומר אתר-לאתר לא הופך פרופיל OpenVPN שרירותי לבר-החלפה עם המנהרה של פרוטוקול אחר, וכפיית הצימוד הזה בדרך כלל מייצרת מנהרה מחוברת למחצה שנראית טוב בדף סטטוס.
בחרו את האפשרות שתוכלו לתאר במשפט אחד למי שיורש את הרשת. אם התשובה מחייבת לציין נתיב סקריפט ותבנית טקסט, העיצוב כבר שביר.
הפכו את הכוונה לניתנת לביקורת
תעדו את החוזה מחוץ למכשיר: זהות לקוח אפקטיבית, קידומת, שער חזור, והשדה הנתמך שמספק כל אחד מהם. ייצאו את התצורה דרך המנגנון הנתמך כדי שלבנייה מחדש תהיה התייחסות, ואמתו את השירות לאחר התחברות מחדש, אתחול ועדכון ולא רק לאחר השינוי.
השוו את התוצאה שנוצרה לרשומה הזו כשמשהו נשבר, במקום לשחזר שורה לא מוסברת ולקוות.הפניית OpenVPN 2.6 היא המקום לאשר כיצד route ו-iroute פועלים יחד לפני שתתווכחו עם ממשק.
רשימת בדיקה לשינוי הבא: תנו שם לבעלים, הצהירו על החוזה התלת-חלקי, ייצאו את הכוונה, ובדקו שוב לאחר אירועי מחזור החיים של המכשיר עצמו ולא לאחר העריכה שלכם.