सारे ICMP को ब्लॉक करना काम कर रहे VPN पथ को क्यों तोड़ता है
आकार पर आधारित फ़ीडबैक संदेश ping के उत्तर नहीं हैं। जब वे कभी नहीं पहुँचते, छोटे पैकेट निकल जाते हैं, बड़े गायब हो जाते हैं, और टनल फड़फड़ाती दिखती है।
जो टनल प्रमाणीकरण पार करती है, ping ढोती है और फिर पहले बड़े स्थानांतरण पर अटक जाती है, वह टूटे VPN का नहीं बल्कि गुम ICMP संदेश का उत्कृष्ट संकेत है। प्रेषक को कभी पता नहीं चलता कि पैकेट बहुत बड़ा था, वही आकार दोहराता रहता है, और ऐप्लिकेशन प्रतीक्षा करता है। इसे ठीक करना फ़ायरवॉल नीति का निर्णय है, क्लाइंट को फिर से इंस्टॉल करना नहीं। क्रम मायने रखता है: नापें कि आकार की सीमा कहाँ है, फिर उस नियम को संकीर्ण करें जिसने रिपोर्ट निगल ली।
इस पथ पर ICMP वास्तव में क्या ढोता है
IPv4 पथ MTU खोज इस पर निर्भर करता है कि राउटर बताए कि don't-fragment बिट वाला पैकेट आगे नहीं भेजा जा सका। वह रिपोर्ट ICMP Fragmentation Needed संदेश है, और उसके बिना प्रेषक के पास अपने खंड का आकार घटाने का कोई कारण नहीं है। IPv6 अधिक सख़्त है: राउटर ट्रांज़िट में विखंडन नहीं करते, इसलिए ICMPv6 Packet Too Big संदेश ही एकमात्र संकेत है जो प्रेषक को सिकोड़ता है।
दोनों संदेश नियंत्रण-तल का फ़ीडबैक हैं, और कोई भी नैदानिक प्रतिध्वनि नहीं है। ping को ब्लॉक करने वाली नीति और सारे ICMP को ब्लॉक करने वाली नीति नियमों की सूची में समान दिखती हैं पर नेटवर्क पर बहुत अलग व्यवहार करती हैं। दूसरी सही आकार की टनल को श्रृंखला की सबसे छोटी कड़ी से बड़ी किसी भी चीज़ के लिए एकतरफ़ा पथ बना सकती है।
कुछ परिवहन अपनी खोज प्रोब पैकेट से लागू करते हैं, जैसा RFC 4821 वर्णित करता है, और वे इस फ़ीडबैक पर कम निर्भर हैं। यह जाँचने का तर्क है कि आप कौन-सा परिवहन चलाते हैं, यह मानने का नहीं कि हर टनल प्रतिरक्षित है।
| संदेश | पथ पर उद्देश्य | यदि ब्लॉक हो |
|---|---|---|
| ICMPv4 प्रकार 3 कोड 4 | पैकेट अगली कड़ी के लिए बहुत बड़ा था | प्रेषक दोहराता रहता है और अटक जाता है |
| ICMPv6 प्रकार 2 | Packet Too Big, IPv6 का समकक्ष | वही अटकाव, विखंडन के किसी विकल्प के बिना |
| ICMP प्रकार 11 | समय समाप्त, traceroute इसका उपयोग करता है | निदान हॉप खो देता है, ट्रैफ़िक फिर भी बहता रहता है |
| ICMP प्रतिध्वनि अनुरोध और उत्तर | पहुँच परीक्षण | ping विफल होता है, पथ ठीक हो सकता है |
विफलता आकार पर निर्भर है
पूछें कि क्या विफलता पैकेट के आकार से संबंधित है। लॉगिन पृष्ठ, DNS क्वेरी और छोटा API कॉल सफल होते हैं, जबकि फ़ाइल अपलोड, बड़ा उत्तर या छवि डाउनलोड अटक जाता है। यह पैटर्न दोनों सिरों के बीच कहीं आकार की सीमा की ओर इशारा करता है, प्रमाणीकरण या राउटिंग की ओर नहीं। सफल छोटा ping उस सीमा के स्थान के बारे में लगभग कुछ नहीं कहता।
टनल के भीतर दो परतें विचारणीय हैं: पेलोड पैकेट और बाहरी एनकैप्सुलेटेड पैकेट। भीतरी प्रेषक सही व्यवहार कर सकता है जबकि बाहरी पथ टनल की धारणा से छोटा हो, इसीलिए टनल की अपनी MTU सेटिंग और उसके नीचे की भौतिक कड़ी दोनों मायने रखती हैं।
नियम संपादित करने से पहले नापें
don't-fragment बिट और अपने चुने हुए पेलोड आकार से जाँचें, विफल क्लाइंट से संरक्षित पते की ओर:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.71472 बाइट का पेलोड और 28 बाइट हेडर मिलकर 1500 बाइट का पैकेट बनाते हैं। यदि बड़ा प्रोब विखंडन त्रुटि से विफल हो और छोटा निकल जाए, तो आपने सीमा पा ली; टनल के अतिरिक्त भार के लिए समायोजित करें और काम करने वाला आकार स्थिर होने तक दोहराएँ।
फिर पुष्टि करें कि अंतराल रिपोर्ट ही है। यदि प्रोब चुपचाप विफल हो, बिना त्रुटि और उत्तर के, तो संदेश संभवतः गिराया जा रहा है, पहुँचाया नहीं जा रहा, और संदिग्ध नियम है।
नियम संकीर्ण करें, फिर कार्य को दोबारा जाँचें
सुधार को विशिष्ट नियंत्रण संदेशों की अनुमति देनी चाहिए, पूरे प्रोटोकॉल की नहीं। iptables होस्ट पर रूप प्रकार-विशिष्ट स्वीकृति है; सिंटैक्स को उसके अनुसार ढालें जो आपके प्लेटफ़ॉर्म पर फ़ायरवॉल का प्रबंधन करता है:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTयदि वह स्थानीय नीति है तो प्रतिध्वनि उत्तरों को ब्लॉक रखें, क्योंकि पथ को उनकी आवश्यकता नहीं है। फिर मूल रूप से विफल हुए स्थानांतरण को नए कनेक्शन से दोबारा जाँचें, और पुष्टि करें कि नियम के काउंटर संदेश आते दिखा रहे हैं।
यदि संदेशों की अनुमति के बाद भी बड़ा स्थानांतरण अटकता है, तो शेष सीमा कहीं और है: बहुत ऊँची सेट की गई टनल MTU, पैकेट फिर से लिखने वाला प्रॉक्सी, या रिपोर्ट करने के बजाय गिराने वाला मध्य बॉक्स। ICMP नियम आवश्यक था, पर्याप्त नहीं।