רק לקוח ניהול אחד: למה תוכנת הניטור שלך מפילה את ממשק המשתמש הגרפי
שקע הניהול מקבל חיבור אחד בכל פעם. מנוי שני או שנכשל בהתחברות או שגונב שליטה מהרכיב שמחזיק בהנחיות.
ממשק גרפי לשולחן העבודה מחזיק בחיבור הניהול, ולכן תסריט ניטור מנסה לפתוח חיבור משלו ולא קורא דבר, או גרוע מכך, הממשק מפסיק להגיב להנחיות. המסקנה הרגילה היא שהדמון לא יציב. בדמון הקהילתי המגבלה היא מכוונת: ממשק השליטה משרת לקוח ניהול מחובר אחד בכל פעם, ומספר זה אינו קשור לכמה משתמשים ה-VPN יכול לשאת.
שקע אחד, מחזיק אחד
ערוץ הניהול מקבל לקוח מחובר אחד. כאשר שני מגיע בזמן שהראשון פעיל, הוא ממתין או נדחה, ואין מצב מנוי מקביל חבוי מאחורי אפשרות. ניתוק המחזיק הנוכחי מאפשר לדמון לקבל את הבא, וזהו מסירה ולא ערוץ שני.
זה הופך כל כלי נוסף למתחרה. אם הממשק הגרפי מחזיק בחיבור, תסריט סקירה או שנכשל בהתחברות או שמצליח רק לאחר שהממשק ויתר, והרצף חוזר בחיבור הבא. אם התסריט מתחבר ראשון, הממשק מאבד את נתיב השליטה שלו וההנחיות שלו מפסיקות לעבוד. אף אחד מהכלים אינו מדווח על ההתנגשות, כי כל אחד רואה רק את הפקודה שנכשלה אצלו.
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
החליטו איזה רכיב מחזיק בשליטה
בחרו מחזיק אחד לערוץ האינטראקטיבי ותנו לו להיות הדבר היחיד שמתחבר. ממשק גרפי שמנהל את החיבור, תסריט שעונה להנחיות האימות ובקר שמסיים הפעלות נחשבים כולם למחזיקים, ורק אחד יכול למלא את התפקיד.
כאשר ממשק גרפי מחזיק בחיבור, השתמשו באינטגרציה שהממשק מספק במקום להיאבק בו. התחרות עם המחזיק על השקע מייצרת כשלים לסירוגין שנראים אקראיים למשתמשים, והאדם שמנפה בדרך כלל רואה רק את המחצית השנייה של המירוץ. שימו לב איזה תהליך מתחבר ראשון לאחר אתחול, כי הסדר הזה קובע מי ינצח בכל פעם. ניטור שמתחיל לפני הממשק הגרפי ישמור על הערוץ עד שהממשק יוותר.
השתמשו בתמונות מצב של סטטוס עבור האספנים
רוב הניטור צריך רשימה, לא שיחה. קובץ סטטוס תקופתי עונה על כך בלי לגעת בערוץ השליטה, והוא ממשיך לעבוד כל עוד הממשק הגרפי נשאר מחובר.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixהמרווח הוא תקציב הרעננות, אז כווננו אותו למה שלוח המחוונים באמת צריך ולא לערך הקטן ביותר שנראה בטוח. תמונת מצב שנכתבת כל כמה שניות היא זולה; תסריט שמתחבר מחדש לשקע השליטה כל כמה שניות אינו זול, כי כל חיבור מחדש מתחרה במחזיק.
תמונת מצב אינה היסטוריה ואינה זרם אירועים. חיבורים שמגיעים ועוזבים בתוך מרווח אחד לעולם אינם מופיעים, ולכן דרישת ביקורת אינה יכולה להתממש על ידי סקירה של קובץ שדורס את עצמו. אם אתם צריכים לדעת שמשתמש התחבר בכלל, תמונת המצב היא הכלי הלא נכון.
פריסה היא תכנון, לא מצב
אם כמה צרכנים באמת זקוקים לנתוני ניהול חיים, הציבו רכיב מהימן אחד לפני השקע ותנו לו לפרסם תצפיות נבחרות בקפידה לשאר. אותו רכיב מחזיק בחיבור מחדש, בהנחיות האימות ובהחלטה מה בטוח לחשוף.
בנו אותו בכוונה: הגדירו אילו שאילתות מותרות, תעדו מי שאל, והימנעו מלהפוך את שכבת הפריסה ללוח בקרה מרחוק בטעות. לדמון אין מצב מרובה לקוחות להפעלה, ואף שורת תצורה אינה יוצרת אחד. התייחסו למחזיק כחלק מגבול האבטחה, כי הוא מחזיק בממשק שיכול לנתק אנשים. הפעלה מחדש שלו צריכה להיות פעולה שגרתית עם נתיב התאוששות מתועד.
התייחסו לשקע כאל הרשאה, לא כאל מדדים
ממשק הניהול יכול לנתק משתמשים, לשנות מצב ולקרוא אירועים שמזכירים אנשים בשמם. הסיסמה שלו מאמתת את הלקוח ואינה מצפינה את התעבורה, ולכן מאזין ברשת חושף את השיחה לכל מי שיכול לצפות בה.
העדיפו שקע מקומי או מאזין מוגבל היטב, ובדקו לאיזה תהליך האספן שלכם באמת פונה, כי מוצרי שרת מגיעים עם ממשקי ניהול משלהם שמתנהגים אחרת. אספן שמכוון לדמון הלא נכון מפיק מסקנות בטוחות ושגויות. אשרו את הנתיב ואת התהליך המחזיק לפני שאתם מנפים שאילתה שלא מחזירה דבר.