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शब्दों के बजाय टाइमस्टैम्प देखें। पिछले सत्र के शुरुआती समय के साथ आने वाली सूचना ने गलत वस्तु बाँधी है, और एक समय-सीमा के लिए दो बार आने वाली सूचना का मतलब है कि भेजा-गया ध्वज कभी सहेजा ही नहीं गया।
स्लीप, फिर से जुड़ना और छूटी हुई डिलीवरी
स्लीप दोनों भोले डिज़ाइन तोड़ देती है। मोनोटोनिक काउंटडाउन मशीन सोते समय रुक जाता है, दीवार-घड़ी की समय-सीमा चलती रहती है, और स्लीप के दौरान बजने वाला टाइमर देर से पहुँचता है या बिलकुल नहीं पहुँचता। तय करें कि आपकी आवश्यकता को कौन-सा व्यवहार चाहिए, फिर थ्रेशोल्ड पार करके मशीन को सुलाएँ और पुष्टि करें।
पहुँचाना भी उसी सावधानी का हक़दार है। अगर सूचना दिखाई नहीं जा सकती, तो उसे कतार में रखें, और अंत में दिखाने से पहले फिर जाँचें कि लक्ष्य सत्र अब भी मौजूद है; वरना उपयोगकर्ता को ऐसे कनेक्शन के बारे में चेतावनी मिलती है जो पहले ही समाप्त हो चुका है। ज़बरदस्ती डिस्कनेक्ट और क्रेडेंशियल नवीनीकरण इस रास्ते से बाहर रहते हैं, क्योंकि कनेक्शन का भाग्य चुपचाप बदलने वाला रिमाइंडर सूचना के वेश में नीति का निर्णय है।