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शब्दांकडे नाही, टाइमस्टॅम्पकडे पाहा. मागील सत्राच्या सुरुवातीच्या वेळेसह येणाऱ्या सूचनेने चुकीची वस्तू जोडली आहे, आणि एका मुदतीसाठी दोन वेळा येणाऱ्या सूचनेचा अर्थ पाठवलेला ध्वज कधीही साठवला गेला नाही.
झोप, पुन्हा जोडणी आणि हरवलेली डिलिव्हरी
झोप दोन्ही साध्या रचना मोडते. मोनोटोनिक उलटी गिनती मशीन झोपल्यावर थांबते, भिंत-घड्याळाची मुदत पुढे सरकत राहते, आणि झोपेत चालू होणारा टाइमर उशिरा किंवा अजिबात पोहोचत नाही. तुमच्या गरजेला कोणते वर्तन हवे ते ठरवा, मग मर्यादा ओलांडून मशीनला झोपवा आणि खात्री करा.
पोहोचवण्यालाही तीच काळजी हवी. सूचना दाखवता येत नसेल तर ती रांगेत ठेवा, आणि शेवटी दाखवण्यापूर्वी लक्ष्य सत्र अजून आहे का ते पुन्हा तपासा; नाहीतर वापरकर्त्याला आधीच संपलेल्या कनेक्शनबद्दल इशारा दिला जातो. सक्तीचे डिस्कनेक्ट आणि क्रेडेन्शियल नूतनीकरण या मार्गाबाहेर राहतात, कारण कनेक्शनचे भवितव्य गुपचूप बदलणारा रिमाइंडर म्हणजे सूचनेच्या वेशातील धोरणाचा निर्णय आहे.