VPN अवस्थासँग बाँधिएको फायरवल गेट किन टनेलबाट मात्र ping को नियम होइन

नामित VPN प्रोफाइल जोडिएको हरेक पटक सर्भरको सार्वजनिक ठेगानाका लागि ICMP echo सक्रिय गर्ने फायरवल नियम कल्पना गर्नुहोस्। यसलाई «टनेलबाट मात्र ping» भनेर पढिन्छ, र त्यो पठन महत्त्वपूर्ण तरिकाले गलत छ। नियमले कसले होस्टसम्म पुग्न सक्छ भन्ने सीमित गर्दैन; अर्को जडान संयोगवश सक्रिय हुँदा सार्वजनिक इन्टरफेसले केको जवाफ दिन्छ भन्ने परिवर्तन गर्छ। यी दुई फरक नीति हुन्, र तीमध्ये एउटा चुपचाप जोखिम फैलाउँछ।

तपाईंले लेख्नुभयो भन्ने ठान्नुभएको नियम

अभिप्रेत आवश्यकता सामान्यतया साँघुरो हुन्छ: अनुगमन प्रणाली, वा VPN मा रहेको एक मात्र प्रशासकले सर्भर जीवित छ भनी पुष्टि गर्न सक्नुपर्छ। वाक्यका रूपमा लेख्दा यो टनेलमा पहुँच नियन्त्रणजस्तो सुनिन्छ। फायरवल वस्तुका रूपमा लेख्दा यो सार्वजनिक प्रोफाइलमा शर्त बन्छ, किनभने echo अनुरोध त्यहीँ आउँछ।

शर्त स्रोत ठेगानाको सट्टा जडानको अवस्था बनेपछि, अनुमति प्राप्त पठाउनेहरूको समूह अब VPN साथीहरूको समूह होइन। सार्वजनिक ठेगानामा पुग्न सक्ने जो कोहीले गेट खुला रहेसम्म echo अनुरोध पठाउन सक्छ। टनेल बाटो बनेन; टनेल स्विच बन्यो।

यो विचार प्रचार गर्नेहरूले सामान्यतया चाहेको प्रभावबारे झुटो बोल्दैनन्। उनीहरूलाई लिङ्क स्वस्थ हुँदा मात्र जवाफ दिने जाँच चाहिएको थियो, र लिङ्कको स्वास्थ्य VPN मार्फत हेर्न सबैभन्दा सजिलो थियो। गल्ती भनेको उपलब्धताको सङ्केतलाई पहुँचको निर्णय मान्नु र त्यसपछि स्वचालित बनाउनु हो।

गेटले वास्तवमा के नियन्त्रण गर्छ

यो डिजाइनले दुई स्वतन्त्र कुरा मिसाउँछ, र तिनलाई छुट्याउनु नै सुधारको ठूलो भाग हो। पहिलो हो दायरा: कुन स्थानीय ठेगाना, कुन टाढाका ठेगानाहरू, कुन प्रोटोकल र कुन ICMP प्रकार। दोस्रो हो शर्त: नियमको वस्तु यो क्षण सक्रिय छ कि छैन। दायरा फायरवलले प्रत्येक प्याकेटमा मूल्याङ्कन गर्ने कुरा हो; शर्त स्क्रिप्टले नीति भण्डारमा लेख्ने कुरा हो, र दुवै पूर्ण रूपमा फरक घडीमा मिलाइन्छ।

आवश्यकता साँच्चै VPN साथीहरू मात्र भए, दायराले कुनै पनि जडान-अवस्था तर्कबिना त्यसको जवाफ दिन्छ: नियमलाई टनेल इन्टरफेस वा टनेल ठेगाना दायरासँग बाँध्नुहोस्, टाढाका ठेगानाहरूलाई ग्राहक पूलमा सीमित गर्नुहोस्, र «ICMP» को सट्टा echo प्रकार तोक्नुहोस्। कुनै VPN सक्रिय नहुँदा पनि त्यो नियम सही रहन्छ र असम्बन्धित प्रोफाइलले खोल्न सक्दैन।

आवश्यकता साँच्चै सार्वजनिक गेट भए, नीतिको पाठमा त्यो भन्नुहोस्, किनभने स्वीकृतिका मापदण्ड बदलिन्छन्। सार्वजनिक गेटले ठ्याक्कै प्रोफाइलको नाम लिनुपर्छ, «जोडिएको» को अर्थ परिभाषित गर्नुपर्छ, र सार्वजनिक पठाउनेहरू डिजाइनअनुसार दायरामा छन् भनी घोषणा गर्नुपर्छ। कसैलाई त्यो वाक्य लेख्न बाध्य पारिएको क्षणमा धेरैजसो अन्योल हराउँछ।

वस्तु एक पटक बनाउनुहोस्, त्यसपछि टगल गर्नुहोस्

स्थिर पहिचान भएको एउटै नियम पहिल्यै, निष्क्रिय अवस्थामा तयार गर्नुहोस्, र नियन्त्रकले त्यसको सक्रिय अवस्था मात्र बदलोस्। हरेक पटक प्रदर्शन नामबाट नियम बनाउनु नै नीति भण्डार पाँच लगभग समान वस्तु र तिनलाई हटाउने भरपर्दो उपाय नभई बस्ने बाटो हो।

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

नाम दिगो पहिचानकर्ता हो; प्रदर्शन नाम मानिसले सम्पादन गर्न सक्ने कागजात हो। -Name मा मिलाउनुहोस् र स्क्रिप्टले प्रतिलिपि बनाउन छोड्छ। त्यही आदेश-आकारले IPv6 अवस्थालाई -Protocol ICMPv6 -IcmpType 128 सहित समेट्छ, तर त्यो छुट्टै नियम हो किनभने echo प्रकारका सङ्ख्या दुई परिवारबीच फरक छन्।

ठेगाना परिवार र ICMP प्रकार स्पष्ट राख्नुहोस्, दोस्रो कारण पनि छ: -Protocol ICMPv4 प्रकारबिना प्रोफाइलले अनुमति दिने हरेक ICMPv4 सन्देशलाई अनुमति दिन्छ, तपाईंले कहिल्यै स्वीकार्न नसोचेकाहरू पनि। प्रकार 8 को नाम लिनुले नियमलाई echo अनुरोधमा साँघुरो बनाउँछ, र पहुँच-जाँचले त्यही मात्र पठाउँछ।

स्वचालनले मनसायको विरोध गर्ने ठाउँ

हरेक केही मिनेटमा ग्राहक प्रोफाइल सोध्ने कामले तत्काल सीमा बनाउन सक्दैन। जडान झर्ने र अर्को सोधाइबीच नियम सार्वजनिक ठेगानामा जवाफ दिइरहन्छ; जडान उठ्ने र अर्को सोधाइबीच जवाफ दिँदैन। त्यो ढिलाइ स्वीकार्नु इमानदार हो, र डिजाइनले कडा अपरिवर्तनीय लाद्छ भन्नु इमानदार होइन।

अवस्था-जाँचमै दायराको जाल छ। Get-VpnConnection ले मेसिनमा कन्फिगर गरिएका ग्राहक प्रोफाइलहरू रिपोर्ट गर्छ, पूर्वनिर्धारित रूपमा वर्तमान प्रयोगकर्ताका लागि र -AllUserConnection सहित सबै प्रयोगकर्ताका लागि। यसले अहिले RRAS सर्भरमा डायल-इन भएका टाढाका प्रयोगकर्ताहरू रिपोर्ट गर्दैन; त्यो अर्को कमाण्डको अर्को अवलोकन हो। गलतमाथि बनाइएको गेट कुनै पनि कुरासँग जोडिएको हुँदैन।

त्यसपछि कसैले स्क्रिप्ट नगर्ने अवस्थाहरू समेट्नुहोस्: अघिल्लो पटकबाट नियम पहिल्यै सक्रिय भएको अवस्थामा सुरु, गेट खुला हुँदा नियन्त्रकको क्र्यास, र नियम जीवित रहँदा प्रोफाइल मेटिनु। प्रत्येकलाई परिभाषित पूर्वनिर्धारित चाहिन्छ, र सार्वजनिक अनुमतिका लागि सुरक्षित पूर्वनिर्धारित निष्क्रिय हो। आवश्यकताले सोधाइको झ्याल साँच्चै सहन नसक्ने भए, अवस्था-बद्ध नियम गलत उपकरण हो र प्रवर्तन टनेलमा हुनुपर्छ, सार्वजनिक इन्टरफेसमा होइन।

अन्तमा, सार्वजनिक अनुरोध दुई पटक जाँच्नुहोस्, एक पटक छानिएको जडान सक्रिय हुँदा र एक पटक बन्द हुँदा, VPN मा नभएको होस्टबाट। टनेलभित्रबाट सफल ping ले यो नीतिबारे केही प्रमाणित गर्दैन, र त्यही मापन धेरैजसो तैनाथीले छोड्छन्।