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 ग्राफिक्स चॅनेलबद्दल नाही। एका वेळी एक चल बदला आणि तीच स्क्रीन क्रिया पुन्हा करा जेणेकरून तुलनेला अर्थ असेल।

सत्र अजिबात उघडत नसेल, तर इथे थांबा, कारण ते गोठणे नाही तर पोहोचक्षमता आहे। अन्यथा लक्षण बदलणारी ट्रान्सपोर्ट सेटिंग ठेवा आणि क्लायंट आवृत्तीसह नोंदवा।