VPN पर RDP फ्रीज़: इनपुट अब भी काम करता है, इसलिए ट्रांसपोर्ट जाँचें

जब छवि अपडेट होना बंद हो जाता है लेकिन माउस दूरस्थ डेस्कटॉप पर फिसलता रहता है, तो स्पष्ट निष्कर्ष यह होता है कि 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 ग्राफ़िक्स चैनल के बारे में नहीं। एक बार में एक चर बदलें और स्क्रीन पर वही क्रिया दोहराएँ ताकि तुलना का अर्थ हो।

अगर सत्र बिल्कुल नहीं खुलता, तो यहीं रुकें, क्योंकि वह फ्रीज़ नहीं बल्कि पहुँच है। अन्यथा वह ट्रांसपोर्ट सेटिंग रखें जिसने लक्षण बदला और उसे क्लाइंट संस्करण के साथ दर्ज करें।