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 इस नीति के बारे में कुछ साबित नहीं करता, और यही वह माप है जिसे अधिकांश परिनियोजन छोड़ देते हैं।