RDP साठी परवानगी नियम जोडल्याने तुमचा VPN प्रवेश अरुंद होत नाही

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

तुम्ही जोडता तो नियम महत्त्वाचा नियम नाही

Windows Firewall मशीनला लागू असलेल्या धोरण साठवणींमधील सर्व लागू इनबाउंड नियमांचे मूल्यांकन करतो, नंतर कोणतीही परवानगी जुळते का आणि कोणताही ब्लॉक तिला मागे टाकतो का हे ठरवतो। नियम जोडल्याने परवानगी जोडली जाते; तो आधीपासून असलेल्या परवानग्या काढत नाही किंवा मर्यादित करत नाही।

त्यामुळे प्रश्न कधीही तुम्ही काय जोडले हा नसतो। प्रश्न असा आहे की स्थानिक धोरण, डोमेन धोरण आणि प्रोफाइलची डीफॉल्ट मूल्ये एकत्र आल्यानंतर प्रभावी धोरणात काय आहे। एका स्थानिक नियमाच्या वर्कस्टेशनबद्दल विचार करणे सोपे आहे; डोमेनशी जोडलेल्या सर्व्हरबद्दल नाही।

म्हणूनच प्रशासक बरोबर दिसणारा बदल करू शकतो, तो चुकीच्या मशीनवरून तपासू शकतो आणि तो चालला असा निष्कर्ष काढू शकतो। वगळलेल्या स्रोताची कधीही चाचणी झाली नाही। केवळ यश सिद्ध करणारी चाचणी बदलाच्या उद्देशाच्या अर्ध्यापेक्षा कमी सिद्ध करते।

सर्व्हर कोणता पत्ता पाहतो ते शोधा

काहीही मर्यादित करण्यापूर्वी Windows होस्टवर एका परवानगी असलेल्या सत्राचे निरीक्षण करा आणि सर्व्हर जो स्रोत पत्ता सांगतो तो नोंदवा। तो नेहमी क्लायंटला वाटत असलेला पत्ता नसतो।

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

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

नेटवर्क भाषांतराने टाकून दिलेली ओळख फायरवॉल फिल्टर परत आणू शकत नाही, पत्ता कितीही काळजीपूर्वक टाइप केला तरी।

प्रभावी नियमाचा मालक बदला

प्रभावी इनबाउंड धोरण तपासा आणि सध्या RDP रहदारीला परवानगी देणारा प्रत्येक नियम शोधा, ज्यांच्या दर्शनी नावात कधीही पोर्ट 3389 चा उल्लेख नसलेल्या नियमांचाही समावेश आहे। सेवा-मर्यादित आणि अनुप्रयोग-मर्यादित नियमही मोजले जातात, आणि काही RDP उपयोजने सक्षम करतात ते UDP वाहतूकही।

नंतर विद्यमान नियम ज्या साठवणीकडे ते आहेत त्या मार्गाने संपादित करा। डोमेन धोरणही परिभाषित करणाऱ्या नियमातील स्थानिक संपादन विलीन होऊ शकते, दुर्लक्षित होऊ शकते किंवा अधिलिखित होऊ शकते, आणि त्यावर अवलंबून राहण्यापूर्वी त्यातले काय होते हे जाणून घेणे योग्य आहे।

या आदेश सक्रिय नियम शोधतात, त्यातील एकाला जोडलेला पत्ता फिल्टर दाखवतात आणि व्याप्तीतील बदलाचे पूर्वावलोकन करतात:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

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

आधी ब्लॉक नंतर परवानगी ही वेगळी प्रतिकृती आहे

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

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

दुसऱ्या स्रोताने ते सिद्ध करा

परवानगी असलेल्या क्लायंटवरून आणि आता अयशस्वी व्हायला पाहिजे अशा स्रोतावरून चाचणी करा। एकच यशस्वी कनेक्शन फक्त परवानगी असलेला मार्ग चालतो हे सिद्ध करते; तुम्ही नुकतेच केलेल्या वगळण्याबद्दल ते काहीही सांगत नाही।

सर्व्हरवर सक्षम असल्यास IPv6 वर चाचणी पुन्हा करा, कारण केवळ IPv4 चा हेतू कोणीही न पाहिलेल्या रुंद IPv6 परवानगीसोबत सहअस्तित्वात राहू शकतो।

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