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: आश्चर्याशिवाय तैनात करा

क्लायंट अद्ययावत स्टोअरमार्फत वापरकर्त्यांपर्यंत पोहोचण्यापूर्वी जाहीर करा, कारण वर्तनातील बदल क्लायंटसोबत येतो. वारंवारता गरजेनुसार निवडा: वापरण्यायोग्यतेसाठी कामकाजाचा दिवस झाकणारे मूल्य, किंवा हरवलेल्या लॅपटॉपला लवकर प्रवेश गमवायचा असेल तर लहान मूल्य. कोणती गरज जिंकली ते लिहा, कारण तीच सेटिंग संरक्षण आणि तक्रार दोन्ही निर्माण करते. नंतर निवड नवीन बिल्ड असलेल्या उपकरणावर पुष्टी करा, जुन्या बिल्डच्या पायलटवरून अंदाज न लावता.

संदेश, आवृत्ती, धोरणाचे मूल्य आणि मोजलेला अंतर एकाच टिपेत ठेवा. ती नोंद पुढील अहवालाला पुनर्बांधणीऐवजी एका मिनिटात उत्तर देते.