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 या धोरणाबद्दल काहीही सिद्ध करत नाही, आणि तेच मोजमाप बहुतेक तैनाती वगळतात।