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이 오면 더 넓은 설명이 필요합니다. 작은 패킷의 실패는 지나치게 큰 데이터 세그먼트를 입증하지 않습니다.

기록에서 정상 동작하는 직접 연결과 실패하는 프록시 연결을 분리해 두십시오. 같은 장비에서도 서로 다른 출발지, 경로, 캡슐화를 쓸 수 있습니다.