چرا یادآور 23 ساعته VPN برای نشست اشتباه فعال می‌شود
هشدار 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به برچسب‌های زمان نگاه کنید نه به عبارت‌بندی. هشداری که با زمان شروع نشست قبلی می‌رسد شیء اشتباه را بسته است، و هشداری که برای یک مهلت دو بار می‌رسد یعنی نشانگر ارسال هرگز ذخیره نشده است.
خواب، اتصال دوباره و تحویل ازدست‌رفته
خواب هر دو طراحی ساده‌لوحانه را می‌شکند. شمارش معکوس یکنوا وقتی ماشین می‌خوابد می‌ایستد، مهلت بر پایه ساعت دیواری به حرکت ادامه می‌دهد، و تایمری که هنگام خواب فعال می‌شود دیر یا هرگز تحویل نمی‌شود. تصمیم بگیرید الزام شما کدام رفتار را می‌خواهد، سپس ماشین را از آستانه عبور داده و به خواب ببرید و تأیید کنید.
تحویل هم همان دقت را می‌خواهد. اگر هشدار را نمی‌توان نشان داد، آن را در صف بگذارید و پیش از نمایش نهایی دوباره بررسی کنید که نشست هدف هنوز وجود دارد؛ وگرنه کاربر درباره اتصالی که پیش‌تر پایان یافته هشدار می‌گیرد. قطع اجباری و تمدید اعتبارنامه از این مسیر بیرون می‌مانند، زیرا یادآوری‌ای که بی‌صدا سرنوشت اتصال را عوض می‌کند تصمیمی سیاستی است با لباس هشدار.