🎣 👛 📻 पथ MTU डिस्कवरी ब्लैक होल के बारे में कुछ शब्द 🌌 🐻 📆

पथ MTU डिस्कवरी ब्लैक होल के बारे में कुछ शब्द

ज्वाइन करने के बजाय

एक बार हर सच्चे सिस्टम एडमिनिस्ट्रेटर (या इस तरह का एक अभिनय) के लिए, सच्चाई का एक क्षण आता है। उसके पास स्थापित GNU / Linux वाले कंप्यूटर पर राउटर को कॉन्फ़िगर करने का भाग्य है। जो लोग पहले से ही यह जानते हैं, वे जानते हैं कि इसमें कुछ भी जटिल नहीं है और यह संभव है कि एक-दो टीमों से मिलना संभव हो। और अब हमारा व्यवस्थापक इन कमांडों को ढूंढता है, उन्हें कंसोल में चलाता है और गर्व से उपयोगकर्ताओं को यह कहने के लिए जाता है कि सब कुछ पहले से ही काम कर रहा है। लेकिन वहाँ यह था - उपयोगकर्ताओं का कहना है कि उनकी पसंदीदा साइटें नहीं खुलती हैं। मेरे जीवन के कुछ विवरणों को जानने के बाद, यह पता चलता है कि अधिकांश साइटें इस प्रकार व्यवहार करती हैं:
1. जब आप पृष्ठ खोलते हैं, तो शीर्षक लोड होता है और इससे अधिक कुछ नहीं;
2. इस अवस्था में, पृष्ठ अनिश्चित काल तक लटका रहता है;
3. ब्राउज़र स्थिति बार यह सब इंगित करता है कि पृष्ठ लोड हो रहा है;
4. इस साइट पर पिंग और ट्रेसिंग ठीक हैं;
5. पोर्ट 80 का टेलनेट कनेक्शन भी ठीक काम करता है।
हतोत्साहित व्यवस्थापक प्रदाता के तकनीकी समर्थन को कॉल करता है, लेकिन वे जल्दी से इससे छुटकारा पा लेते हैं, जिससे उन्हें सलाह दी जाती है कि वे विंडोज ओएस पर राउटर को कॉन्फ़िगर करने का प्रयास करें, और यदि यह वहां काम नहीं करता है ... तो एक हार्डवेयर राउटर खरीदें।
मुझे लगता है कि यह स्थिति बहुतों से परिचित है। कुछ खुद में गिर गए, कुछ उसके साथ दोस्त थे, और कुछ मंचों और अन्य सम्मेलनों में इस तरह के प्रवेशकों से मिले थे। तो: यदि आपके पास ऐसी स्थिति है, तो - बधाई! आपका सामना पथ एमटीयू डिस्कवरिंग ब्लैक होल से है । यह आलेख ऐसा क्यों होता है और इस समस्या को हल करने के लिए समर्पित है।

लेख को समझने के लिए आवश्यक शर्तें।

MTU (अधिकतम संचरण इकाई) - इस शब्द का उपयोग अधिकतम पैकेट आकार (बाइट्स में) निर्धारित करने के लिए किया जाता है जिसे OSI नेटवर्क मॉडल की डेटा लिंक परत पर प्रेषित किया जा सकता है। ईथरनेट के लिए, यह 1500 बाइट्स है। यदि एक बड़ा पैकेट आता है (उदाहरण के लिए, टोकन रिंग के माध्यम से), तो डेटा को एमटीयू (यानी 1,500 बाइट्स से अधिक नहीं) के पैकेटों में फिर से जोड़ा जाता है। एक और एमटीयू के तहत पैकेट रिअर्सफॉर्म के संचालन को विखंडन कहा जाता है और यह राउटर के लिए महंगा है।
PMTU (पथ MTU) - यह पैरामीटर स्रोत और रिसीवर के बीच MTU डेटा चैनलों में सबसे छोटे MTU को इंगित करता है।
PMTU डिस्कवरी एक PMTU डिस्कवरी तकनीक है जिसे राउटर पर लोड को कम करने के लिए डिज़ाइन किया गया है। 1988 में RFC 1191 में वर्णित। प्रौद्योगिकी का सार यह है कि जब दो होस्ट जुड़े होते हैं, तो DF (टुकड़ा नहीं) पैरामीटर सेट होता है, जो पैकेट विखंडन को रोकता है। यह नोड का कारण बनता है, जिसका एमटीयू पैकेट के आकार से कम है, पैकेट के प्रसारण को अस्वीकार करने और टाइप गंतव्य का एक ICMP संदेश भेजने के लिए पहुंच से बाहर है। त्रुटि संदेश नोड के MTU मान के साथ है। भेजने वाला होस्ट पैकेट के आकार को कम करता है और इसे फिर से भेजता है। इस तरह का एक ऑपरेशन तब तक होता है जब तक कि विखंडन के बिना गंतव्य मेजबान तक पहुंचने के लिए पैकेट काफी छोटा हो।
एमएसएस (अधिकतम खंड आकार) - अधिकतम खंड आकार, अर्थात्। डेटा का सबसे बड़ा हिस्सा जो टीसीपी कनेक्शन के दूरस्थ दूसरे छोर पर भेजेगा। इसकी गणना निम्न सूत्र द्वारा की जाती है:
इंटरफ़ेस MTU - Header_IP_Size (20 बाइट्स) - Header_TCP_Size (20 बाइट्स)। कुल आम तौर पर 1460 बाइट्स। जब एक कनेक्शन स्थापित होता है, तो प्रत्येक पक्ष अपने स्वयं के एमएसएस की घोषणा कर सकता है। सबसे छोटा मान चुना गया है। अधिक विवरण यहां पाया जा सकता है ।
ध्वज DF (टुकड़ा न करें) - आईपी पैकेट हेडर के झंडे क्षेत्र में एक बिट, जो जब एक पर सेट होता है, तो यह इंगित करता है कि यह पैकेट टुकड़ा करने के लिए मना किया गया है। यदि इस तरह के झंडे वाला एक पैकेट अगले अग्रेषण के एमटीयू से बड़ा है, तो इस पैकेट को छोड़ दिया जाएगा, और प्रेषक को एक आईसीएमपी त्रुटि भेजी जाएगी: "विखंडन की आवश्यकता है, लेकिन बिट टुकड़ा सेट नहीं किया गया है" (विखंडन की जरूरत है लेकिन विखंडन बिट सेट नहीं है)।

परीक्षण स्थल

यह समस्या अभ्यास में सबसे अच्छी तरह से परिचित है (लेकिन समय की परेशानी में नहीं, जब बॉस कान पर चिल्लाता है)। ऐसा करने के लिए, मैंने एक परीक्षण नेटवर्क बनाया, जो चित्र 1 में दिखाया गया है

अंजीर। 1. परीक्षण नेटवर्क।

यह वैश्विक नेटवर्क का एक सरलीकृत संस्करण है। भूमिकाओं:
1. डिबट-सर्व -03 नाम का एक कंप्यूटर हमारा लिनक्स राउटर है। ध्यान - इसके एथ 2 इंटरफेस पर, एमटीयू का आकार 1400 बाइट्स तक कम हो गया है;
2. डिब-सर्व -05 - स्थानीय नेटवर्क पर एक ग्राहक;
3. डिब-होम - प्रदाता पर स्थित एक राउटर;
4. डिब-सर्व - इंटरनेट पर एक वेब सर्वर जिसके साथ हम डेटा का आदान-प्रदान करना चाहते हैं। हम www.site.local से प्राप्त करते हैं , यह आकार में 5.9Kb का पृष्ठ है।
बेशक, वास्तव में श्रृंखला बहुत बड़ी है, लेकिन एक उदाहरण के लिए यह पर्याप्त है। इस नेटवर्क के सभी कंप्यूटर डेबियन GNU / Linux 5.0 Lenny चला रहे हैं। नेटवर्क में विभिन्न बिंदुओं पर, मैं tcpdump प्रोग्राम का उपयोग करके स्थिति को नियंत्रित करता हूं।

पीएमटीयू का सामान्य पता लगाना

पहले, आइए देखें कि जब आप एक पेज खोलते हैं तो नेटवर्क पर क्या होता है। जानें कि वेब सर्वर से पैकेज कैसे चलते हैं। हम TCPDUMP # 1 के आउटपुट को देखते हैं (eth0 डिबेट-सर्व पर):

1 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [S], seq 2947128725, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [S.], seq 757312786, ack 2947128726, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.48547 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:2897, ack 118, win 181, options [...], length 2896
7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
8 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:1349, ack 118, win 181, options [...], length 1348
9 IP 192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1349:2697, ack 118, win 181, options [...], length 1348
10 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556

मैं केवल पहले 10 पैकेज देता हूं और मानक tcpdump आउटपुट में सभी अतिरिक्त कटौती करता हूं। पार्स:
1. लाइनों 1 में 3 के माध्यम से हम टीसीपी कनेक्शन सेटअप देखते हैं। पार्टियां SYN, SYN-ACK, ACK पैकेट का आदान-प्रदान करती हैं। यहां यह विकल्प क्षेत्र पर ध्यान देने योग्य है, अर्थात् पार्टियों के बीच एमएसएस पैरामीटर का आदान-प्रदान किया जाता है। दोनों तरफ यह 1460 बाइट्स है। इसका मतलब यह है कि पार्टियों द्वारा एक दूसरे को भेजे जाने वाले पैकेट का अधिकतम आकार 1460 (MSS) +20 (टीसीपी हैडर) +20 (आईपी हैडर) = 1500 बाइट्स है।
2. लाइन 4 पर, डिब-सर्व -05 से एक वेब पेज के लिए एक अनुरोध भेजें। पंक्ति 5 इस पैकेज की प्राप्ति की पुष्टि करती है।
3. पंक्ति 6 में, हम अनुरोध की प्रतिक्रिया देखते हैं (जो वेब पेज का एक टुकड़ा भेज रहे हैं)। संभवतः इस इंटरफेस पर peculiarities के कारण, tcpdump आकार में 2948 बाइट्स के एक पैकेट को देखता है, जबकि 1500 और 1452 बाइट्स के 2 पैकेट क्रमशः नेटवर्क पर जाएंगे। यदि हम tcpdump के अधिक विस्तृत आउटपुट को देखते हैं, तो हम देखेंगे कि DF पैकेज इस पैकेज पर है (या पैकेज नहीं):

IP (tos 0x0, ttl 64, id 5177, offset 0, flags [DF], proto TCP (6), length 2948)
192.168.0.1.80 > 172.16.5.3.48547: Flags [.], seq 1:2897, ack 118, win 181, options [nop,nop,TS val 86620459 ecr 4922429], length 2896

4. जब ये डेटा पैकेट डीब-सर्व -03 तक पहुंच जाते हैं, तो उन्हें छोड़ दिया जाता है, क्योंकि वे MTU 1400 के साथ कनेक्शन के माध्यम से नहीं जा सकते हैं और खंडित नहीं हो सकते हैं (DF ध्वज), और जवाब में एक ICMP संदेश टाइप 3 कोड 4 उत्पन्न होता है: ICMP 17.1.16 .5.3 अगम्य - (1400 mtu) को सुगंधित करने की आवश्यकता है , जिसे हम लाइन 7 (लाइन 10 पर, 2 वें पैकेज के लिए एक संदेश आता है) पर देखते हैं। यह संदेश वांछित MTU प्रसारित करता है।
5. लाइनों 8 और 9 में, हम यह देखते हैं कि एमटीयू = 1400 प्राप्त करने वाले डिबेट-सर्व, 1400 बाइट्स के पैकेट में वेब पेज का एक ही टुकड़ा भेजता है। ये पैकेट डीब-सर्व -05 तक पहुँचते हैं, जहाँ पुष्टि की जाती है, और इसी तरह जब तक कि पूरा पृष्ठ स्थानांतरित न हो जाए। बाद के सभी पैकेटों का आकार 1400 बाइट्स से अधिक नहीं होगा।
यह उदाहरण RCF1911 में वर्णित परिवहन MTU निर्धारण प्रक्रिया (PMTU) को प्रदर्शित करता है। मैंने इसे चित्र 2 में सरलीकृत रूप में प्रस्तुत किया।

चित्रा 2. पीएमटीयू का निर्धारण करने की प्रक्रिया।

पथ MTU डिस्कवरी ब्लैक होल के साथ बैठक

अब कल्पना कीजिए कि प्रदाता के लिए एक नया विशेषज्ञ आया और (उदाहरण के लिए, आईसीएमपी बाढ़ से बचाने के लिए) डिब-होम के माध्यम से आईसीएमपी पैकेट भेजने पर रोक लगाने का फैसला किया, जो अब उसके प्रभार में है। हम देखते हैं कि क्या होता है:
TCPDUMP # 1 आउटपुट (एथ0 डिब-सर्व पर):

1 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [S], seq 1723325723, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [S.], seq 2482933888, ack 1723325724, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:2897, ack 118, win 181, options [...], length 2896
7 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
8 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
9 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
10 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

TCPDUMP # 2 आउटपुट (एथ0 डिब-सर्व -03 पर):

1 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [S], seq 1723325723, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [S.], seq 2482933888, ack 1723325724, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.57925 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
7 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
8 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1449:2897, ack 118, win 181, options [...], length 1448
9 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
10 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
11 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
12 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
13 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
14 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
15 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
16 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
17 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
18 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448
19 IP 172.16.250.2 > 192.168.0.1: ICMP 172.16.5.3 unreachable - need to frag (mtu 1400), length 556
20 IP 192.168.0.1.80 > 172.16.5.3.57925: Flags [.], seq 1:1449, ack 118, win 181, options [...], length 1448

जैसा कि आप देख सकते हैं, स्थिति काफी अपेक्षित है। प्रत्येक आउटपुट में पहली 6 लाइनें बिल्कुल सामान्य ट्रांसफर की तरह ही होती हैं (पिछले उदाहरण में विवरण देखें)। लेकिन फिर विसंगतियां शुरू हो जाती हैं। ICMP 3: 4 को समान रूप से deb-serv-03 (लाइन 7, 9 11.13, 15, 17, 19 पर TCPDUMP # 2) में जेनरेट किया गया है, लेकिन डिबेट-सर्व इसे प्राप्त नहीं करता है और आकार में 1500 बाइट्स (1500 के साथ लाइन भेजना जारी रखता है) TCPDUMP # 1 और 6 में 8 से 8, 10, 12, 14, 16, 18 और 20 में TCPDUMP # 2)। हर बार, रिट्रांसमिशन के बीच का समय बढ़ता है (इन उदाहरणों में, मैंने टाइमस्टैम्प को गिरा दिया, लेकिन टीसीपी रेट्रांसमिट तंत्र वास्तव में इस तरह से काम करता है)। इस मामले में, PMTU से बड़ा कोई डेटा प्रेषित नहीं किया जा सकता है। लेकिन अफसोस, टीसीपी को यह पता नहीं है और कनेक्शन स्थापित होने के समय एमएसएस के साथ पैकेट भेजना जारी है। इस स्थिति को पथ MTU डिस्कवरी ब्लैक होल (परिवहन MTU की परिभाषा में ब्लैक होल) कहा जाता है। मैंने इसे अंजीर में सरलीकृत रूप में प्रस्तुत करने की कोशिश की। 3।

अंजीर। 3. पीएमटीयू की परिभाषा में ब्लैक होल।

यह समस्या नई नहीं है। यह 2000 में RFC 2923 में वर्णित है। फिर भी, यह कई प्रदाताओं के बीच उल्लेखनीय तप के साथ मिलना जारी है। लेकिन यह प्रदाता है जो इस स्थिति के लिए दोषी है: उन्हें ICMP टाइप 3 कोड 4 को ब्लॉक करने की आवश्यकता नहीं है। इसके अलावा, वे आम तौर पर "कारण की आवाज़" (यानी, क्लाइंट जो समझते हैं कि समस्या क्या है) को सुनना नहीं चाहते हैं।

पीएमटीयू समस्या का समाधान

हम तकनीकी सहायता नहीं कहेंगे, लेकिन अपने स्वयं के धन के आधार पर समस्या को हल करने का प्रयास करेंगे।
लिनक्स डेवलपर्स, जो इसके बारे में भी जानते हैं, ने iptables में एक विशेष विकल्प प्रदान किया है। आदमी iptables से उद्धरण:

TCPMSS
This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40 for IPv4 or 60 for IPv6, respectively). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table. This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall configuration like:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss value
Explicitly set MSS option to specified value.

--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).

These options are mutually exclusive.

उन लोगों के लिए मेरा मुफ्त अनुवाद जो तंग अंग्रेजी रखते हैं:

TCPMSS
MSS TCP SYN , ( MTU 40 IPv4 60 IPv6). , -p tcp. mangle. , "ICMP Fragmentation Needed" "ICMPv6 Packet Too Big" . – , :
1) , .
2) , .
3) ssh , scp ( : TCP " ").
: , , :
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss
MSS .

--clamp-mss-to-pmtu
MSS (path_MTU - 40 IPv4; -60 IPv6).
.

जैसा कि आप देख सकते हैं, उन्होंने बहुत सी चीजें लिखीं, यहां तक कि अनुमानित समस्या के लक्षण भी बताए। और प्रदाताओं के इस व्यवहार को "आपराधिक अक्षमता (आपराधिक रूप से बहादुर)" कहा जाता था, जिसे मैं पूरी तरह से उनसे सहमत हूं। आइए जानें कि यह विकल्प हमारे उदाहरण में कैसे काम करेगा। डिबेट-सर्व -03 में अनुशंसित नियम जोड़ें:
iptables -t mangle -एक FORWARD -p tcp --tcp-flag SYN, RST SYN -j TCPMSS –set-mss 1360
और देखो क्या हुआ:
TCPDUMP # 1 आउटपुट (एथ0 डिब-सर्व पर):

1 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [s], seq 1484543117, win 5840, options [mss 1360...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [s.], seq 2230206317, ack 1484543118, win 5792, options [mss 1460...], length 0
3 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [p.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 1:2697, ack 118, win 181, options [...], length 2696
7 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 1349, win 2184, options [...], length 0
8 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [.], seq 2697:5393, ack 118, win 181, options [...], length 2696
9 IP 192.168.0.1.80 > 172.16.5.3.33792: flags [fp.], seq 5393:6380, ack 118, win 181, options [...], length 987
10 IP 172.16.5.3.33792 > 192.168.0.1.80: flags [.], ack 2697, win 2908, options [...], length 0

TCPDUMP # 3 आउटपुट (eth0 डिब-सर्व -05 पर):

1 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [S], seq 1484543117, win 5840, options [mss 1460...], length 0
2 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [S.], seq 2230206317, ack 1484543118, win 5792, options [mss 1360...], length 0
3 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1, win 1460, options [...], length 0
4 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [P.], seq 1:118, ack 1, win 1460, options [...], length 117
5 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], ack 118, win 181, options [...], length 0
6 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1:1349, ack 118, win 181, options [...], length 1348
7 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 1349:2697, ack 118, win 181, options [...], length 1348
8 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 1349, win 2184, options [...], length 0
9 IP 172.16.5.3.33792 > 192.168.0.1.80: Flags [.], ack 2697, win 2908, options [...], length 0
10 IP 192.168.0.1.80 > 172.16.5.3.33792: Flags [.], seq 2697:4045, ack 118, win 181, options [...], length 1348

पार्स:
1. लाइनों 1-3 में, हम पहले से ही एक टीसीपी कनेक्शन देखने के आदी हैं। लेकिन एमएसएस मूल्यों पर ध्यान दें। TCPDUMP # 1 में, deb-serv-05 का मान 1360 प्राप्त होता है, जबकि TCDUMP # 3 में यह देखा जा सकता है कि MSS = 1460 वाला एक पैकेट छोड़ रहा है। यह वास्तव में नियम -सेट-एमएस 1360 के साथ काम करता है। यह पासिंग पैकेट के एमएसएस मूल्य को संपादित करता है। SYN पैकेट जो वापस आया, के लिए यह मान भी संपादित किया गया है।
2. दोनों निष्कर्षों की लाइनों 4 और 5 में, हम फिर से एक GET अनुरोध भेजने और प्राप्ति की पुष्टि का निरीक्षण करते हैं।
3. TCPDUMP # 1 के लिए लाइन 6 और TCPDUMP # 3 के लिए लाइनों 6 और 7 में हम डेटा के साथ पैकेट भेजते हुए देखते हैं, लेकिन अब प्रत्येक पैकेट का आकार 1400 बाइट्स से अधिक नहीं है। फिर से, TCPDUMP # 1 के साथ एक अजीब गड़बड़ होती है, जहां एक बड़ा पैकेट दिखाई देता है, जबकि TCPDUMP # 3 में हम 2 पैकेट के आगमन का निरीक्षण करते हैं।
4. इसके अलावा पैकेट विनिमय टीसीपी प्रोटोकॉल के नियमों के अनुसार है। लेकिन कभी भी पैकेट का आकार 1400 बाइट्स से अधिक नहीं था।

एक सरलीकृत रूप में, MSS का व्यवहार अंजीर में दिखाया गया है। 4. मैंने डेटा विनिमय नहीं दिखाया, क्योंकि यह सामान्य व्यवहार के समान है।

अंजीर। 4. मक्खी पर एमएसएस बदलें।

हालांकि मैन आईपटेबल्स में वर्णित दो विकल्प हैं, अब तक मैंने केवल एक ही आवेदन किया है। आपके लिए आवश्यक विकल्प विशिष्ट स्थिति पर निर्भर करता है। सभी स्थितियों को 2 प्रकारों में विभाजित किया जा सकता है:

1. साइटें सामान्य रूप से आपके राउटर पर खुलती हैं; स्थानीय नेटवर्क पर ग्राहकों को समस्याओं का अनुभव होता है।
इस मामले में, पूरे पथ के साथ सबसे छोटा MTU आपके सर्वर पर स्थित है। आमतौर पर ये कुछ एनकैप्सुलेशन प्रोटोकॉल होते हैं, जैसे पीपीपीओई, पीपीटीपी, आदि। इस स्थिति के लिए सबसे अच्छा विकल्प है- क्लैंप-एमएसएस-टू-पीपीटू, जो स्वचालित रूप से सभी ट्रांजिट पैकेट के लिए न्यूनतम एमएसएस निर्धारित करेगा।

2. स्थानीय नेटवर्क पर आपके राउटर और क्लाइंट्स पर, साइटें नहीं खुलती हैं।
इस मामले में, सबसे छोटा एमटीयू प्रदाता के साथ कहीं स्थित है और मानक तरीकों से इसकी गणना करना मुश्किल है। विशेष रूप से इसके लिए, मैंने एक छोटी अजगर स्क्रिप्ट लिखी (वास्तव में पीईपी 8 के बारे में चिंता नहीं की और पैर में गोली चलाने में असमर्थता), जो इस स्थिति के लिए आवश्यक एमएसएस आकार निर्धारित करने में मदद करेगा:

 #!/usr/bin/env python # -*-coding: utf-8 -*- import socket import os import time import sys #        .    # ,    . HOST = 'www.site.local' #  ,        . #       ,  #  -    . TIMEOUT = 25.0 #  ,      ,     #  .      MTU BUF = 3000 #  MTU    . MTU = 1500 #  MSS      MTU-LIM-40  MTU-40.  #    MTU        # 100-200 -        . LIM = 100 #     .     #    . TRY_TIME = 0 def set_mss(mss, action='A'): return os.system("iptables -t mangle -%s OUTPUT -p tcp --tcp-flags \ SYN,RST SYN -j TCPMSS --set-mss %d" % (action, mss) ) def check_connection(host): sock = socket.socket() sock.connect( (host, 80) ) sock.send('GET / HTTP/1.1\r\nHost: %s\r\n\r\n' % host) sock.settimeout(TIMEOUT) try: answer_size = len( sock.recv(BUF) ) except: answer_size = 0 sock.close() return answer_size def main(): mss = MTU - 40 if not check_connection(HOST): mss = MTU - 40 - LIM set_mss(mss) if not check_connection(HOST): set_mss(mss,'D') print "Error: Too small LIM" sys.exit(1) else: while check_connection(HOST): time.sleep(TRY_TIME) set_mss(mss,'D') if mss >= MTU-40: print "Error in determining MSS" sys.exit(1) mss += 1 set_mss(mss) set_mss(mss,'D') mss -= 1 print 'MSS = %d' % (mss) if __name__ == '__main__': main() sys.exit(0)

आपको सुपरसुसर विशेषाधिकारों के साथ स्क्रिप्ट को चलाने की आवश्यकता है। उनके कार्य का एल्गोरिथ्म इस प्रकार है:
1. हम एक सामान्य MSS मान वाली साइट से एक निश्चित मात्रा में डेटा प्राप्त करने का प्रयास कर रहे हैं।
2. यदि यह काम नहीं करता है, तो iptables OUTPUT श्रृंखला पर MSS को MTU - 40 - लीम पर कम करें।
3. यदि उसके बाद भी हम डेटा प्राप्त नहीं कर सकते हैं, तो हमें एक त्रुटि मिलती है कि लिम बहुत छोटा है।
4. लगातार बढ़ते MSS, हम उस क्षण की तलाश कर रहे हैं जब डेटा का आगमन बंद हो जाएगा। उसके बाद हम MSS के अंतिम कार्य मान को घटाते हैं।
5. यदि हमें MSS = MTU-40 मिलता है, तो हम एक त्रुटि बताते हैं कि हम MSS निर्धारित नहीं कर सकते हैं। यह स्थिति त्रुटिपूर्ण है, क्योंकि अनुच्छेद 1 में हम एक समान जांच करते हैं, और यदि परिणाम मेल नहीं खाते हैं, तो यह सोचने का अवसर है।

वांछित एमएसएस प्राप्त करने के बाद, आपको इसे संबंधित नियम में दर्ज करना होगा। आप आँख के द्वारा MSS मान को कम करके स्क्रिप्ट के बिना कर सकते हैं, लेकिन यह सुनिश्चित करने के लिए बेहतर है - पैकेट भेजने के लिए कम ओवरहेड है।

अक्सर मंचों पर आप किसी दिए गए इंटरफ़ेस पर MTU को कम करने के लिए सुझाव पा सकते हैं। आपको यह समझने की आवश्यकता है कि यह एक रामबाण नहीं है, और परिणाम किस इंटरफेस पर कम करने के लिए निर्भर करता है। यदि हम प्रतिभागियों में से किसी एक इंटरफेस पर टीसीपी कनेक्शन कम करते हैं, तो यह प्रभावी होगा, क्योंकि घोषित एमएसएस न्यूनतम पैक्स आकार के अनुरूप होगा। लेकिन अगर ये एंडपॉइंट नहीं हैं, लेकिन ट्रांजिट रूटर्स में से एक है, तो बिना --clamp-mss-to-pmtu विकल्प को सक्षम किए बिना, कोई प्रभाव नहीं होगा।

मुझे उम्मीद है कि यह लेख आपको घर पर और अपने दोस्तों और परिचितों के साथ एक समान समस्या को हल करने में मदद करेगा। एक बार फिर, मैं प्रदाताओं के विशेषज्ञों की ओर रुख करता हूं - बिना किसी आवश्यकता के आवश्यकताओं के लिए ICMP TYPE 3 CODE 4 को बंद न करें - यह आपके सहकर्मियों के लिए समस्याएँ पैदा करता है।

पथ MTU डिस्कवरी ब्लैक होल के बारे में कुछ शब्द

पथ MTU डिस्कवरी ब्लैक होल के बारे में कुछ शब्द

ज्वाइन करने के बजाय

लेख को समझने के लिए आवश्यक शर्तें।

परीक्षण स्थल

पीएमटीयू का सामान्य पता लगाना

पथ MTU डिस्कवरी ब्लैक होल के साथ बैठक

पीएमटीयू समस्या का समाधान

More articles: