Azure VPN Client 3.4 हर घंटे डिस्कनेक्ट होता है: साइन-इन आवृत्ति

एक उपयोगकर्ता जुड़ता है, काम करता है, और फिर हर घंटे एक बार इस संदेश के साथ डिस्कनेक्ट हो जाता है कि Microsoft Entra के साथ प्रमाणीकरण समाप्त हो गया। दोबारा जुड़ना काम करता है और चक्र स्टॉपवॉच की तरह दोहराता है। एक point-to-site गेटवे पर जहाँ कुछ भी तैनात नहीं किया गया, वह पैटर्न क्रेडेंशियल की ओर इशारा करता है, टनल की ओर नहीं। Azure VPN Client 3.4.0 ने सशर्त एक्सेस की साइन-इन आवृत्ति को पहले से स्थापित सत्र के दौरान लागू करना शुरू किया, ऐसी नीति जिसे पुराने क्लाइंट केवल साइन-इन पर आँकते थे।

नीचे दी गई छह जाँचें क्रम से करें। हर जाँच या तो शेड्यूल की पुष्टि करती है या उसे खारिज करती है, और जल्दी रुकना गेटवे को बिना कारण फिर से बनाने का तरीका है।

चरण 1: सटीक संदेश पढ़ें

शब्दावली परतों को अलग करती है। Entra प्रमाणीकरण के समाप्त होने का संदेश टोकन के बारे में है; टनल या सुरक्षा संबंध की त्रुटि नहीं। बीता समय भी लिखें, जो जुड़ने से डिस्कनेक्ट तक मापा जाए, कार्यदिवस की शुरुआत से नहीं।

अगर उपयोगकर्ता तुरंत दोबारा जुड़ सकता है और गेटवे अब भी स्वस्थ टनल दिखाता है, तो आप टोकन की समाप्ति देख रहे हैं, मृत पीयर नहीं।

चरण 2: क्लाइंट का संस्करण जानें

संस्करण ऐप में पढ़ें, तैनाती रिकॉर्ड में नहीं। बदलाव 3.4.0 के साथ आया, इसलिए 3.3.1 और पुराने संस्करण नीति की परवाह किए बिना स्थापित टनल को जीवित रखते हैं। एक बिना प्रबंधन वाला लैपटॉप पुराने बिल्ड के साथ बिल्कुल ठीक चलता है जबकि बाकी टीम हर घंटे गिरती है: यही वह विभाजन है जो लोगों को गेटवे की ओर वापस भेजता है। संस्करण क्लाइंट का गुण है, और गेटवे नहीं जानता कि कौन सा बिल्ड जुड़ा है।

पहले एक परीक्षण डिवाइस अपडेट करें और घड़ी देखें। अपडेट के बाद नीति के अंतराल पर गिरने वाला डिवाइस उत्पादन नीति को छुए बिना तंत्र की पुष्टि करता है।

चरण 3: पता लगाएँ कि नीति कहाँ रहती है

साइन-इन आवृत्ति उस नीति में सशर्त एक्सेस की सेटिंग है जो Azure VPN एंटरप्राइज़ ऐप को लक्षित करती है। यह VPN गेटवे संसाधन पर नहीं है, point-to-site कॉन्फ़िगरेशन में नहीं है, और क्लाइंट प्रोफ़ाइल में नहीं है। नीति सूची में Azure VPN ऐप खोजें और सत्र नियंत्रण पढ़ें।

एक उपयोगकर्ता पर दो नीतियाँ लागू हो सकती हैं, और सख्त वाली जीतती है, इसलिए जो मान आपने कभी सेट नहीं किया वही प्रभावी हो सकता है। पूरे टेनेंट की आधार नीति और ऐप-विशिष्ट नीति, दोनों जाँचें। रिपोर्ट का दायरा भी मायने रखता है: समूह को बाहर रखने वाली नीति अलग व्यवहार वाली आबादी बनाती है और स्पष्ट व्याख्या नहीं देती।

चरण 4: गणना करें

डिस्कनेक्ट साइन-इन आवृत्ति के मान के एक घंटे बाद होता है, उस व्यवहार में जिसे Microsoft इस क्लाइंट के लिए दर्ज करता है, इसलिए सात घंटे की आवृत्ति लगभग आठ घंटे कनेक्टिविटी देती है। इसी अंतराल के कारण आठ घंटे के कार्यदिवस के लिए चुना गया मान दोपहर बाद टूटा दिखता है जबकि नौ घंटे का परीक्षण ठीक लगता है। कुछ भी बदलने से पहले शिकायत को संख्याओं में बदलें: जुड़ने का समय, डिस्कनेक्ट का समय, अंतर, फिर नीति के मान और एक घंटे से तुलना करें।

अगर अंतर उस योग से मेल नहीं खाता, तो शेड्यूल की परिकल्पना गलत है और नीति को समायोजित करना बंद कर दें।

चरण 5: शेड्यूल को rekey से अलग करें

IPsec rekey, मृत पीयर का पता लगाना और निष्क्रियता की समय-सीमाएँ अनियमित कटौतियाँ पैदा करती हैं जो ट्रैफ़िक की मात्रा या खामोशी से जुड़ी होती हैं, स्टॉपवॉच से नहीं। ट्रांसफ़र के बीच में गिरा उपयोगकर्ता और निष्क्रिय दोपहर के भोजन के बाद गिरा उपयोगकर्ता अलग-अलग तंत्र बता रहे हैं। पूछें कि डिस्कनेक्ट से पहले के मिनट में उपयोगकर्ता क्या कर रहा था।

प्रमाणपत्र की समस्याएँ फिर अलग दिखती हैं: क्लाइंट चल रहा सत्र खोने के बजाय जुड़ ही नहीं पाता, और विफलता तुरंत होती है। कभी पूरा न होने वाला MFA अनुरोध अटकाव के रूप में दिखता है, साफ़ हर घंटे की कटौती और फिर सफल पुनः कनेक्शन के रूप में नहीं।

चरण 6: बिना आश्चर्य के तैनात करें

क्लाइंट अपडेट की घोषणा स्टोर के ज़रिए उपयोगकर्ताओं तक पहुँचने से पहले करें, क्योंकि व्यवहार का बदलाव क्लाइंट के साथ आता है। आवृत्ति आवश्यकता से चुनें: उपयोगिता के लिए कार्यदिवस को ढकने वाला मान, या छोटा मान यदि खोया लैपटॉप जल्दी पहुँच खो दे। लिखें कि कौन सी आवश्यकता जीती, क्योंकि वही सेटिंग सुरक्षा और शिकायत दोनों पैदा करती है। फिर चयन की पुष्टि नए बिल्ड वाले डिवाइस पर करें, पुराने बिल्ड वाले पायलट से अनुमान लगाने के बजाय।

संदेश, संस्करण, नीति का मान और मापा गया अंतराल एक ही नोट में रखें। वह रिकॉर्ड अगली रिपोर्ट का जवाब एक मिनट में देता है, न कि पुनर्निर्माण से।