એક વપરાશકર્તા જોડાય છે, કામ કરે છે, પછી Microsoft Entra સાથેની પ્રમાણીકરણની મુદત પૂરી થઈ ગઈ હોવાના સંદેશ સાથે દર કલાકે એક વાર કનેક્શન તૂટી જાય છે. ફરી જોડાવાથી કામ થાય છે અને સ્ટોપવોચ પર ચક્ર પુનરાવર્તિત થાય છે. જ્યાં કંઈ જ તૈનાત કરવામાં આવ્યું ન હતું તેવા પોઇન્ટ-ટુ-સાઇટ ગેટવે પર આ પેટર્ન ટનલને બદલે ઓળખપત્ર તરફ ઇશારો કરે છે. Azure VPN Client 3.4.0 એ સ્થાપિત સેશન દરમિયાન Conditional Access સાઇન-ઇન ફ્રિકવન્સી લાગુ કરવાનું શરૂ કર્યું, જે નીતિ અગાઉના ક્લાયન્ટ ફક્ત સાઇન-ઇન વખતે જ મૂલ્યાંકન કરતા હતા.

નીચેની છ ચકાસણીઓ ક્રમમાં પૂરી કરો. દરેક કાં તો સમયપત્રકની પુષ્ટિ કરે છે અથવા તેને નકારી કાઢે છે, અને વહેલું અટકવું એ જ વ્યર્થમાં ગેટવે ફરીથી બનાવવાનો રસ્તો છે.

પગલું 1: ચોક્કસ સંદેશ વાંચો

શબ્દરચના સ્તરોને અલગ પાડે છે. Entra પ્રમાણીકરણની મુદત પૂરી થવાનો સંદેશ ટોકનનું નિવેદન છે; ટનલ કે સિક્યોરિટી એસોસિએશનની ભૂલ એવું નથી. વીતેલો સમય પણ લખો, કામકાજના દિવસની શરૂઆતથી નહીં, પણ જોડાણથી જોડાણ તૂટવા સુધી માપો.

જો વપરાશકર્તા તરત જ ફરી જોડાઈ શકે અને ગેટવે હજી પણ સ્વસ્થ ટનલ બતાવે, તો તમે ટોકનની મુદત પૂરી થવા જોઈ રહ્યા છો, મૃત પીઅર નહીં.

પગલું 2: ક્લાયન્ટની આવૃત્તિ મેળવો

આવૃત્તિ એપમાંથી વાંચો, ડિપ્લોયમેન્ટ રેકોર્ડમાંથી નહીં. ફેરફાર 3.4.0 સાથે આવ્યો, તેથી 3.3.1 અને તે પહેલાંની આવૃત્તિઓ નીતિને ધ્યાનમાં ન લેતાં સ્થાપિત ટનલને જીવંત રાખે છે. જૂના બિલ્ડ પરનું એક અસંચાલિત લેપટોપ સંપૂર્ણ કામ કરે છે જ્યારે બાકીની ટીમ દર કલાકે તૂટે છે, આ પ્રકારનું વિભાજન જ લોકોને ગેટવે તરફ પાછા મોકલે છે. આવૃત્તિ ક્લાયન્ટની મિલકત છે, અને કયું બિલ્ડ જોડાયેલું છે તે ગેટવે જાણતું નથી.

પહેલા એક પરીક્ષણ ઉપકરણ અપડેટ કરો અને ઘડિયાળ જુઓ. અપડેટ પછી નીતિના અંતરાલે તૂટવા લાગે તેવું ઉપકરણ ઉત્પાદન નીતિને સ્પર્શ કર્યા વિના જ પ્રક્રિયાની પુષ્ટિ કરે છે.

પગલું 3: નીતિ ક્યાં રહે છે તે શોધો

સાઇન-ઇન ફ્રિકવન્સી એ Azure VPN એન્ટરપ્રાઇઝ એપ્લિકેશનને લક્ષ્ય બનાવતી નીતિનું Conditional Access સેટિંગ છે. તે VPN ગેટવે સંસાધન પર નથી, પોઇન્ટ-ટુ-સાઇટ રૂપરેખાંકનમાં નથી, અને ક્લાયન્ટ પ્રોફાઇલમાં પણ નથી. નીતિઓની યાદીમાં Azure VPN એપ શોધો અને સેશન નિયંત્રણો વાંચો.

એક વપરાશકર્તા પર બે નીતિઓ લાગુ પડી શકે છે, અને કડક નીતિ જીતે છે, તેથી તમે કદી સેટ ન કર્યું હોય તેવું મૂલ્ય પણ અમલમાં હોઈ શકે. એપ-વિશિષ્ટ નીતિ ઉપરાંત ટેનન્ટ-વ્યાપી બેઝલાઇન નીતિ પણ તપાસો. રિપોર્ટનો વ્યાપ પણ મહત્વપૂર્ણ છે: જે નીતિ કોઈ જૂથને બાકાત રાખે છે તે અલગ વર્તન ધરાવતી વસ્તી બનાવે છે, જેની સ્પષ્ટ સમજૂતી હોતી નથી.

પગલું 4: ગણતરી કરો

આ ક્લાયન્ટ માટે Microsoft દસ્તાવેજ કરેલા વર્તનમાં જોડાણ તૂટવાની ઘટના સાઇન-ઇન ફ્રિકવન્સી મૂલ્યના એક કલાક પછી આવે છે, તેથી સાત કલાકની ફ્રિકવન્સી લગભગ આઠ કલાકનું જોડાણ આપે છે. આ ઓફસેટને કારણે જ આઠ કલાકના કામકાજના દિવસ માટે પસંદ કરેલું મૂલ્ય બપોર પછી તૂટેલું દેખાય છે, જ્યારે નવ કલાકની ચકાસણી ઠીક દેખાય છે. કંઈપણ બદલતા પહેલા ફરિયાદને સંખ્યામાં ફેરવો: જોડાણનો સમય, જોડાણ તૂટવાનો સમય, તફાવત, પછી નીતિના મૂલ્યમાં એક કલાક ઉમેરીને સરખાવો.

જો તફાવત તે સરવાળા સાથે મેળ ખાતો ન હોય, તો સમયપત્રકની પરિકલ્પના ખોટી છે અને નીતિ સમાયોજિત કરવી બંધ કરવી જોઈએ.

પગલું 5: સમયપત્રક અને રીકી અલગ કરો

IPsec રીકી, ડેડ પીઅર શોધ અને નિષ્ક્રિય સમયમર્યાદા ટ્રાફિકના જથ્થા કે મૌન સાથે જોડાયેલા અનિયમિત ડ્રોપ બનાવે છે, સ્ટોપવોચ સાથે નહીં. સ્થાનાંતરણની વચ્ચે તૂટેલો વપરાશકર્તા અને નિષ્ક્રિય બપોરના ભોજન પછી તૂટેલો વપરાશકર્તા જુદી જુદી પ્રક્રિયાઓનું વર્ણન કરે છે. જોડાણ તૂટવાના એક મિનિટ પહેલા વપરાશકર્તા શું કરી રહ્યો હતો તે પૂછો.

પ્રમાણપત્રની સમસ્યાઓ ફરી અલગ દેખાય છે: ક્લાયન્ટ કામ કરતું સેશન છોડવાને બદલે જોડાવામાં નિષ્ફળ જાય છે, અને નિષ્ફળતા તાત્કાલિક હોય છે. જે MFA પ્રોમ્પ્ટ કદી પૂરો થતો નથી તે હેંગ તરીકે દેખાય છે, સ્વચ્છ કલાકદીઠ ડ્રોપ અને પછી સફળ પુનઃજોડાણ તરીકે નહીં.

પગલું 6: આશ્ચર્ય વિના તેને રોલ આઉટ કરો

સ્ટોર દ્વારા વપરાશકર્તાઓ સુધી પહોંચતા પહેલા ક્લાયન્ટ અપડેટની જાહેરાત કરો, કારણ કે વર્તનમાં ફેરફાર ક્લાયન્ટ સાથે જ આવે છે. જરૂરિયાત પરથી ફ્રિકવન્સી પસંદ કરો: ઉપયોગિતા માટે કામકાજનો દિવસ આવરી લેતું મૂલ્ય, અથવા ખોવાયેલા લેપટોપે ઝડપથી ઍક્સેસ ગુમાવવી હોય તો ટૂંકું મૂલ્ય. કઈ જરૂરિયાત જીતી તે નોંધો, કારણ કે એક જ સેટિંગ સંરક્ષણ અને ફરિયાદ બંને ઉત્પન્ન કરે છે. પછી જૂના બિલ્ડ પર ચાલેલા પાયલટ પરથી અનુમાન કરવાને બદલે નવા બિલ્ડ પર ચાલતા ઉપકરણ પર પસંદગીની પુષ્ટિ કરો.

સંદેશ, આવૃત્તિ, નીતિનું મૂલ્ય અને માપેલું અંતરાલ એક નોંધમાં રાખો. તે રેકોર્ડ આગલા રિપોર્ટનો જવાબ એક મિનિટમાં આપે છે, ફરીથી બનાવવામાં નહીં.

સંબંધિત લેખો