सर्व 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 नियम आवश्यक होता, पुरेसा नव्हता.