Die MSS-reël werk op die router, maar mis Squid

'n Administrateur voeg TCPMSS-klamping by FORWARD. Direkte gerouteerde verkeer verbeter, maar aflaaie deur die plaaslike Squid-instansie hang steeds. Die proxy se webwerfverbinding is nie bloot die kliënt se TCP-verbinding wat deur daardie ketting beweeg nie.

In 'n gewone beëindigende forward-proxy eindig die kliëntgerigte verbinding plaaslik. Die proxy skep 'n tweede TCP-verbinding na die oorsprong of ouer. Op Linux volg die pakkies wat vir daardie verbinding geskep word die plaaslike uitvoerpad.

'n Reël wat net op FORWARD werk, kan dus heeltemal funksioneel wees en tog die handdruk mis wat dit bedoel was om aan te pas. Karteer die werklike verbinding en die rigting van die SYN voordat jy 'n haak kies. Houers of aparte naamruimtes kan nog 'n gerouteerde segment byvoeg, so die korrekte plasing hang daarvan af waar die proses loop.

Moet nie die PMTU-getal direk in MSS sit nie

Pad-MTU is 'n IP-pakkie-grootte. TCP MSS beskryf TCP-lading en moet die betrokke opkoppe in ag neem. Net so is 'n ping-ladinglengte nie die volledige IP-pakkie-lengte nie. Die bekende byvoeging van 28 grepe hoort by 'n basiese IPv4 ICMP-echo-reëling, nie by elke adresfamilie of inkapseling nie.

Die TCPMSS-teiken dokumenteer eksplisiete waardes en PMTU-klamping. Klamping berus steeds op die roete se MTU-inligting; dit is nie bewys dat padontdekking gesond is nie, en ook nie 'n plaasvervanger daarvoor om die nodige ICMP-boodskappe toe te laat nie.

Pas ook die simptoom by die teorie. 'n Voltooide handdruk gevolg deur vasval by groter oordragte kan 'n ondersoek na pakgrootte regverdig. Herhaalde onbeantwoorde SYN's of 'n onmiddellike reset vra 'n wyer verklaring; klein pakkies wat misluk bewys nie 'n te groot datasegment nie.

Hou 'n werkende direkte verbinding en 'n mislukkende proxy-verbinding apart in die verslag. Hulle kan verskillende bronne, roetes en inkapseling gebruik, selfs vanaf dieselfde masjien.