तुम्ही RDP विंडोच्या आत आहात, डेस्कटॉप स्क्रीनवर आहे, आणि त्या रिमोट मशीनवर चालणाऱ्या VPN क्लायंटमध्ये Connect दाबता। काही सेकंदांनंतर विंडो गोठते आणि नंतर बंद होते। टनेल वर आले, VPN लॉग नेमके तेच नोंदवेल, आणि ते संपूर्ण घटनेतील सर्वात कमी उपयुक्त तथ्य आहे। तुम्ही ज्या मशीनशी बोलत होते तिने तुम्हाला उत्तर देण्याची पद्धत बदलली म्हणून सत्र मरण पावले, त्यामुळे टनेलला हात लावण्यापूर्वी परतीचा मार्ग तपासा।

तुमचे सत्र प्रत्यक्षात वापरत असलेला एंडपॉइंट नोंदवा

तुमच्या RDP क्लायंटमध्ये लिहिलेला पत्ता रिमोट संगणक ज्या पत्त्यावर उत्तर देतो तोच असेल असे नाही। NAT, RD Gateway किंवा होस्टसमोरील लोड बॅलन्सर तो पुन्हा लिहू शकतात, आणि परतीचा मार्ग स्थापित कनेक्शनवर रिमोट मशीनला दिसणाऱ्या स्रोत पत्त्याने ठरतो। येथे चूक झाल्यास कधीही सहभागी न झालेला मार्ग शोधत तुम्ही निघाल।

रिमोट संगणकावर, VPN जोडण्यापूर्वी, स्थापित सत्रे यादी करा आणि तक्त्यातून पीअर पत्ता वाचा। नंतर तो त्या मशीनबाहेर कुठेतरी लिहून ठेवा, कारण सत्र पडल्यानंतर तुम्हाला तो वाचता येणार नाही।

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

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

त्या एंडपॉइंटला उत्तर देणारा मार्ग वाचा

Windows प्रत्येक गंतव्यासाठी एक इंटरफेस निवडते, आणि Find-NetRoute आत्ता घेणारा निर्णय दाखवते। जोडण्यापूर्वी तो पीअर पत्त्यावर चालवा, नंतर टनेल वर असताना पुन्हा, आणि दोन्ही उत्तरांमधील इंटरफेस इंडेक्स व पुढील हॉपची तुलना करा। इंटरफेस बदलणे हीच आउटपुटच्या एका ओळीतली सगळी बग।

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

फुल-टनेल प्रोफाइल टनेलमधून डीफॉल्ट मार्ग स्थापित करते, जसे Windows चे VPN राउटिंग मार्गदर्शक सांगते, म्हणून आता प्रत्येक उत्तर VPN मधून बाहेर पडते आणि समोरची बाजू तुमच्या क्लायंटकडे परत राउट करते का यावर अवलंबून असते। स्प्लिट-टनेल प्रोफाइल डीफॉल्टनुसार अधिक सुरक्षित आहे पण प्रतिरोधक नाही, कारण पीअर पत्ता व्यापणारा विशिष्ट मार्ग भौतिक डीफॉल्ट मार्गाला अजूनही हरवू शकतो। कोणत्याही परिस्थितीत प्रश्न तोच आहे: टनेल वर आल्यानंतर, पीअर पत्ता अजूनही सत्र आत आणलेल्या इंटरफेसवर सोडवला जातो का?

जर नाही, तर दुरुस्ती प्रोफाइलमध्ये किंवा VPN धोरणाच्या मालकाने मंजूर केलेल्या स्पष्ट अपवाद मार्गात आहे। घटनेच्या वेळी उत्पादन होस्टवर हाताने राउटिंग तक्ता संपादित करणे हा तात्पुरता उपाय अलेखी संरचना बनण्याचा मार्ग आहे।

फायरवॉल प्रोफाइलचा बदल पाहा

नवीन इंटरफेस दिसल्यावर वर्गीकृत होतो, आणि ते वर्गीकरण त्याचा रहदारी कोणत्या फायरवॉल प्रोफाइलनुसार मोजली जाईल हे ठरवते। Public श्रेणीत येणारा टनेल अडॅप्टर राउटिंग तक्ता परिपूर्ण दिसत असूनही येणारे RDP शांतपणे थांबवू शकतो। हा दुसरा अपयश मोड आहे, आणि तो वेगळे लक्षण देतो: मार्ग बरोबर आहे, पॅकेट येत आहेत, आणि होस्ट कनेक्शन नाकारतो।

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

टनेल इंटरफेसला जोडलेल्या प्रोफाइलची तुलना Remote Desktop नियम ज्या प्रोफाइलांना लक्ष्य करतात त्यांच्याशी करा। फक्त Domain आणि Private साठी सक्षम केलेला नियम Public म्हणून वर्गीकृत इंटरफेससाठी काहीही करत नाही, आणि कोणतीही मार्ग दुरुस्ती ते बदलत नाही। काही VPN क्लायंट रचनेनुसार स्थानिक सबनेट प्रवेशही मर्यादित करतात, ज्यामुळे दुसऱ्या नियंत्रणातून तीच अपयशाची रचना तयार होते।

तुम्ही परत येऊ शकता अशा ठिकाणाहून संक्रमण तपासा

संपूर्ण क्रम आउट-ऑफ-बँड कन्सोल किंवा दुसऱ्या व्यवस्थापन मार्गाने या क्रमाने करा: विद्यमान सत्राची खात्री करा, VPN जोडा, नवीन सत्र उघडा, नंतर VPN तोडा आणि अजून एक उघडा। प्रत्येक पायरी वेगळे संक्रमण तपासते, आणि पहिली अपयशी ठरलेली पायरी कोणते नियंत्रण जबाबदार आहे ते सांगते।

सुरू करण्यापूर्वीच रोलबॅक ठरवा, उदाहरणार्थ ठरलेल्या अंतरानंतर rasdial "Work VPN" /disconnect चालवणारे निर्धारित कार्य। ते गमावलेल्या सत्राचे साइट भेटीऐवजी पाच मिनिटांच्या व्यत्ययात रूपांतर करते, आणि संपूर्ण प्रक्रियेतील सर्वात स्वस्त विमा तोच आहे।

सत्र आधीच गेले असेल तेव्हा पुन्हा आत या

जर होस्ट आधीच पोहोचण्याबाहेर असेल, तर त्याच क्लायंटवरून नवीन RDP कनेक्शनचा प्रयत्न थांबवा आणि पर्यावरणाकडे आधीच असलेली पुनर्प्राप्ती चॅनेल वापरा: RD Gateway, हायपरव्हायझर कन्सोल, किंवा आउट-ऑफ-बँड व्यवस्थापन इंटरफेस। कन्सोल प्रवेश असलेल्या व्यक्तीला तेच Find-NetRoute आणि Get-NetConnectionProfile आदेश चालवायला सांगा, जेणेकरून पुरावे पुनर्प्राप्तीनंतरही टिकून राहतील।

मग सर्वात वेगवान नाही तर कायमची व्यवस्था ठरवा। एकतर VPN प्रोफाइल व्यवस्थापन मार्ग स्पष्टपणे जपते, किंवा व्यवस्थापन होस्टच्या डीफॉल्ट मार्गावर अवलंबून नसलेल्या चॅनेलवर जाते। दोन्ही टिकाऊ आहेत; अंदाजित गेटवे असलेला होस्ट मार्ग नाही। तुम्ही कोणता निवडला ते लिहा, आणि टिकून राहायचा असलेला पीअर पत्ता नोंदवा।

संबंधित लेख