Windows L2TP ले केही साइट मात्र लोड गर्छ: pfSense मा DF बिट खाली गर्नुहोस्

ल्यापटप जोडिन्छ, इन्ट्रानेट लोड हुन्छ, र केही सार्वजनिक साइट अड्किन्छन्। प्रमाणीकरण र राउटिङ स्पष्ट रूपमा काम गरिरहेका छन्, जसले व्याख्याका रूपमा प्याकेटको आकार छोड्छ। 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 देखाउँछन्।

फेरि प्रयास गर्नुअघि स्थिति तालिका खाली गर्नुहोस्, किनभने भएका प्रवाहले आफ्ना पुराना खण्ड आकार राख्छन्। त्यसपछि असफल पृष्ठ लोड गर्नुहोस् र एकतर्फी काउन्टरको सट्टा दुईतर्फी ट्राफिकका लागि स्थिति दृश्य पढ्नुहोस्। अझै अड्किन्छ भने अर्को चेकबक्स प्रयास गर्नुको सट्टा फेरि क्याप्चर गर्नुहोस्।