למה תזכורת VPN של 23 שעות נורית עבור הסשן הלא נכון
התראה של 23 שעות צריכה לעקוב אחרי סשן אחד, לא אחרי החשבון. הצמידו את הטיימר לחיבור שהתחיל, והתייחסו לשינה ולחיבור מחדש כמקרים נפרדים.
ההתראה הופיעה עשרים דקות לאחר ההתחברות. המונה שמתחתיה רץ מאז הבוקר הקודם, או מאז ההזדהות האחרונה של החשבון, ושום דבר בהתראה לא אמר איזה מהם. זה הסימפטום: תזכורת שקשורה למשהו אחר ולא לחיבור שלפניכם.
התיקון אינו התראה טובה יותר. הוא להחליט איזה שעון הדרישה מתכוונת אליו, ואז לקשור את הטיימר לאובייקט שקיים בשעון הזה.
מה נורה, ומה הוא ספר
שלושה מקורות סבירים מייצרים את אותה הודעה. כלל יומן רץ בשעה מקומית קבועה ואינו יודע דבר על מנהרות. מונה בלקוח מצטבר כל עוד חיבור כלשהו פעיל ושורד התחברויות מחדש. מדיניות שער מפקיעה את הסשן בצד השרת ודוחפת אזהרה תחילה.
רק השניים האחרונים עוסקים בסשן, וגם הם אינם מסכימים. מונה הלקוח מודד את מה שהתהליך המקומי הבחין בו; השער מודד את מה שאימת וחשב. שינה, החלפת רשת או הפעלה מחדש של הצופה יכולים להפריד ביניהם בשעות, ולכן ההתראה והפקיעה הכפויה מתרחקות זו מזו.
שלושה שעונים מאחורי דרישה אחת
התחילו בכתיבת המשפט שאתם באמת רוצים. אזהרה לפני שהשער מסיים את החיבור הזה אינה אותה דרישה כמו תזכורת לאחר יום של זמן מחובר. היא גם אינה אותו דבר כמו לדווח שהסשן הזה פעיל כבר 23 שעות. כל גרסה נוקבת באירוע אחר, ורכיב אחר צריך להשיב עליו.
אחר כך בדקו אם הנתונים קיימים. חותמת זמן מקומית של התחלה נותנת את גיל הסשן בלי תלות בשרת. מדיניות שער נותנת את משך החיים שנותר, אך רק אם השער חושף אותו. דוח שימוש נותן את המשך לאחר מעשה, וזה אינו יכול להניע התראה מראש.
קשרו את הטיימר לסשן, לא לחשבון
בחרו קודם את האובייקט. חשבון יכול להחזיק כמה מכשירים וכמה סשנים בו-זמנית, ולכן תזכורת שממופתחת לפי שם המשתמש אינה יכולה לומר איזה חיבור הגיע לגיל. פתחו אותה לפי הפרופיל בתוספת ההפעלה ההיא, ובטלו את ההתראה הממתינה כשההפעלה מסתיימת.
| Evidence you can read | What it establishes | Where it misleads |
|---|---|---|
| Connection state changes to active | A session started now | Does not carry the gateway's own session identifier |
| Duration reported at disconnect | Total service time for that session | Arrives too late for any advance notice |
| Interim usage update | Time accounted up to that update | Staleness equals the update interval |
| Local timestamp taken at activation | Age of your observation | Resets whenever the observer restarts |
הטבלה ההיא היא חוזה למודיע שלכם, לא תיאור של API קריאה חוזרת של שום לקוח. מה שהמוצר המותקן מתעד לגבי מצב החיבור הוא המקור שאליו יש להיקשר; במקום שהוא חושף רק אירועי אימות, אמרו זאת בקול וקבלו את ההתנהגות הגסה יותר במקום להסיק סשן.
בדקו אותו עם סף קצר
לעולם אל תנפו טיימר של יום שלם בהמתנה של יום שלם. הוסיפו סף ניתן להגדרה, קבעו אותו לשלושים שניות, והריצו ארבעה מעברים בסדר: התחברות, המתנה, ניתוק, התחברות מחדש. כל מעבר אמור להפיק בדיוק שינוי מצב אחד, וההתחברות מחדש אמורה לתזמן מועד חדש ולא לרשת את הישן.
# current connection state and profile identity
nmcli -f GENERAL.STATE,GENERAL.CONNECTION connection show work
# the notifier unit you wrote: does it restart the deadline or resume it?
journalctl --user -u vpn-timer.service --since "-5 min" -o catהביטו בחותמות הזמן ולא בניסוח. התראה שמגיעה עם שעת ההתחלה של הסשן הקודם קשרה את האובייקט הלא נכון, והתראה שמגיעה פעמיים עבור מועד אחד פירושה שדגל השליחה מעולם לא נשמר.
שינה, חיבור מחדש ומסירה שהוחמצה
שינה שוברת את שני העיצובים הנאיביים. ספירה לאחור מונוטונית נעצרת כשהמכונה ישנה, מועד לפי שעון קיר ממשיך לזוז, וטיימר שמתלקח בזמן שינה נמסר באיחור או לא נמסר כלל. החליטו איזו התנהגות הדרישה שלכם צריכה, ואז הרדימו את המכונה מעבר לסף ואמתו.
המסירה ראויה לאותה הקפדה. אם לא ניתן להציג את ההתראה, תורו אותה, ובדקו שוב שסשן היעד עדיין קיים לפני שמציגים אותה לבסוף; אחרת המשתמש מוזהר מפני חיבור שכבר הסתיים. ניתוק כפוי וחידוש אישורים נשארים מחוץ למסלול הזה, מפני שתזכורת שמשנה בשקט את גורל החיבור היא החלטת מדיניות לבושה בהתראה.