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 दर्ता र यो नेटवर्क अनुमति दुवै हटाउनुपर्छ, नत्र तपाईंले सीमित गर्नुभएको ठेगाना कुनै दिन अरू कसैको हुनेछ।