पिंग फक्त एकाच दिशेने चालते: 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

अंमलात आलेला नियम छापणे हे तो तयार करणाऱ्या आदेशावर विश्वास ठेवण्यापेक्षा अधिक उपयुक्त आहे, कारण पूर्वावलोकन आणि लागू केलेला नियम वेगळ्या स्थिती आहेत. पत्ता गाळणी तुम्हाला अभिप्रेत स्रोत दाखवत असेल आणि वगळलेला स्रोत अजूनही कालबाह्य होत असेल, तर नियम त्याच्या व्याप्तीप्रमाणेच वागतो. क्लायंटकडून सुरू झालेला यशस्वी पिंग ते कधीच दाखवू शकला नसता, म्हणूनच प्रत्येक चाचणीची दिशा तिच्या निकालाशेजारी नोंदीत असते. तिकिटात दोन्ही दिशा ठेवा, नाहीतर पुढील वाचक अपयशी होऊच न शकणारी चाचणी पुन्हा करेल.