듀얼 스택 VPN: 주소 패밀리를 고르는 것은 클라이언트이지 당신이 아닙니다

터널은 올라와 있고 IPv4 사이트는 로드되며 호스트 이름 하나만 시간 초과됩니다. 즉시 'VPN이 고장 났거나 자격 증명이 틀렸다'고 결론 내리지만 보통 둘 다 사실이 아닙니다. 이름은 IPv4와 IPv6 주소를 모두 반환했고 애플리케이션은 하나를 골랐으며 그 후보 중 실제로 경로가 동작한 것은 하나뿐이었습니다. 선택은 클라이언트가 한 것이고, 터널은 그저 선택된 것을 커버하지 못했을 뿐입니다.

선택은 커버리지에 대한 약속이 아닙니다

RFC 6724에 설명된 기본 주소 선택은 여러 후보가 있을 때 호스트가 어떤 출발지-목적지 쌍을 선호할지 결정합니다. Happy Eyeballs는 그 위에 연결 전략을 더합니다. 두 패밀리 모두에서 시도를 시작하고 먼저 응답한 쪽을 유지하므로 사용자는 고장 난 패밀리의 시간 초과를 기다리지 않습니다.

어느 메커니즘도 경로를 만들지 않습니다. 터널이 IPv4만 전달한다면 AAAA 후보는 여전히 클라이언트가 시도할 수 있는 정당한 목적지이며, 실패는 오류가 아니라 느린 로딩으로 나타납니다. 브라우저가 폴백하기 때문입니다. 사용자는 '고장 난 사이트'가 아니라 '느린 사이트'를 보고하고 지원 티켓도 그 모호함을 물려받습니다. 고정된 패밀리로 재현하면 보고가 구체적으로 바뀝니다.

그 폴백 때문에 증상이 애플리케이션마다 일관되지 않습니다. 브라우저는 지연을 숨기고, 패밀리를 고정한 명령줄 클라이언트는 실제 실패를 즉시 보여 줍니다.

요청이 실제로 사용한 패밀리를 찾으세요

터널이 아니라 이름부터 시작하세요. 두 레코드 유형을 모두 조회하고 무엇이 돌아왔는지 기록하세요:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

v4 요청이 성공하고 v6 요청이 실패한다면 디버그할 수 있는 형태로 문제를 재현한 것입니다. 셸에서는 둘 다 성공하는데 브라우저가 계속 실패한다면 터널을 건드리기 전에 애플리케이션 자체의 리졸버나 캐시된 응답을 확인하세요.

패밀리와 목적지를 메모에 남기세요. 'VPN으로 사이트가 로드되지 않는다'는 티켓은 아무도 검증할 수 없지만, 'AAAA는 실패하고 A는 동작한다'는 티켓은 특정 경로를 가리킵니다.

해당 패밀리의 경로를 확인하세요

실패하는 패밀리에 대해 커널에 어떤 경로를 쓸지 물어보고 터널에 설정된 주소와 비교하세요. Linux에서는 ip -6 route get이(가) 목적지에 대해 선택될 인터페이스와 출발지를 보여 줍니다.

그다음 터널 자체를 확인하세요. WireGuard 피어는 허용 IP 목록을 가지며 0.0.0.0/0 항목은 IPv6에 대해 아무것도 말하지 않습니다. 피어 목록에 IPv6 접두사가 없다면 클라이언트가 AAAA 트래픽을 터널로 보낼 이유가 없고, 패킷은 호스트가 원래 하던 경로로 빠져나갑니다.

방화벽 규칙과 NAT 정책도 패밀리별로 같은 확인이 필요합니다. IPv4용으로 작성된 규칙은 어떤 플랫폼에서도 IPv6를 포함하지 않으며, 한 패밀리만 동작하는 가장 흔한 이유입니다.

스크린샷을 간단히 하려고 IPv6를 끄지 마세요

IPv6를 시스템 전체에서 끄면 증상은 사라지지만 진단은 남지 않습니다. IPv6 전용 목적지도 깨지고 다음 애플리케이션을 위해 같은 버그를 숨기게 됩니다. 어떤 머신이 정말 IPv6를 쓰지 말아야 한다면 그것은 소유자와 테스트가 있는 의도된 정책입니다. 장애 대응 중에 끄는 것은 둘 다 아닙니다.

클라이언트가 패밀리를 어떻게 다뤄야 하는지 정하고 명시적으로 설정하세요: 터널을 통해 전달하거나, 지원되는 방식으로 차단해 선택이 도달할 수 없는 후보를 절대 제시하지 않게 하세요. 둘 다 정당한 설계입니다. 전역 비활성화는 둘 다 아니며, 설계라고 할 수도 없습니다.

티켓에 무엇을 적을까

네 가지를 기록하세요. 호스트 이름, 실패한 패밀리, 커널이 고른 경로, 패밀리별 요청의 결과입니다. 이 정도면 다른 사람이 두 경로 중 어느 쪽을 말했는지 추측하지 않고도 실패를 재현할 수 있습니다.

RFC 6724 주소 선택 규칙은(는) 클라이언트가 왜 그 후보를 선호했는지 설명하고, RFC 8305는 지연을 숨긴 경쟁 동작을 설명합니다. 둘 다 당신을 위해 패킷을 라우팅하지는 않으며, 바로 그 부분을 터널이 해야 합니다.