Linux IPsec 게이트웨이의 TCP MSS 클램핑: 무엇을 고치는가

핑은 되고 SSH도 되며 작은 페이지는 로드되는데, 그다음에는 모든 큰 응답이 시간 초과까지 멈춥니다. 전형적인 패턴은 도달 가능성이 아니라 패킷 크기를 가리키는데, 경로는 핸드셰이크와 처음 몇 킬로바이트를 나르고, 그다음 전체 크기 세그먼트가 사라집니다. Linux IPsec 게이트웨이에서 TCP MSS 규칙은 흔히 해결책이지만, 그것이 무엇을 바꾸고 그것이 건드리는 패킷이 실제로 어디에 있는지 이해할 때만 그렇습니다. 아래 순서는 증상에서 규칙 배치까지 패킷을 따라가므로, 설명이 더 이상 맞지 않는 지점에서 멈출 수 있습니다.

MSS를 암시하는 증상

TCP는 핸드셰이크에서 최대 세그먼트 크기를 협상한다. 그 값이 캡슐화 후 경로가 나를 수 있는 양보다 크면, 송신자는 결코 도착하지 않는 세그먼트를 계속 만들고 연결은 첫 왕복 후 멈춘다. 작은 응답은 들어가고 큰 응답은 들어가지 않는다.

ICMP 피드백은 경로 MTU 탐색을 통해 연결을 구할 수 있지만, 그 메시지를 버리는 방화벽은 멈춤을 조용한 블랙홀로 만든다. 그래서 같은 터널이 한 애플리케이션에서는 되고 다른 애플리케이션에서는 구성에 뚜렷한 차이도 없이 실패한다.

TCPMSS 규칙이 하는 일과 하지 않는 일

이 규칙은 지나가는 TCP 핸드셰이크 패킷의 MSS 옵션을 다시 쓴다. 터널 인터페이스의 MTU를 설정하지도, IPsec 정책을 바꾸지도 않으며, 현재 커널에서는 이미 더 작은 값을 올리는 대신 광고된 값을 낮출 뿐이다. 또한 TCP만 건드리므로 UDP 페이로드, DNS 동작, 협상된 트래픽 선택자는 그 범위 밖에 있다.

변경이 핸드셰이크 중에 일어나므로 규칙 이전에 맺어진 기존 연결은 옛 값을 유지한다. 새 연결로 시험하고, 변경 후 첫 시도가 무언가를 알려 주는 시도일 것이라고 예상하라. 규칙의 어느 부분도 이미 열린 연결에는 닿지 않는다. 그래서 인시던트 도중에 적용한 수정이 아무것도 하지 않은 것처럼 보일 수 있다.

규칙을 내부 TCP 경로에 두라

정책 기반 Linux 게이트웨이에서 전달되는 패킷은 방화벽이 볼 때 여전히 평범한 TCP처럼 보인다. IPsec 정책은 그 패킷이 보호될 것이라고 결정하지만, 방화벽은 내부 흐름의 ESP 헤더를 보지 못하므로 여기서 ESP와 일치시키는 것은 전혀 다른 패킷을 가리킨다. 이 불일치가 일부 규칙이 옳아 보이면서도 결코 일치하지 않는 이유다.

iptables 용어로 말하면 이 규칙은 전달 경로의 mangle 테이블에 속하며 핸드셰이크 패킷으로 제한된다: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. 이 숫자는 예시일 뿐 보편적인 상수가 아니며, 캡슐화 오버헤드와 경로의 실제 MTU에서 도출하라. nftables의 등가물은 forward 또는 postrouting 체인에서 최대 세그먼트 크기를 설정한다.

IKE와 ESP를 위한 바깥쪽 수신 규칙은 안쪽 전달 규칙과 분리해 두라. 애플리케이션 흐름과 바깥 프로토콜을 동시에 허용하려는 단일 규칙은 결국 둘 중 어느 것과도 안정적으로 일치하지 않는다.

방화벽의 소유자와 NAT 순서를 존중하라

UFW가 호스트 방화벽을 소유한다면, 다음 재로드에서 사라질 명령을 입력하는 대신 지원되는 영구 구성으로 mangle과 전달 변경을 추가하라. 잘못된 테이블에 또는 종단 규칙 뒤에 삽입한 규칙은 효과가 없으며, 살아 있는 테이블은 그 사실을 감춘다.

소스 변환은 별개의 결정이며 종종 이 결정과 상호작용한다. 일반 masquerade 규칙 앞에 둔 예외는 보호된 트래픽이 정책이 요구하는 소스를 잃지 않게 하지만, 크기 문제를 고치지는 않으며 크기 규칙이 변환 문제를 고치지도 않는다.

좁게 검증하고, 그다음 멈춰라

실패하는 서비스에 새 연결을 열고 애플리케이션과 규칙 카운터를 모두 관찰하라. 멈춤이 사라진다면 그 캡슐화를 쓰는 그 TCP 경로에 대한 증거는 얻은 것이다. 모든 VPN 프로토콜이 맞는다거나, 모든 UDP 애플리케이션이 고쳐졌다거나, 특정 상위 서비스가 원래 원인이었다는 증거는 아니다.

정책이 허용하는 곳에서는 ICMP 크기 피드백을 계속 동작하게 두고, 바깥 IPsec 경로가 안쪽 라우트로 표현되지 않을 때는 라우트 MTU에 기반한 자동 클램핑을 조심해서 다뤄라. 결론이 좁을수록 다음 인시던트를 진단하기 쉽다.