VPN मार्फत ping: प्रतिध्वनि उत्तरका नियमहरू फर्किने बाटो किन चुक्छन्

VPN मार्फत होस्टमा ping गर्नुहोस्, अनुरोध एउटा ICMP प्रकारमा जान्छ र अर्को प्रकारमा फर्कन्छ, जुन पोर्टका आधारमा लेखिएको कुनै पनि नियम भ्रमित गर्न पर्याप्त छ। प्रतिध्वनि आदानप्रदानमा फर्किने नियममा प्रतिलिपि गर्न मिल्ने कुनै गन्तव्य सेवा पोर्ट हुँदैन, र सममिति अपेक्षा गर्ने फिल्टरले अनुरोध निर्बाध पार हुँदै गर्दा उत्तर फ्याँकिदिन्छ। सुधार प्याकेटलाई जस्तो छ त्यस्तै पढेर, त्यसपछि बाटोमा कुन सीमाले निर्णय गरिरहेको छ भनेर निर्धारण गर्नबाट सुरु हुन्छ। सामान्यतया दुई तह काम गरिरहेका हुन्छन् र तेस्रोले चुपचाप उत्तर फ्याँकिदिन्छ। तलका खण्डहरूले प्याकेटले भेट्ने क्रममै तिनलाई अलग गर्छन्।

प्याकेटले पोर्ट होइन, प्रकार बदल्छ

प्रतिध्वनि अनुरोध ICMP प्रकार 8, कोड 0 हो, र यसले पहिचानकर्ता र क्रम नम्बर बोक्छ। उत्तर प्रकार 0, कोड 0 हो, त्यही पहिचानकर्ता र क्रमसहित, र IP छेउहरू फेरिएका छन्। यी फिल्डहरू RFC 792 ले परिभाषित गर्छ, र पहिचानकर्ताले नै प्रेषकलाई उत्तरहरू आफ्नै अनुरोधसँग मिलाउन दिन्छ।

जो छैन त्यो पनि उत्तिकै महत्त्वपूर्ण छ: TCP वा UDP हेडर छैन, त्यसैले अनुमति दिने पोर्ट छैन। प्रतिध्वनि उत्तरका लागि पोर्ट नाम दिने नियमले कहिल्यै नहुने प्याकेट वर्णन गर्छ। VPN ping टिकटहरूमा यो सबैभन्दा सामान्य गल्ती हो। नियम विशिष्ट देखिन्छ, कुनै कुरामा लागू हुँदैन, र विफलतालाई जहाँ थियो त्यहीँ छोड्छ।

तीन सन्दर्भले प्याकेट निर्धारण गर्छन्

यदि ping टाढाको LAN को होस्टलाई लक्ष्य गर्छ भने, अनुरोध गेटवेले फर्वार्ड गर्नुपर्छ। यदि यो गेटवेकै ठेगानालाई लक्ष्य गर्छ भने, यो स्थानीय इनपुट मार्गमा टुंगिन्छ। यदि गेटवे आफैंले ping सुरु गर्छ भने, प्याकेट आफ्नै आउटपुट मार्गमा सुरु हुन्छ र फर्वार्डिङ निर्णय पटक्कै पार गर्दैन।

यी तीन सन्दर्भका नियम-शृंखला र काउन्टर फरक छन्, र तिनलाई एउटै मान्नु नै «फायरवालले ICMP अनुमति दिन्छ» भन्दा पनि ping असफल हुनुको कारण हो। बाह्य सुरुङ चौथो सन्दर्भ हो: VPN श्रोतालाई अनुमति दिनुले डिक्याप्सुलेट भएको भित्री अनुरोधलाई स्वतः अनुमति दिँदैन, र भित्री अनुमतिले बाह्य सुरुङ चालु छ कि छैन भन्नेबारे केही भन्दैन।

स्टेटफुल र स्टेटलेस फिल्टरले उत्तर फरक ढंगले सम्हाल्छन्

अनुरोध बाहिर जाँदै गरेको देखेको स्टेटफुल फायरवालले उत्तरलाई त्यही प्रवाहसँग जोडेर दोस्रो नियमबिना प्रवेश दिन सक्छ। स्टेटलेस फिल्टरसँग त्यस्तो स्मृति हुँदैन, त्यसैले फर्किने दिशालाई आफ्नै स्पष्ट अनुमति चाहिन्छ, स्रोत र गन्तव्य उल्टाएर।

केही लेख्नु अघि उत्पादनले वास्तवमा कुन मोडेल लागू गर्छ जाँच्नुहोस्। प्रतिध्वनि अनुरोधको नियमले अनिवार्य रूपमा प्रतिध्वनि उत्तर समेट्दैन, र ICMP प्रश्नहरू ट्र्याक गर्ने उत्पादनले अर्को इन्टरफेसमा आउने उत्तरहरूमा फरक नीति लागू गर्न सक्छ।

तपाईंले अनुमति दिने कुराको दायरा तोक्नुहोस्। जहाँबाट पनि हरेक प्रतिध्वनि उत्तरलाई अनुमति दिनु स्टेटफुल सम्बन्ध पूरा गर्नुसरह होइन, र प्रकार नम्बरले प्रेषकको प्रमाणित गर्दैन।

अनुवादले पहिचानकर्ता पनि बदल्छ

यदि स्रोत अनुवाद जानाजान गरिएको हो भने, टाढाको छेउको टपल ग्राहकले पठाएकोसँग मिल्दैन। NAT ले ICMP प्रश्नको पहिचानकर्ता ठेगानासँगै अनुवाद गर्न सक्छ, त्यसैले दुवैतिर एउटै नम्बर देखिनुपर्छ भन्ने आग्रहले झुटो अमिलता सिर्जना गर्छ।

यसको सट्टा अनुवादकले रिपोर्ट गर्ने म्यापिङसँग सहसम्बन्ध राख्नुहोस्। पहिचानकर्ता पुनःलेख्ने अनुवादकले तपाईंको ग्राहकले रेकर्ड गरेको नम्बर जोगाउँदैन, त्यसैले नम्बरलाई होइन, म्यापिङलाई पहिचान मान्नुहोस्। त्यसपछि पहिचान गर्न सकिने एउटा अनुरोधलाई बाटोभरि पछ्याउनुहोस्: यो अपेक्षित स्रोतसहित गन्तव्यमा पुग्छ भनी पुष्टि गर्नुहोस्, गन्तव्यले उत्तर पठायो भनी पुष्टि गर्नुहोस्, त्यो उत्तरको फर्किने मार्ग पछ्याउनुहोस्, र ग्राहकले त्यो प्राप्त गर्‍यो भनी पुष्टि गर्नुहोस्, केवल गेटवे काउन्टर बढेको हेर्नुको सट्टा।

ICMP त्रुटिहरूलाई प्रतिध्वनि नीतिमा नमिसाउनुहोस्

बाटोको MTU पत्ता लगाउन प्रयोग हुने «खण्डीकरण आवश्यक» सन्देश प्रतिध्वनि उत्तर होइन, र यसको पेलोडले यसलाई उत्प्रेरित गर्ने प्याकेट उद्धृत गर्छ। प्रतिध्वनिमा मात्र अनुमति दिने नियमले ती त्रुटिहरू चुपचाप फ्याँक्दा आकारको समस्या झुन्डिएको जडानमा बदलिन्छ, जुन सहयोगी हुनुको विपरीत हो।

त्यही सावधानी ठेगाना परिवारहरूमा पनि लागू हुन्छ। ICMPv6 ले फरक सन्देश प्रकार प्रयोग गर्छ र IPv4 मा नभएका आवश्यक कार्य बोक्छ, त्यसैले यी नम्बरहरू IPv6 नियममा प्रतिलिपि गर्नु सीधै गलत हो।

प्रतिध्वनि आदानप्रदान चलेपछि वास्तविक एप्लिकेसन छुट्टै परीक्षण गर्नुहोस्। सफल ping ले एउटा प्रोटोकलको एउटै आकारमा एउटै गन्तव्यसम्मको आवतजावत प्रमाणित गर्छ, र HTTPS, SMB वा अन्य कुनै प्रवाह अनुमत छ भनी मान्ने इजाजतपत्र होइन।