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 ग्राफिक्स च्यानलको बारेमा होइन। एक पटकमा एउटा चल बदल्नुहोस् र स्क्रिनको त्यही कार्य दोहोर्याउनुहोस् ताकि तुलनाको अर्थ होस्।

यदि सत्र कहिल्यै खुल्दैन भने यहीँ रोक्नुहोस्, किनकि त्यो जम्नु होइन, पहुँचयोग्यता हो। नत्र लक्षण बदल्ने ट्रान्सपोर्ट सेटिङ राख्नुहोस् र क्लाइन्ट संस्करणसँगै रेकर्ड गर्नुहोस्।