लॅपटॉप जोडला जातो, इंट्रानेट लोड होते, आणि काही सार्वजनिक साइट्स अडकतात। प्रमाणीकरण आणि राउटिंग स्पष्टपणे काम करत आहेत, त्यामुळे स्पष्टीकरण म्हणून पॅकेटचा आकार उरतो। L2TP/IPsec टनेलमध्ये वापरण्यायोग्य MTU अॅडॉप्टर अजूनही जाहीर करत असलेल्यापेक्षा लहान आहे, आणि क्लायंट «विभाजित करू नका» बिट सेट करून पूर्ण आकाराचे पॅकेट पाठवत राहतो। pfSense गेटवेला तो बिट साफ करण्याचा आदेश दिला जाऊ शकतो, आणि नीट दुरुस्त करण्यापूर्वी निदानाची पुष्टी करण्याचा हा सर्वात वेगवान मार्ग आहे।

अयशस्वी होणाऱ्या पानांपासून सुरुवात करा

कोणतेही सेटिंग हाताळण्यापूर्वी कोणती गंतव्ये अयशस्वी होतात आणि कोणती यशस्वी होतात ते लिहून ठेवा। टनेलच्या मर्यादेखाली राहणारे हॅंडशेक सामान्यपणे पूर्ण होतात, तर पूर्ण आकाराच्या खंडाची गरज असलेली स्थानांतरे अर्ध्यावर थांबतात। हे विभाजन फिल्टरचे नाही तर आकाराच्या समस्येचे लक्षण आहे, कारण अडवलेले गंतव्य पानाच्या मध्ये नाही तर कनेक्शन स्थापित होताना अयशस्वी होते। दोन्ही निरीक्षणे काहीही खर्च करत नाहीत आणि शोध लगेच संकुचित करतात।

बिट सेट करणारे आणि पेलोडचा आकार नियंत्रित करणारे ping वापरून तपासा। जास्तीत जास्त पेलोड जो पार होतो तो तुम्हाला मार्गाचा खरा MTU सांगतो, आणि अॅडॉप्टरचे जाहीर मूल्य दोन्ही किती दूर आहेत हे दाखवते।

दोन्ही आकडे लिहून ठेवा। दुरुस्ती कोणता चुकीचा आहे यावर अवलंबून आहे, आणि तीच जोडी नंतर कॅप्चर पुष्टी करते।

बाहेर जाताना DF बिट काय करतो

आकड्यांमध्ये फरक पडण्याचे कारण एन्कॅप्स्युलेशन आहे। IPsec ESP जोडते, L2TP अजून एक हेडर जोडते, आणि म्हणून टनेल भौतिक लिंकपेक्षा कमी पेलोड वाहून नेते। Windows अजूनही अॅडॉप्टरवर 1500 बाइट नोंदवते आणि पाठवत असलेल्यावर «विभाजित करू नका» सेट करते। असे पॅकेट न बसल्यास, गेटवेकडून योग्य उत्तर पाठवणाऱ्याला लहान होण्याची विनंती करणारा ICMP संदेश आहे। म्हणूनच लहान ping पार करणारे टनेलही फाइल डाउनलोड अयशस्वी करू शकते।

तो संदेश बऱ्याचदा कधीच पोहोचत नाही। एखादा हॉप ICMP फिल्टर करू शकतो, किंवा काहीही तो तयार करत नाही, आणि स्थानांतर हार मानेपर्यंत पाठवणारा तोच आकार पुन्हा करतो।

इथे शांतता ही सामान्य मांडणी आहे, म्हणूनच लक्षण निवडक अडवणूक म्हणून वाचले जाते। क्लायंट लॉगमध्ये गहाळ ICMP संदेश काहीही नोंदवत नाही।

pfSense पर्याय, आणि तो काय करत नाही

पर्याय सिस्टम, प्रगत, फायरवॉल आणि NAT पानावर «पॅकेट टाकून देण्याऐवजी अवैध DF बिट साफ करा» या लेबलसह आहे। ध्वज वाहून नेणारे जास्त मोठे पॅकेट टाकून देण्याऐवजी फिल्टर ध्वज काढून टाकते आणि पॅकेटला पुढे विभाजित होऊ देते। पॅकेट बाहेर जाणाऱ्या इंटरफेसला एका तुकड्यात ओलांडू शकत नाही तेव्हा ते अवैध मानले जाते।

पर्याय क्लायंटला हात न लावता कनेक्टिव्हिटी पुनर्संचयित करतो, म्हणूनच तो लोकप्रिय आहे। तो एक तात्पुरता उपायही आहे: विभाजन CPU खर्च करते आणि प्रत्येक गमावलेला तुकडा अधिक महाग करते।

तो केवळ पुढे पाठवलेल्या रहदारीवर लागू होतो, फायरवॉल स्वतः निर्माण करणाऱ्या रहदारीवर नाही। तेच पान «फायरवॉल स्क्रब अक्षम करा» देते, जे सामान्यीकरण पूर्णपणे बंद करते, आणि हा या समस्येला आवश्यक असलेल्यापेक्षा खूप मोठा बदल आहे।

TCP विभाजित न ठेवणारी अधिक मर्यादित दुरुस्ती

अडकलेले प्रवाह जवळजवळ सर्व TCP आहेत, आणि TCP विभाजनावर अवलंबून न राहता लहान खंडावर बोलणी करू शकतो। टनेल इंटरफेसवर MSS मर्यादित केल्यास हॅंडशेक दरम्यान जाहीर मूल्य पुन्हा लिहिले जाते, त्यामुळे प्रत्येक बाजू प्रत्यक्षात बसते ते पाठवते। मग मार्ग अंदाजे वागतो आणि कोणतेही पॅकेट विभाजित करण्याची गरज नसते।

यामुळे UDP शोध किंवा DF पर्यायावर सोडले जाते। अयशस्वी साइट्स सामान्य वेब पाने असल्यास, मर्यादाच प्राधान्य देण्याजोगा बदल आहे।

क्लायंट netsh interface ipv4 show subinterfaces द्वारे आपला अॅडॉप्टर MTU कळवू शकतो। तो आकडा सर्व्हरने बोलणी झाली असे मानलेल्या मूल्याशी तुलना करा, कारण दोन्ही नेहमी सारखे नसतात। बोलणीने काहीही कळवले तरी ऑपरेटिंग सिस्टम प्रत्यक्षात वापरणारे मूल्य तेच आहे।

कॅप्चरने पुष्टी करा, नंतर स्थिती रीसेट करा

निर्णय घेण्यापूर्वी दोन्ही बाजूंनी कॅप्चर करा: टनेल जिथे जाते तिथे एक ट्रेस, आणि WAN इंटरफेस जिथे जातो तिथे दुसरा। पूर्ण आकारात बाहेर पडणारे आणि ICMP परत न येणारे पॅकेट मर्यादेकडे योग्य स्तर म्हणून निर्देश करतात। येऊन नंतर परतीच्या मार्गावर मरणारी उत्तरे त्याऐवजी टनेलच्या MTU कडे निर्देश करतात।

पुन्हा प्रयत्न करण्यापूर्वी स्थिती तक्ता साफ करा, कारण विद्यमान प्रवाह त्यांचे जुने खंड आकार ठेवतात। नंतर अयशस्वी पान लोड करा आणि एकतर्फी काउंटरऐवजी दुतर्फी रहदारीसाठी स्थिती दृश्य वाचा। तरीही अडकत असेल, तर दुसरा चेकबॉक्स करून पाहण्याऐवजी पुन्हा कॅप्चर करा।

संबंधित लेख