VPN ઉપર RDP થીજી જવું: ઇનપુટ હજી કામ કરે છે, તેથી ટ્રાન્સપોર્ટ ચકાસો
કામ કરતા ઇનપુટ સાથે થીજેલી RDP છબી પડી ગયેલી ટનલ નથી. રૂટ બદલતાં પહેલાં ક્લાયન્ટ ટ્રાન્સપોર્ટ, UDP નીતિ અને એક-હોસ્ટ કેસ ચકાસો.
જ્યારે છબી અપડેટ થવાનું બંધ થાય છે પણ માઉસ હજી દૂરસ્થ ડેસ્કટોપ પર સરકે છે, ત્યારે સ્પષ્ટ નિષ્કર્ષ એ છે કે VPN પડી ગયું. આ નિષ્કર્ષ સામાન્ય રીતે ખોટો હોય છે. કામ કરતા ઇનપુટ સાથે થીજેલી ફ્રેમનો અર્થ એ છે કે સેશન અને તેનું ઇનપુટ ચેનલ જીવંત છે, જે ખામીને રૂટિંગ કે ક્રેડેન્શિયલ તરફ નહીં પણ ગ્રાફિક્સ ટ્રાન્સપોર્ટ તરફ ધકેલે છે. બે ઝડપી નિરીક્ષણો વપરાશકર્તાઓ એક જ શબ્દથી વર્ણવેલી ત્રણ નિષ્ફળતાઓને અલગ પાડે છે.
થીજવું તમને શું નથી કહેતું
દૂરસ્થ ડેસ્કટોપ ઇનપુટ અને સ્ક્રીન અપડેટ્સ TCP 3389 પર લઈ જાય છે, અને વર્તમાન Windows ક્લાયન્ટ્સ સ્ટ્રીમના ગ્રાફિક્સ-ભારે ભાગ માટે UDP ટ્રાન્સપોર્ટ ઉમેરી શકે છે. જે ટનલ મોટા ડેટાગ્રામને ફ્રેગમેન્ટ કરે છે અથવા ડ્રોપ કરે છે, ત્યાં વિશ્વસનીય ચેનલ કીસ્ટ્રોક લઈ જવાનું ચાલુ રાખે છે જ્યારે ગ્રાફિક્સ ચેનલ અટકી જાય છે. પરિણામ એ અટકેલી છબી અને પ્રતિસાદ આપતા કીબોર્ડનું વિચિત્ર સંયોજન છે. આ એ પણ સમજાવે છે કે ફરી કનેક્ટ થવાથી ક્યારેક લક્ષણ એક મિનિટ માટે મટે છે અને પછી પાછું આવે છે.
જે સેશન ડિસ્કનેક્ટ થઈને ફરી કનેક્ટ થાય છે તે બીજી ખામી છે, અને જે બિલકુલ ખૂલતું નથી તે ત્રીજી છે. પહેલાં આકારનું નામ આપવાથી તમે ખોટું સ્તર ચકાસતા અટકો છો.
બે આદેશોથી ત્રણ નિષ્ફળતાઓ અલગ કરો
પહોંચનીયતા બાકાત કરવી સસ્તી છે. ક્લાયન્ટથી RDP પોર્ટ ચકાસો, પછી હોસ્ટ પર સેશનની સ્થિતિ વાંચો.
Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-hostનિષ્ફળ TCP પરીક્ષણનો અર્થ છે કે સેશન ક્યારેય ખૂલ્યું નથી, તેથી તેને થીજવું નહીં પણ ફાયરવોલ, સ્કોપ કે સેવાની સમસ્યા ગણો. સક્રિય સેશન સાથે સફળ પરીક્ષણ પુષ્ટિ કરે છે કે નિયંત્રણ ચેનલ અસ્તિત્વમાં છે, જે બરાબર થીજેલી છબીનો કેસ છે. હોસ્ટ ક્વેરી એવા ખાતામાંથી ચલાવો જેને સેશન જોવાની પરવાનગી છે, કારણ કે પરવાનગીની ભૂલ ખાલી યાદી જેવી દેખાય છે. સેશન ID અને સ્થિતિ નોંધો, કારણ કે પોતાનું ID રાખતું ડિસ્કનેક્ટેડ સેશન સક્રિય સેશન જેવું નથી.
UDP ટ્રાન્સપોર્ટ બંધ કરો અને સરખાવો
જો ફક્ત ડિસ્પ્લે અટકે છે, તો એક સમયે એક ફેરફાર કરીને ક્લાયન્ટ ટ્રાન્સપોર્ટ સરખાવો. બિલ્ટ-ઇન ક્લાયન્ટ અને Store ક્લાયન્ટ એક જ સ્ટેક વહેંચતા નથી, અને નીચેની નીતિ બિલ્ટ-ઇન ક્લાયન્ટમાંથી UDP દૂર કરે છે.
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDPમૂલ્ય 1 નો અર્થ છે કે તે ક્લાયન્ટ માટે UDP પહેલેથી બંધ છે, તેથી આ સેટિંગ છતાં થીજવું UDP પથની સમસ્યા નથી. જ્યારે મૂલ્ય ગેરહાજર હોય, ત્યારે નીતિ સક્રિય કરો, ફરી કનેક્ટ કરો અને પહેલાં થીજી ગયેલી બરાબર એ જ ક્રિયા પુનરાવર્તિત કરો. બંને ફેરફારો ભેગા કરવાને બદલે Store ક્લાયન્ટને અલગ પગલા તરીકે ચકાસો, નહીંતર તમને ખબર નહીં પડે કે કયો મહત્વનો હતો. ક્લાયન્ટ સંસ્કરણ તમારી નોંધમાં રાખો, કારણ કે Windows આવૃત્તિઓ દરમિયાન ટ્રાન્સપોર્ટ વર્તન બદલાયું છે.
જ્યારે એક હોસ્ટ થીજી જાય પણ બાકીના ઠીક હોય
અન્યથા સ્વસ્થ સબનેટ પર એક જ નિષ્ફળ હોસ્ટ ટનલથી દૂર ઇશારો કરે છે. VPN સેટિંગ્સને સ્પર્શ કરતાં પહેલાં પથનું MTU અને દૂરસ્થ ડિસ્પ્લે સ્ટેક ચકાસો.
ping -f -l 1472 rdp-host.example.comએક જવાબ સાબિત કરે છે કે પથ તે માપમાં ફ્રેગમેન્ટેશન વિના પૂર્ણ-માપનું પેકેટ લઈ જાય છે, જ્યારે ન-ફ્રેગમેન્ટ ધ્વજ સાથેની નિષ્ફળતા સૂચવે છે કે ટનલના MTU પર ધ્યાન આપવાની જરૂર છે. જો 1472 બાઇટ પસાર થાય અને ફક્ત તે જ હોસ્ટ થીજે, તો નેટવર્કને બદલે તેના ગ્રાફિક્સ ડ્રાઇવર અને લોડ તપાસો. એ જ મશીન પર ઝડપી ફાઇલ કૉપી થ્રુપુટ વિશે કંઈક કહે છે, RDP ગ્રાફિક્સ ચેનલ વિશે નહીં. એક સમયે એક ચલ બદલો અને સ્ક્રીન પરની એ જ ક્રિયા પુનરાવર્તિત કરો જેથી સરખામણીનો અર્થ થાય.
જો સેશન બિલકુલ ખૂલતું નથી, તો અહીં થોભો, કારણ કે તે થીજવું નહીં પણ પહોંચનીયતા છે. નહીંતર જે ટ્રાન્સપોર્ટ સેટિંગે લક્ષણ બદલ્યું તે રાખો અને ક્લાયન્ટ સંસ્કરણ સાથે નોંધો.