पिंग केवल एक दिशा में काम करता है: Windows सर्वर की गूँज क्यों गिरा देता है

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

दो दिशाएँ, दो अलग निर्णय

जब क्लाइंट गूँज अनुरोध भेजता है, तब Windows फ़ायरवॉल एक बहिर्गामी कनेक्शन देखता है जिसे उसने अनुमति देने का निर्णय लिया है। उत्तर उसी स्थापित प्रवाह के भीतर लौटता है, इसलिए स्थिति-सचेत इंजन ICMP के लिए किसी भी आने वाले नियम से पूछे बिना उसे स्वीकार कर लेता है। व्यवहार में स्थिति-आधारित फ़िल्टरिंग का यही अर्थ है, और जो नियम किसी ने नहीं लिखा वह इसमें शामिल नहीं है। इसलिए क्लाइंट की सफलता आने वाली नीति के बारे में कुछ नहीं कहती।

जब सर्वर पहले अनुरोध भेजता है, तो कोई स्थिति उससे मेल नहीं खाती। Windows पैकेट को नया आने वाला कनेक्शन मानता है और आने वाली नीति से पूछता है, जो डिफ़ॉल्ट रूप से मनमाने स्रोतों से आने वाले गूँज अनुरोधों के लिए कोई प्रावधान नहीं रखती।

अतः क्लाइंट की सफलता ने सिद्ध किया कि बहिर्गामी ICMP और लौटने का मार्ग काम करते हैं। इसने आने वाले निर्णय को कभी परखा ही नहीं, और स्वाभाविक निष्कर्ष, कि फ़ायरवॉल ठीक है, उचित और गलत है। इसीलिए यह भूल उन टिकटों में दोहराई जाती है जिनमें प्रमाण पहले से मौजूद है।

पैकेट के गायब होने तक उसका पीछा करें

कुछ भी बदलने से पहले पते की पुष्टि करें: वही टनल पता इस्तेमाल करें जो क्लाइंट के पास वास्तव में है, और जाँचें कि सर्वर उसी की ओर मार्ग देता है, क्लाइंट के पीछे के LAN पते की ओर नहीं। सर्वर के प्रॉम्प्ट से दोनों विफलताएँ एक जैसी दिखती हैं, क्योंकि दोनों समय-समाप्ति पर समाप्त होती हैं। पैकेट कहाँ मरता है, यही एकमात्र तथ्य है जो तय करता है कि क्या बदलना है।

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

जब सर्वर पिंग कर रहा हो तब क्लाइंट के टनल इंटरफ़ेस पर कैप्चर करें। अनुरोध को बगल में उत्तर के बिना आते देखना वह प्रमाण है जो Windows नियम लिखने को उचित ठहराता है। कुछ भी न दिखना आपको ऊपर की ओर भेजता है, और उस स्थिति में जोड़ा गया नियम ऐसे पैकेट के लिए मशीन को केवल अधिक अनुमतिशील बनाता है जो कभी आया ही नहीं। दोनों ही स्थितियों में कैप्चर उस अनुमान से कम खर्चीला है जिसका वह स्थान लेता है।

ICMP खोलने के बजाय एक नियम सीमित करें

कुछ भी लिखने से पहले एडाप्टर और उसकी वर्तमान श्रेणी पहचानें, क्योंकि दोनों उस दायरे में आते हैं जिसे आप सेट करने वाले हैं। वह उपनाम Windows इंटरफ़ेस का नाम है, जो ज़रूरी नहीं कि आपके आयातित VPN प्रोफ़ाइल का नाम हो। नीचे दिए गए कमांड बताते हैं कि क्या मौजूद है, फिर लागू किए बिना सीमित नियम का पूर्वावलोकन दिखाते हैं।

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 प्रकार 8 गूँज अनुरोध है, वह अकेला संदेश जिसका उत्तर सर्वर को चाहिए। इसे सर्वर के टनल पते और टनल इंटरफ़ेस तक सीमित करें, और प्रोफ़ाइल को वैसा ही रहने दें जैसा एडाप्टर वास्तव में है। किसी उदाहरण में फ़िट कराने के लिए नेटवर्क का नाम बदलना अपने ही परिणामों वाला अलग परिवर्तन है।

नियम क्या नहीं ढकता

IPv6 की गूँज अलग संदेश प्रकार वाला अलग प्रोटोकॉल है, इसलिए ICMPv4 नियम उसके बारे में कुछ नहीं कहता, और दोनों परिवारों को ढोने वाली टनल को दूसरे के लिए अपना नियम चाहिए। यह नियम और कुछ भी नहीं खोलता: RDP, फ़ाइल साझा करना और हर अन्य सेवा अब भी अपनी नीति पर निर्भर है। व्यापक ICMP अनुमति चालू करने के बजाय एक संकीर्ण नियम सीमित करने का पूरा उद्देश्य यही है। व्यापक अनुमति आसान उपाय है और सबसे लंबे समय तक टिकती है, क्योंकि बाद में कोई उस पर ध्यान नहीं देता।

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

परिणाम सही दिशा में पढ़ें

नियम लागू होने के बाद सर्वर से पिंग करें और पुष्टि करें कि उत्तर क्लाइंट तक पहुँचता है, फिर ऐसे स्रोत से पिंग करें जो अब भी बाहर रहना चाहिए और पुष्टि करें कि वह नहीं पहुँचता। यदि टनल दूसरा पता परिवार ढोती है तो उस पर पहुँच-परीक्षण दोहराएँ।

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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