VPN क्लाइंट इंस्टॉल के बाद RDP रुक जाता है? फ़ायरवॉल ज़िम्मेदार है

उपभोक्ता VPN क्लाइंट का इंस्टॉलेशन पूरा होने के कुछ मिनट बाद भी पोर्टल कहता है कि VM चल रहा है, सार्वजनिक IP नहीं बदला, और RDP जवाब नहीं देता। लोग आमतौर पर मानते हैं कि VM क्रैश हो गया या नेटवर्क सुरक्षा समूह बदल गया, और दोनों आमतौर पर ग़लत होते हैं। जो बदला है वह Windows फ़ायरवॉल प्रोफ़ाइल है जिसमें मशीन है, और पहले मिलने वाला RDP नियम अब नहीं मिलता। मरम्मत RDP पर निर्भर न करने वाले रास्ते से एक शेल लेने से शुरू होती है।

VM चल रहा है; नियम मिलना बंद हो गया

Windows में फ़ायरवॉल नियमों के साथ प्रोफ़ाइल सेट होता है, और निजी या डोमेन तक सीमित नियम का कोई असर नहीं होता जब तक मशीन सार्वजनिक प्रोफ़ाइल पर है। VPN इंस्टॉलर एडेप्टर और रूट जोड़ते हैं, और उनमें से कई साइड इफ़ेक्ट के रूप में सार्वजनिक को कड़ा करते हैं। लिसनर 3389 से बंधा रहता है और पैकेट आते रहते हैं, लेकिन प्रोफ़ाइल की असंगति उन्हें बाहर फेंक देती है।

पावर स्थिति और पहुँच अलग-अलग तथ्य हैं, और बंद पोर्ट वाला चलता VM बाहर से ठीक वैसा ही दिखता है जैसा क्रैश हुआ।

कुछ भी बदलने से पहले पोर्ट जाँचें। 3389 पर कनेक्ट करने की कोशिश समय-सीमा पर समाप्त होती है जबकि गेस्ट एजेंट कमांड अब भी आउटपुट दे रहा है, यह होस्ट फ़ायरवॉल की ओर संकेत करता है। पोर्ट जवाब देता हो लेकिन RDP अब भी विफल हो, इसका अर्थ है कि खराबी नेटवर्क परत के ऊपर है, और यह मरम्मत उसे नहीं छुएगी। दोनों में से आपने कौन-सी स्थिति देखी, लिख लें, क्योंकि बाकी योजना उसी पर निर्भर है।

दो द्वार स्वतंत्र रूप से बंद होते हैं

फ़ैब्रिक नीति पहले चलती है: नेटवर्क सुरक्षा समूह पैकेट को गेस्ट से पहले देखता है। यह क्रम होस्ट द्वारा पैकेट गिराए जाने पर बेहतरीन NSG प्रविष्टि को बेकार बना देता है, और फ़ैब्रिक द्वारा मना किए जाने पर खुले होस्ट नियम को बेकार बना देता है। उन्हें अलग द्वार मानें और हर एक को अलग से जाँचें।

पोर्टल या CLI में NSG के प्रभावी नियम पढ़ें, फिर उनकी तुलना गेस्ट के अपने नियमों से करें। यह न मानें कि आपको याद आख़िरी बदलाव ही लागू हुआ है।

उपभोक्ता क्लाइंट Windows फ़ायरवॉल के नीचे ट्रैफ़िक रोकने वाला फ़िल्टर ड्राइवर या किल स्विच भी इंस्टॉल कर सकता है। अगर फ़ायरवॉल नियम सही दिखते हैं और पोर्ट अब भी विफल हो, तो वही परत अगला संदिग्ध है।

गेस्ट एजेंट को वापसी का रास्ता बनाएँ

दूरस्थ निष्पादन की दो सुविधाएँ, Run Command और Custom Script Extension, फ़ैब्रिक एजेंट के ज़रिए गेस्ट के अंदर चलती हैं। किसी को भी RDP की ज़रूरत नहीं, इसलिए फ़ायरवॉल की ग़लती उन पर असर नहीं डालती। दोनों स्क्रिप्ट का आउटपुट लौटाती हैं, जिससे वे निदान और मरम्मत दोनों की चैनल बन जाती हैं।

दोनों में से कोई भी बदलने से पहले सक्रिय प्रोफ़ाइल और RDP नियम पढ़ें:

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

उस प्रोफ़ाइल पर इनबाउंड नियम फिर से सक्षम करना अस्थायी कदम है, लक्ष्य नहीं। इसे सत्र पाने के लिए इस्तेमाल करें, फिर खाई ठीक से बंद करें:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

वह स्विच प्रोफ़ाइल के हर इनबाउंड नियम को खोलता है, सिर्फ़ RDP को नहीं। सत्र मिलने पर उसे सीमित नियम से बदलें और वे सेटिंग्स बहाल करें जो आप वास्तव में चाहते हैं। अगर एजेंट भी उपलब्ध न हो, तो सीरियल कंसोल या फिर से बनाई गई डिस्क विकल्प है, और एजेंट को स्वस्थ रखने की व्यावहारिक वजह यही है।

सत्र बंद करने से पहले खाई सँकरी करें

अस्थायी प्रोफ़ाइल बदलाव उस प्रोफ़ाइल के हर इनबाउंड नियम के लिए खुला रखा गया दरवाज़ा है। उसे आपके स्रोत पते और RDP पोर्ट तक सीमित नियम से बदलें, फिर पुष्टि करें कि प्रोफ़ाइल अपनी इच्छित स्थिति में लौट आया है। यह तब करें जब सत्र अब भी आपके पास हो, क्योंकि अगली ग़लती दूर से उलटी न हो सके। बदलाव के दौरान Bastion या सीरियल कंसोल जैसा दूसरा प्रशासनिक रास्ता तैयार रखें।

अपने वर्कस्टेशन से पोर्ट परीक्षण से और गेस्ट के भीतर से नियम सूची से परिणाम की पुष्टि करें:

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

परीक्षण की अवधि के लिए फ़ायरवॉल लॉगिंग चालू करें। गिराए गए पैकेट की एक पंक्ति जो 3389 और सक्रिय प्रोफ़ाइल बताती है, दूसरे रीबूट से ज़्यादा तेज़ी से जवाब देती है।

अगले इंस्टॉलर को फिर से ऐसा करने से रोकें

अगर उस होस्ट के पास क्लाइंट चलाने की कोई वजह नहीं है, तो उसे अनइंस्टॉल करें। इंस्टॉल किया गया क्लाइंट अगले अपडेट के लिए प्रोफ़ाइल फिर से लिखने का स्थायी न्योता है, और अगला व्यक्ति पोर्टल से वही रुकावट डीबग करेगा।

किसी को नेटवर्क सेटिंग्स फिर से लिखने देने से पहले डिस्क का स्नैपशॉट लें, और ज़रूरत पड़ने से पहले दूसरा प्रशासनिक रास्ता तैयार रखें।

इंस्टॉलर ने क्या बदला, यह दर्ज करें: एडेप्टर, रूट, फ़ायरवॉल प्रोफ़ाइल, फ़िल्टर ड्राइवर और सेवाएँ। यह रिकॉर्ड अगली घटना को नई जाँच के बजाय जाना-पहचाना पैटर्न बना देता है। जब VM को ठीक एक सेवा तक सुरंग चाहिए, तो क्लाइंट अपने वर्कस्टेशन पर रखें या सर्वर पर लैपटॉप उत्पाद इंस्टॉल करने के बजाय साइट-टू-साइट लिंक बनाएँ। उपभोक्ता क्लाइंट लैपटॉप के लिए होते हैं, और दूर से आप जो सर्वर प्रशासित करते हैं वह ऐसा नहीं है।