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