IPv6 패킷이 너무 큽니다: 큰 VPN 전송이 멈추는 이유

핑은 되고, 브라우저는 작은 페이지를 열며, 파일 전송만 멈춥니다—모두 같은 터널을 지나는 IPv6입니다. 이런 패턴은 대개 터널이 느린 것이 아니라 보내는 쪽이 경로의 실제 크기를 배우지 못했다는 뜻입니다. IPv6는 라우터가 Packet Too Big 메시지로 문제를 알리기를 기대하며, 캡슐화는 패킷이 바깥 네트워크에 닿기 전에 부하를 더합니다. 그 메시지가 필터링되면 보내는 쪽은 통과할 수 없는 크기를 계속 반복합니다.

작은 요청, 큰 멈춤

터널은 각 패킷을 또 다른 헤더로 감싸므로 안쪽에서 쓸 수 있는 크기는 바깥 크기보다 작습니다. 캡슐화 전에 물리 링크에 맞춰 측정된 패킷은 그 뒤에 너무 커집니다. IPv4 라우터는 경로에서 단편화할 수 있지만 IPv6 라우터는 보내는 쪽을 대신해 그렇게 하지 않으므로 보내는 쪽이 스스로 조정해야 합니다. 그리고 그 조정은 전적으로 피드백을 받는 데 달려 있습니다.

메시지 하나가 유실되면 전형적인 증상이 생깁니다—핸드셰이크와 작은 응답은 성공하고, 디렉터리 목록이나 업로드는 매번 같은 지점에서 멈춥니다. 사용자는 VPN이 느리다고 표현하고, 로그에는 인증 문제가 전혀 나타나지 않습니다. 두 관찰 모두 정확하며 어느 것도 결함의 위치를 찾지 못합니다.

Packet Too Big는 피드백이며 트래픽이 아닙니다

ICMPv6 Packet Too Big 메시지는 다음 홉이 받아들일 수 있는 크기를 담고 있고, 보내는 쪽은 그것으로 자신의 추정치를 낮춥니다. 그것을 필터링하는 것은 도로 표지를 없앤 뒤 운전자를 탓하는 것과 같습니다. 모든 ICMPv6를 버리는 규칙은 엄격해 보이지만 그것이 필요한 모든 링크에서 경로 탐색을 깨뜨립니다. 이 메시지는 경로에 대한 제어 정보이며 애플리케이션 페이로드가 아닙니다.

선택적 필터링은 여전히 합리적입니다. 에코 요청과 이웃 탐색은 오류 메시지와 다른 역할을 하며, 정책은 이를 다르게 다룰 수 있습니다. 프로토콜 전체를 받아들이거나 버리는 대신 플랫폼의 문서화된 필터링 지침을 따르십시오—왜냐하면 RFC 8201이 그 피드백이 탐색을 어떻게 이끄는지 정의하기 때문입니다.

두 주소 체계를 따로 시험하십시오

IPv6를 따로 시험하십시오—IPv4 전송이 성공해도 IPv6 경로에 대해서는 아무것도 증명하지 않습니다. 그다음 큰 전송이 멈춰 있는 동안 제어 메시지를 캡처하십시오. 두 기록을 함께 보면 피드백이 나가는지, 아니면 애초에 도착하지 않았는지 알 수 있습니다.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

프로브는 do-not-fragment 비트를 켠 패킷을 보내고 실패하는 크기를 보고합니다—그것이 터널이 감당해야 하는 숫자입니다. 경로 질의는 목적지를 실어 나를 인터페이스를 알려 주므로 어느 링크의 MTU가 적용되는지 알 수 있습니다. 캡처는 ICMPv6 유형 2, 즉 Packet Too Big 메시지를 걸러 내고 그것이 이 호스트에 도달하는지 보여 줍니다. 메시지가 캡처에 나타나는데 전송이 계속 멈춘다면 보내는 쪽이 이를 무시하는 것이며, 조사는 네트워크가 아니라 스택으로 옮겨 갑니다.

증거가 나온 뒤에만 터널 크기를 조정하십시오

터널 MTU를 낮추면 필터링된 메시지를 숨겨 증상을 없앨 수 있지만, 모든 패킷에 더 큰 부하가 드는 대가가 따릅니다. 그것은 진단이 아니라 우회이며, 캡처를 대체하는 것이 아니라 그 뒤를 따라야 합니다. 임의로 낮은 값도 눈에 보이게 무언가를 깨뜨리지 않기 때문에 설정에 수년씩 남습니다. 의도적으로 바꾸고, 값을 기록하고, 어떤 측정이 그것을 정당화했는지 적어 두십시오.

게이트웨이를 관리한다면 방화벽을 끄는 대신 메시지를 버리는 규칙을 살펴보십시오. 수정된 규칙 하나는 정책 예외보다 좁고 나중에 변호하기 훨씬 쉽습니다. 같은 논리가 타임아웃에도 적용됩니다—모든 멈춤이 크기 문제는 아니며, 둘을 구분해 주는 것은 캡처입니다.