Az MSS-szabály működik a routeren, de elkerüli a Squidet

A rendszergazda TCPMSS-korlátozást ad a FORWARD-hoz. A közvetlenül irányított forgalom javul, de a helyi Squid-példányon keresztüli letöltések továbbra is elakadnak. A proxy webhelykapcsolata nem egyszerűen az ügyfél TCP-kapcsolata, amely áthalad ezen a láncon.

Egy szokásos, a kapcsolatot lezáró forward proxyban az ügyfél felé menő kapcsolat helyben véget ér. A proxy egy második TCP-kapcsolatot hoz létre az eredet vagy a szülő felé. Linuxon az ehhez a kapcsolathoz generált csomagok a helyi kimeneti útvonalat követik.

A csak FORWARD-ra vonatkozó szabály tehát teljesen működőképes lehet, és mégis elvéti a kézfogást, amelyet módosítania kellett volna. A hook kiválasztása előtt térképezze fel a tényleges kapcsolatot és a SYN irányát. A konténerek vagy külön névterek további irányított szakaszt adhatnak, ezért a helyes elhelyezés attól függ, hol fut a folyamat.

Ne tegye a PMTU-számot közvetlenül az MSS-be

Az útvonal MTU IP-csomagméret. A TCP MSS a TCP hasznos terhelést írja le, és figyelembe kell vennie a vonatkozó fejléceket. Hasonlóképpen, a ping hasznos terhelésének hossza nem a teljes IP-csomag hossza. Az ismert 28 bájtos hozzáadás egy alapvető IPv4 ICMP echo elrendezéshez tartozik, nem minden címcsaládhoz vagy beágyazáshoz.

A TCPMSS cél explicit értékeket és PMTU-korlátozást dokumentál. A korlátozás továbbra is az útvonal MTU-információjára támaszkodik; nem bizonyítja, hogy az útvonalfelderítés egészséges, és nem helyettesíti a szükséges ICMP-üzenetek engedélyezését.

A tünetet is illessze az elmélethez. A befejezett kézfogás és az azt követő megakadás nagyobb átvitelnél indokolhatja a csomagméret vizsgálatát. Az ismételt válasz nélküli SYN-ek vagy az azonnali reset szélesebb magyarázatot igényel; a kis csomagok kudarca nem bizonyít túl nagy adatszegmenst.

A feljegyzésben tartsa külön a működő közvetlen kapcsolatot és a hibázó proxykapcsolatot. Különböző forrásokat, útvonalakat és beágyazást használhatnak, akár ugyanarról a gépről.