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 का मार्गदर्शन समर्थित एक्सपोज़र विकल्प बताता है, और दबाव में जोड़े गए सार्वजनिक श्रोता से यह बेहतर संदर्भ है।