VPN क्लायंट इन्स्टॉल केल्यानंतर RDP थांबतो? फायरवॉल जबाबदार आहे
ग्राहक VPN इन्स्टॉलर Windows फायरवॉल प्रोफाइल बदलून RDP कापू शकतो। गेस्ट एजंटमार्फत परत या, नंतर नियम पोर्ट 3389 पर्यंत मर्यादित करा।
ग्राहक 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 ला नेमक्या एका सेवेपर्यंत बोगदा हवा असेल, तर क्लायंट तुमच्या वर्कस्टेशनवर ठेवा किंवा सर्व्हरवर लॅपटॉप उत्पादन इन्स्टॉल करण्याऐवजी साइट-टू-साइट लिंक तयार करा। ग्राहक क्लायंट लॅपटॉपसाठी आहेत, आणि दूरून तुम्ही व्यवस्थापित करता तो सर्व्हर तसा नाही।