Cisco Secure Client RDP સત્રમાંથી VPN સ્થાપિત કરવા અટકાવે છે

સાઇન-ઇન સફળ થાય છે અને ટનલ તો પણ ઉપર આવતી નથી. આ સંયોજન લોકોને ગૂંચવે છે કારણ કે તેઓ તેને પ્રમાણીકરણની સમસ્યા તરીકે વાંચે છે અને પછી એવા ઓળખપત્રો રીસેટ કરવામાં બપોર પસાર કરે છે જે ક્યારેય સમસ્યા ન હતા. Cisco Secure Client ખાસ કરીને એટલા માટે VPN સ્થાપિત કરવાનો ઇનકાર કરી શકે છે કારણ કે પ્રયાસ Remote Desktop સત્રમાંથી આવ્યો છે, અને તે નિર્ણય ક્લાયન્ટ બાજુની નીતિથી લેવાય છે.

કનેક્શન પ્રવાહમાં આ ક્યાં દેખાય છે

ક્લાયન્ટને ઉપરથી નીચે જુઓ. પ્રોફાઇલ લોડ થાય છે, ઓળખપત્રો એકત્ર થાય છે અને પ્રમાણીકરણ પૂર્ણ થાય છે. પછી, કોઈ ટનલ બનતા પહેલાં, ક્લાયન્ટ પોતાની સત્ર અને સ્થાપના સેટિંગ્સને જે પર્યાવરણમાં છે તેની સામે મૂલ્યાંકન કરે છે.

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

જે સેટિંગ ખરેખર નિર્ણય કરે છે

Windows VPN Establishment નીતિ સંબંધિત નિયંત્રણ છે અને તેના બે દસ્તાવેજી મૂલ્યો છે: ફક્ત સ્થાનિક વપરાશકર્તાઓ, અને દૂરસ્થ વપરાશકર્તાઓને મંજૂરી. બીજું સમર્થિત ગોઠવણીમાં Remote Desktop સત્રમાંથી ટનલ સ્થાપિત કરવાની મંજૂરી આપે છે. પ્રથમ ઘણા એન્ટરપ્રાઇઝ પ્રોફાઇલમાં મૂળભૂત વલણ છે.

તેને Windows Logon Enforcement સાથે ભેળવશો નહીં, જેને પ્રોફાઇલ માર્ગદર્શિકા સાઇન-ઇન સત્રો વિશે અલગ નીતિ તરીકે દસ્તાવેજીકૃત કરે છે. એક નિયંત્રિત કરે છે કયું સત્ર ટનલ બનાવી શકે, બીજું એક સાથેના અથવા સાઇન-ઇન પહેલાંના વર્તનને નિયંત્રિત કરે છે. ખોટું બદલવાથી કોઈ દૃશ્યમાન અસર થતી નથી.

ખરેખર લાગુ થયેલી પ્રોફાઇલ વાંચો

સંચાલિત તૈનાતીમાં ક્લાયન્ટ તેની પ્રોફાઇલ હેડએન્ડ અથવા સંચાલિત સ્થાનમાંથી મેળવે છે, અને ડિસ્ક પર સંપાદિત નકલ ઘણી વાર અમલમાં હોય તે નથી. તેથી સ્થાનિક XML ફેરફાર સાચો લાગી શકે અને કંઈપણ બદલાય નહીં.

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

ટનલ ઉપર આવ્યા પછીનો RDP માર્ગ

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

ફેરફાર પહેલાં પુનઃપ્રાપ્તિ ચેનલનું આયોજન કરો: કન્સોલ પ્રવેશ, આઉટ-ઓફ-બેન્ડ સંચાલન માર્ગ અથવા દસ્તાવેજીકૃત પુનઃકનેક્શન પ્રક્રિયા. પછી નક્કી કરવાનો અર્થ સામાન્ય રીતે મશીન સુધીની મુસાફરી થાય છે.

નીતિ ટાળવા માટે સત્ર ચોરવાની યુક્તિઓ, વૈકલ્પિક રિમોટ-કંટ્રોલ સાધનો અથવા સ્ક્રિપ્ટમાં લખેલો પાસવર્ડ વાપરશો નહીં. જો સંસ્થા આ કાર્યપ્રવાહને અધિકૃત કરતી નથી, તો સાચું પગલું એ સંચાલન માર્ગ છે જેને તે સમર્થન આપે છે.

વ્યવસ્થાપકને શું મોકલવું

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

છેલ્લી સરખામણી જ સમય બચાવે છે, કારણ કે તે સત્ર-નીતિના ઇનકારને સમગ્ર ઉપકરણની નિષ્ફળતાથી અલગ કરે છે.

મંજૂર ફેરફાર પછી ચકાસો

પ્રોફાઇલ અપડેટ થયા પછી નવું RDP સત્ર સ્થાપિત કરો અને ફરી જોડાઓ, પછી ડિસ્કનેક્શન ક્રમ જાણી જોઈને કરો. ખાતરી કરો કે ટનલ ઉપર આવે છે, સંચાલન માર્ગ ટકી રહે છે અને તમારું ખાતું હજી ડેસ્કટોપમાં સાઇન ઇન કરી શકે છે.

VPN પ્રવેશ, સત્ર ટકી રહેવું અને Windows સાઇન-ઇન પરવાનગી ત્રણ અલગ ચકાસણીઓ છે. એક પાસ થવાથી બીજી બે વિશે કંઈ કહેવાતું નથી.