כלל MSS עובד בנתב, אך מפספס את Squid
החילו את היגיון ה-MTU על חיבורי ה-TCP הנפרדים שנפתחים על ידי פרוקסי, במקום להניח שכל מנה עוברת ב-FORWARD.
מנהל מוסיף ריסון TCPMSS ל-FORWARD. תעבורה מנותבת ישירות משתפרת, אך הורדות דרך מופע Squid המקומי עדיין נתקעות. החיבור של הפרוקסי לאתר אינו פשוט חיבור ה-TCP של הלקוח שעובר בשרשרת הזו.
בפרוקסי קדמי רגיל שמסיים את החיבור, החיבור בצד הלקוח מסתיים מקומית. הפרוקסי יוצר חיבור TCP שני אל המקור או ההורה. ב-Linux, המנות שנוצרות עבור אותו חיבור הולכות בנתיב הפלט המקומי.
לכן כלל שמוגבל ל-FORWARD יכול להיות תקין לחלוטין ובכל זאת לפספס את לחיצת היד שהוא נועד לכוונן. מפו את החיבור בפועל ואת כיוון ה-SYN לפני בחירת נקודת התערבות. מכולות או מרחבי שמות נפרדים יכולים להוסיף מקטע מנותב נוסף, ולכן המיקום הנכון תלוי היכן התהליך פועל.
אל תניחו את מספר ה-PMTU ישירות ב-MSS
ה-MTU של הנתיב הוא גודל מנת IP. ה-MSS של TCP מתאר את המטען של TCP וחייב להתחשב בכותרים הרלוונטיים. באותו אופן, אורך המטען של ping אינו אורך מנת ה-IP המלא. התוספת המוכרת של 28 בתים קשורה לסידור בסיסי של IPv4 ICMP echo, ולא לכל משפחת כתובות או אנקפסולציה.
יעד TCPMSS מתעד ערכים מפורשים וריסון PMTU. הריסון עדיין נשען על מידע ה-MTU של המסלול; הוא אינו הוכחה שגילוי הנתיב תקין, ואינו תחליף להתרת הודעות ה-ICMP הנדרשות.
התאימו גם את הסימפטום לתאוריה. לחיצת יד שהושלמה ואחריה תקיעות בהעברות גדולות יכולה להצדיק בדיקת גודל המנה. SYN חוזרים ללא מענה או reset מיידי דורשים הסבר רחב יותר; כשל של מנות קטנות אינו מוכיח מקטע נתונים גדול מדי.
שמרו בתיעוד בנפרד חיבור ישיר שעובד וחיבור פרוקסי שנכשל. הם יכולים להשתמש במקורות, במסלולים ובאנקפסולציה שונים, אפילו מאותו מחשב.