שקע הניהול של OpenVPN: ערוץ שליטה, לא מדדים

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

האמונה, ומה היא עולה

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

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

מה לקוח מאושר באמת מחזיק

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

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

שקע בבעלות, לא שקע פתוח

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

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

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

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

פרסום דרך TCP אינו אותו תכנון

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

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

תלויות אתחול שלא ביקשתם

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

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

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

איך נראית קבלה

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

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