ESP는 제대로 복호화하는데 내부 패킷은 여전히 아무 데도 가지 않는다

ESP 수신 카운터는 올라가고 터널은 살아 있는데 애플리케이션은 패킷을 전혀 보지 못합니다. 복호화는 실행됐고 무결성 검사도 통과했으며, 그다음 수신 측은 보호된 페이로드가 실제로 무엇인지 판단해야 했습니다. 바로 그 마지막 단계에서 형식 불일치가 나타나며, 밖에서 보면 방화벽 문제와 전혀 닮지 않았습니다.

라벨이 거짓말할 때 보이는 것

클라이언트 로그에는 이것을 라우팅 블랙홀과 구별해 주는 것이 없습니다. 둘 다 건강한 터널 옆에서 애플리케이션 타임아웃을 만들기 때문에 카운터가 먼저 의심받습니다.

수신 카운터가 오르는 것은 정말 좋은 소식입니다. 패킷이 도착하고 인증도 통과하고 있습니다. 하지만 그것이 암호 계층 위의 무언가에게 내부 패킷이 의미 있었다는 증거는 아닙니다.

유형은 트레일러에 산다

일반적인 IPsec 터널 모드에서 ESP가 보호하는 페이로드에는 완전한 내부 IP 패킷이 들어 있습니다. 트레일러의 다음 헤더 필드가 그 페이로드가 무엇인지 알려 주며, 그것은 TCP 포트도, 바깥 헤더의 프로토콜 번호도, 초기 SPI와 시퀀스 번호 필드의 일부도 아닙니다. RFC 4303 2.6절 이 필드를 페이로드 유형 필드로 정의하며, 정확한 작업에 정확한 이름입니다.

만나게 될 값은 작고 기억할 만합니다. IPv4는 4(0x04), IPv6는 41(0x29)입니다.

이 숫자들은 지역 관습이 아니라 IANA의 프로토콜 번호 할당에서 나옵니다. IPv4를 선언하면서 IPv6 패킷을 감싸는 송신자는 형식 불일치를 만든 것이며, 자기 라벨에 어긋나는 바이트를 고쳐 주는 방화벽 규칙은 없습니다.

흔한 용의자들과 구별하는 방법

사라진 패킷의 대부분은 인코딩 결함이 아닙니다. 먼저 셀렉터를 확인하세요. IPv6 프리픽스를 제외하는 트래픽 셀렉터는 무엇이든 캡슐화되기 전에 트래픽을 버립니다. 그다음 라우팅, 그다음 수신 호스트의 로컬 필터링을 확인하세요. 이것들이 배제된 뒤에야 페이로드 형식 불일치가 그럴듯한 설명이 됩니다.

암호화된 캡처로는 결론이 나지 않습니다. 보호된 다음 헤더가 암호화된 페이로드 안에 있기 때문입니다. 구현 진단이나 지원되는 복호화 관측 지점이 필요하며, 둘 다 사용 전에 승인이 필요합니다.

아무도 그 증거를 낼 수 없다면 형식 버그가 아닙니다. 이론만 있는 것이고, 셀렉터가 여전히 더 나은 선택입니다.

수리가 아닌 것

트래픽을 통과시키려고 무결성 검사를 끄지 마세요. 중간 라우터에서 암호화된 패킷을 다시 쓰지 마세요. 동작할 수 없고 캡처에서는 도움이 되어 보여도 흐름을 망칩니다. 포트가 막혔다는 추측으로 애플리케이션 방화벽 규칙을 더 넓히지 마세요. 어느 것도 라벨 불일치를 건드리지 않습니다.

확인된 불일치가 상대 구현에서 온 것이라면 최소한으로 정리한 재현을 남기고 그 구현의 지원 채널로 가져가세요.

카운터가 아니라 흐름을 검증하세요

수정 후 실제 IPv6 흐름을 끝에서 끝까지 시험하세요. 터널을 지나는 애플리케이션 요청, 그 응답, 그리고 양쪽이 관찰하는 주소 쌍입니다. ESP 카운터가 오르는 것은 패킷이 수신되고 인증된다는 것만 증명합니다. 내부 패킷이 쓸 만했는지에 대해서는 아무 말도 하지 않습니다.

두 결과를 모두 티켓에 기록하세요. 카운터 움직임과 동작하는 흐름이 함께 있으면 수리이고, 카운터 움직임만 있으면 시작하기 전과 똑같은 상태입니다.