RDP के लिए अनुमति नियम जोड़ने से आपकी VPN पहुँच संकुचित नहीं होती

योजना उचित लगती है: मौजूदा रिमोट डेस्कटॉप अनुमति को जैसा है वैसा रहने दें और उस एकमात्र VPN क्लाइंट के लिए छोटी अनुमति जोड़ें जिसे पहुँच मिलनी चाहिए। Windows Firewall ऐसे काम नहीं करता। नियम कोई क्रमबद्ध सूची नहीं हैं जिसमें सबसे विशिष्ट प्रविष्टि जीतती है, और चौड़ी अनुमति के बगल में संकीर्ण अनुमति कुछ नहीं बदलती, क्योंकि चौड़ी अनुमति अब भी उन सबको जाने देती है जिन्हें पहले से जाने देती थी। सेवा को संकुचित करने का अर्थ उसी अनुमति को संपादित करना है जो पहले से काम कर रही है।

आप जो नियम जोड़ते हैं वह महत्वपूर्ण नियम नहीं है

Windows Firewall मशीन पर लागू नीति भंडारों में सभी लागू इनबाउंड नियमों का मूल्यांकन करता है, फिर तय करता है कि कोई अनुमति मेल खाती है या नहीं और कोई ब्लॉक उसे ओवरराइड करता है या नहीं। नियम जोड़ने से अनुमति जुड़ती है; यह पहले से मौजूद अनुमतियों को हटाता या सीमित नहीं करता।

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

इसीलिए एक व्यवस्थापक सही दिखने वाला बदलाव कर सकता है, उसे गलत मशीन से परख सकता है और निष्कर्ष निकाल सकता है कि यह काम कर गया। बाहर किए गए स्रोत का कभी परीक्षण नहीं हुआ। जो परीक्षण केवल सफलता साबित करता है वह उस आधे से भी कम साबित करता है जिसके लिए बदलाव किया गया था।

पता लगाएँ कि सर्वर कौन-सा पता देखता है

कुछ भी सीमित करने से पहले Windows होस्ट पर एक अनुमत सत्र देखें और सर्वर जो स्रोत पता बताता है उसे दर्ज करें। यह हमेशा वह पता नहीं होता जो क्लाइंट मानता है कि उसके पास है।

यदि VPN गेटवे क्लाइंट पते सुरक्षित रखता है, तो सर्वर क्लाइंट का टनल पता देखता है, और पते से सीमित नियम अर्थपूर्ण है। यदि गेटवे अनुवाद करता है, तो हर क्लाइंट गेटवे के पते के रूप में आता है, और उस पते तक सीमित करना उसके पीछे के हर क्लाइंट को पहुँच देता है। तब नियम गलत चीज़ के बारे में सटीक है।

इन दो डिज़ाइनों को अलग उत्तर चाहिए। पहले को फ़ायरवॉल नियम में व्यक्त किया जा सकता है; दूसरे को वहाँ लागू करना होगा जहाँ पहचान अब भी मौजूद है, यानी VPN में ही या सेवा के सामने प्रमाणित गेटवे में।

नेटवर्क अनुवाद ने जो पहचान छोड़ दी, उसे फ़ायरवॉल फ़िल्टर वापस नहीं ला सकता, चाहे पता कितनी सावधानी से लिखा गया हो।

प्रभावी नियम का स्वामी बदलें

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

फिर मौजूदा नियमों को उसी भंडार से संपादित करें जो उनका स्वामी है। ऐसे नियम में स्थानीय संपादन जिसे डोमेन नीति भी परिभाषित करती है, विलय हो सकता है, अनदेखा हो सकता है या अधिलेखित हो सकता है, और उस पर निर्भर होने से पहले यह जानना उचित है कि इनमें से क्या होता है।

ये कमांड सक्रिय नियम खोजते हैं, उनमें से एक से जुड़ा पता फ़िल्टर दिखाते हैं और दायरे के बदलाव का पूर्वावलोकन करते हैं:

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 नामांकन और यह नेटवर्क अनुमति दोनों हटनी चाहिए, वरना आपने जिस पते की सीमा तय की वह कभी किसी और का हो जाएगा।