היכן ממוקם מכסת נתונים חודשית לכל חשבון OpenVPN

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

הצמידו את המכסה לחשבון, לא למנהרה

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

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

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

קבעו את היחידה, הכיוון וגבול האיפוס

יש להסדיר ארבע הגדרות בכתב לפני שכל איסוף מתחיל. האם המכסה סופרת בתים שהלקוח שולח, בתים שהוא מקבל, או את הסכום של שניהם? האם גיגה-בייט הוא 10^9 בתים או 2^30? באיזו שעה מקומית ובאיזה אזור זמן מתהפכת התקופה? ומה בדיוק מודד המונה, בהינתן שתקורת המנהרה ושליחות חוזרות נכללות ואילו גודל קובץ היישום והחשבונית של ספק אינם?

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

הפכו סכומי בתים להפרש מחויב אחד

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

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

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

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

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

הניצול יחסום כניסה, ולא רק יהרוג את המנהרה

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

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

התחברויות מחדש מבוססות אסימון ראויות למבחן משלהן. OpenVPN 2.6 יכול לאמת אסימון הפעלה פנימית עם auth-gen-token, תוך דילוג על קריאת האימות החיצונית שהבקר שלכם השתמש בה כדי לאכוף את התקרה. אסימון שעדיין תקף מוכיח אפוא זהות, לא מכסה שנותרה, וכל מופע לקוח חדש חייב עדיין להתייעץ עם ספר החשבונות. אם תפעילו במקום זאת management-client-auth, הבקר הופך למאמת ויורש את החובה לנתח את מצב ההפעלה ולדחות אסימונים שפגו או שאינם תקפים בעצמו.

קבלו את החריגה שהדגימה יוצרת

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

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

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