IPsec 오버헤드: 모드, NAT-T, 알고리즘이 모두 바꿉니다

어떤 가이드의 어딘가에는 보통 육십에서 팔십 바이트 사이의 숫자가 있는데, 누군가가 1500에서 빼서 인터페이스 MTU를 구한 값입니다. 그 숫자는 특정 경로 위의 특정 캡슐화를 설명합니다. 모드, 외부 주소 체계, 암호 방식 또는 NAT의 유무를 바꾸면 그 계산은 더 이상 당신의 터널에 적용되지 않습니다.

그 숫자는 다른 터널에서 온 것이다

오버헤드는 추상적 의미에서 IPsec의 속성이 아니라 실제로 만들어지는 패킷의 속성입니다. 협상된 모드, 외부 헤더, 보호 헤더, 패딩, 무결성 필드, 그리고 어쩌면 추가 UDP 래퍼까지입니다.

IPv4에 NAT 없는 전송 모드에 대해 인용되는 수치는 NAT 통과 아래의 IPv6 터널 모드보다 작은 패킷을 설명합니다. 둘 다 각자의 경우에는 맞습니다. 둘 중 하나를 다른 배포에 복사하는 것이 바로 큰 전송을 깨뜨리는 MTU로 끝나는 방식입니다. 작은 요청은 계속 동작하므로 실패는 조용합니다.

실제로 있는 계층을 더하라

외부 IP 헤더에서 시작해 안쪽으로 들어가세요. 터널 모드에서는 원래 패킷이 안에 있으므로 외부 헤더는 대체가 아니라 추가입니다. RFC 4303 ESP 헤더, 패딩, 그 뒤를 따르는 무결성 데이터를 설명합니다.

그 행들 중 어느 것도 배포마다 일정하지 않고, 패딩 행은 한 배포 안에서도 일정하지 않습니다. 공개된 단일 오버헤드 수치가 실망스러운 이유가 바로 이것입니다.

두 사이트가 같은 터널에 대해 다를 수 있다

보호된 패킷은 여전히 외부 경로를 지나야 하고, 외부 경로는 어디서나 같지 않습니다. PPPoE 액세스 회선은 깨끗한 Ethernet 세그먼트보다 적게 나릅니다. 이동통신망은 더 줄어들 수 있고, 자기 트래픽을 터널링하는 사업자는 아무도 언급하지 않은 또 하나의 캡슐화를 더합니다. 한 회선에서 동작하고 다른 회선에서 실패하는 터널은 두 번째 회선을 설명하는 것이지 프로토콜을 설명하는 것이 아닙니다.

두 방향이 다를 수도 있습니다. 비대칭 경로는 업로드는 되고 다운로드는 멈추는 형태를 만들 수 있는데, 이는 도달 가능성이 아니라 패킷 크기를 보기 전까지는 응용 프로그램 문제로 읽힙니다. 작은 ping이 성공한다는 것은 전체 크기 응답에 대해 거의 아무것도 증명하지 못합니다.

빼지 말고 측정하라

경로를 통과하는 가장 큰 데이터그램을 찾으세요. 그다음 인터페이스가 보고하는 값과 비교하세요:

ip link show eth0 | grep -o 'mtu [0-9]*'
ip xfrm state list
ping -M do -s 1400 198.51.100.7
ping -M do -s 1372 198.51.100.7
tcpdump -ni any -c 20 'esp or udp port 4500'

응답이 올 때까지 ping 크기를 낮추고, 동작하는 가장 큰 값을 그 경로의 예산으로 삼으세요. xfrm 출력은 어떤 모드와 어떤 알고리즘이 협상되었는지 알려 주며, 그것이 어떤 정직한 계산의 입력입니다. 캡처는 회선 위에 ESP가 있는지 UDP로 캡슐화된 ESP가 있는지 확인해 주고, 그것으로 NAT 문제가 추측 없이 정리됩니다.

제어 평면을 위해 값 하나를 따로 두세요. IKE 핸드셰이크 패킷은 데이터 패킷과 구조가 다르므로, 핸드셰이크 캡처에서 도출한 크기는 데이터 평면의 MTU가 아닙니다.

숫자를 제자리에 두라

터널을 지나는 TCP의 경우, MSS 클램프는 터널 자체를 바꾸지 않고 끝점이 보내는 양을 줄이므로 흔히 가장 침습이 적은 제어입니다. 경로 기반 터널에서는 터널 인터페이스의 MTU를 의도적으로 설정하고 그 이유를 기록하세요. 둘을 한꺼번에 하고 나서 측정하면 어느 쪽이 도움이 되었는지 아무 정보도 얻지 못합니다.

협상된 모드, 외부 체계, NAT 상태, 재현 가능한 증상을 티켓에 함께 남기세요. 기록된 네 가지 사실은 기억 속 상수보다 낫고, 다음 클라이언트 업그레이드까지 살아남는 것은 이 형태뿐입니다.