पिङ एउटै दिशामा मात्र काम गर्छ: 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

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