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: आश्चर्य बिना तैनाथ गर्नुहोस्

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

सन्देश, संस्करण, नीतिको मान र नापिएको अन्तराल एउटै टिप्पणीमा राख्नुहोस्। त्यो अभिलेखले अर्को प्रतिवेदनलाई पुनर्निर्माणको सट्टा एक मिनेटमा जवाफ दिन्छ।