सबै 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 नियम आवश्यक थियो, पर्याप्त थिएन।