रिमोट कम्प्युटर VPN मा जोडिँदा RDP किन जम्छ
VPN सफल हुन्छ र डेस्कटप जम्छ: टनेलले तपाईंको सत्रको फर्कने बाटो बदल्यो। पहिले पियर ठेगाना, रुट र फायरवाल प्रोफाइल लेख्नुहोस्।
तपाईं 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 प्रोफाइलले व्यवस्थापन बाटो स्पष्ट रूपमा जोगाउँछ, या व्यवस्थापन होस्टको डिफल्ट रुटमा निर्भर नहुने च्यानलमा जान्छ। दुवै टिकाउ छन्; अनुमानित गेटवे भएको होस्ट रुट होइन। तपाईंले कुन रोज्नुभयो लेख्नुहोस्, र टिक्नुपर्ने पियर ठेगाना अभिलेख गर्नुहोस्।