MSS नियम राउटरवर काम करतो, पण Squid पर्यंत पोहोचत नाही

प्रशासक FORWARD मध्ये TCPMSS क्लॅम्पिंग जोडतो. थेट राउट केलेला रहदारी सुधारतो, पण स्थानिक Squid प्रतलीद्वारे डाउनलोड अजूनही अडकतात. प्रॉक्सीचे वेबसाइटशी जोडणी केवळ क्लायंटची TCP जोडणी त्या साखळीतून जाणे नाही.

सामान्य समाप्त करणाऱ्या फॉरवर्ड प्रॉक्सीमध्ये क्लायंटच्या बाजूची जोडणी स्थानिक पातळीवर संपते. प्रॉक्सी मूळ किंवा पालकाकडे दुसरी TCP जोडणी तयार करते. Linux वर त्या जोडणीसाठी तयार केलेले पॅकेट स्थानिक निर्गम मार्गाचे अनुसरण करतात.

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

PMTU क्रमांक थेट MSS मध्ये ठेवू नका

मार्गाचा MTU हा IP पॅकेटचा आकार आहे. TCP MSS TCP पेलोडचे वर्णन करतो आणि संबंधित शीर्षलेख विचारात घेतले पाहिजेत. त्याचप्रमाणे, ping पेलोडची लांबी संपूर्ण IP पॅकेटची लांबी नाही. ज्ञात 28 बाइटची बेरीज मूलभूत IPv4 ICMP echo रचनेशी जोडलेली आहे, प्रत्येक पत्ता कुटुंब किंवा एन्कॅप्स्युलेशनशी नाही.

TCPMSS लक्ष्य स्पष्ट मूल्ये आणि PMTU क्लॅम्पिंगचे दस्तऐवजीकरण करते. क्लॅम्पिंग अजूनही मार्गाच्या MTU माहितीवर अवलंबून आहे; ते मार्ग शोध निरोगी असल्याचा पुरावा नाही, आणि आवश्यक ICMP संदेशांना परवानगी देण्याचा पर्यायही नाही.

लक्षण सिद्धांताशीही जुळवा. पूर्ण झालेली हातमिळवणी आणि नंतर मोठ्या हस्तांतरणांमध्ये अडकणे पॅकेट आकाराच्या तपासणीचे समर्थन करू शकते. वारंवार उत्तर न मिळणारे SYN किंवा तात्काळ reset ला व्यापक स्पष्टीकरण आवश्यक आहे; लहान पॅकेट अपयशी ठरल्याने अत्यधिक मोठा डेटा विभाग सिद्ध होत नाही.

नोंदीत कार्यरत थेट जोडणी आणि अपयशी प्रॉक्सी जोडणी वेगळी ठेवा. एकाच यंत्रावरूनही ते वेगळे स्रोत, मार्ग आणि एन्कॅप्स्युलेशन वापरू शकतात.