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 या कोई अन्य प्रवाह अनुमत है।