VPN દ્વારા રિમોટ ડેસ્કટોપ: તમે કઈ નિષ્ફળતામાં છો?

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

એક જેવા દેખાતા ચાર નિષ્ફળતા

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

કાર્યકારી આંતરિક વેબસાઇટ ચારમાંથી એક પણ સાબિત કરતી નથી. તે સાબિત કરે છે કે તે જ નેટવર્ક પરના હોસ્ટે બીજા પોર્ટ પર બીજી સેવા સાથે જવાબ આપ્યો. તેને રૂટિંગ વિશેના પુરાવા તરીકે લો, વધુ કંઈ નહીં.

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

શું 3389 પર કંઈ સાંભળે છે?

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

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

પછી હોસ્ટ નહીં, પોર્ટનું પરીક્ષણ કરો. 3389 પર પૂર્ણ થયેલો TCP હેન્ડશેક પહોંચને તેની ઉપરની દરેક વસ્તુથી અલગ પાડે છે:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

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

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

રૂપરેખા વાંચતાં પહેલાં સંદેશ વાંચો

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

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

સત્ર લોગિન પોતાની એક સીમા છે

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

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

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

સત્ર શું ખસેડી શકે છે, અને ક્યાં રહે છે

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

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