자체 리소스로 VPN을 통해 IPv6를 테스트하는 방법

공용 IP 검사 페이지는 한 가지 질문에 답하며, 보통은 여러분이 던진 질문이 아닙니다. 페이지가 본 출구 주소를 알려줄 뿐, 터널을 지나는 IPv6 경로가 작동하는지, 호스트가 IPv6를 선호했는지 아니면 되돌아갔는지, 제외된 애플리케이션이 다른 경로를 택했는지는 알려주지 않습니다. 직접 관리하는 승인된 리소스는 양쪽 끝을 볼 수 있으므로 더 좁은 질문에 제대로 답합니다. 아래 절차는 방어할 수 있는 결론에 이르는 것에 관한 것이지, 초록색 결과를 얻는 것에 관한 것이 아닙니다.

1단계: 어떤 IPv6 경로를 테스트하는지 밝히세요

한 문장으로 말하세요. 터널 서버 자체의 IPv6 주소로 보내는 요청은 터널을 테스트하고, 출구 너머의 호스트로 보내는 요청은 출구의 IPv6 이그레스를 테스트하며, 사설 IPv6 주소로 보내는 요청은 내부 경로를 테스트합니다.

이것은 서로 다른 세 가지 주장이며 성공한 요청 하나로 모두를 뒷받침할 수 없습니다. 앞에 놓인 결정에 중요한 하나를 고르고 무엇이든 실행하기 전에 적어 두세요. 걱정이 터널 주변으로 IPv6가 새는지 여부라면, 질문은 호스트의 경로 선택에 관한 것이지 출구의 도달 가능성에 관한 것이 아닙니다. 걱정이 먼 쪽이 내부 서비스에 도달할 수 있는지 여부라면 출구는 무관합니다.

2단계: 호스트가 그 경로를 선택하는지 확인하세요

ip -6 route get 2001:db8:1::10 경로, 원본 주소, 커널이 사용할 인터페이스를 출력하며 나머지 테스트는 이 사실에 달려 있습니다.

인터페이스가 존재하는 것과 선택되는 것은 다릅니다. 이중 스택 호스트에는 우선순위 표가 있고, Linux에서 /etc/gai.conf는 두 주소로 모두 확인되는 이름에 대해 어느 패밀리가 이길지 바꿀 수 있습니다.

3단계: 정당한 목적지와 이름을 사용하세요

HTTPS를 테스트한다면 인증서가 발급된 호스트 이름을 사용하고 검증을 켜 두고, 테스트를 통과시키려고 리터럴 주소로 바꾸면, 의도한 호스트에 도달했음을 증명하는 바로 그 검사를 끄게 됩니다. 직접 관리하는 진단 서비스가 알려진 이름에서 유효한 인증서로 응답한다면 그것이 가장 깔끔한 대상입니다. 또한 대조할 수 있는 서버 측 로그 한 줄도 주는데, 외부 검사기는 결코 주지 않습니다.

사용한 주소를 보여 주는 형태로 요청을 실행하세요: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. -6는 패밀리를 강제하며, 이렇게 해서 IPv6가 작동하지 않음과 IPv6가 선호되지 않았음을 구분합니다.

ICMPv6가 허용되는 순수한 도달성 확인에는 ping -6 -c 3 2001:db8:1::10로 충분합니다. 경로를 증명할 뿐 그 위의 것은 아무것도 아닙니다.

4단계: 양쪽 끝을 대조하세요

양쪽 끝에 접근할 수 있다면 클라이언트에서 tcpdump -ni any ip6 and host 2001:db8:1::10를, 리소스에서 그에 상응하는 것을 타임스탬프와 함께 실행하고 같은 흐름이 양쪽에 나타나는지 확인하고, 이것이 그럴듯한 결과를 증거로 바꿉니다. 클라이언트의 시야만으로는 리소스의 응답과 중간의 무언가가 보낸 응답을 구별할 수 없습니다. 캡처는 하나의 목적지로 좁게 유지해 출력이 읽히고 다른 사람의 무관한 세션이 파일에 들어가지 않게 하세요.

정책이 재시작을 견디는지가 걱정이라면 다시 연결한 뒤 테스트를 반복하세요. 연결 시 한 번 적용된 경로와 방화벽 상태는 다시 적용되는 상태와 다를 수 있고, 그 차이는 두 번째 연결에서만 드러납니다.

필요하다면 실패 사례를 따로 테스트하세요. 끊길 때 IPv6를 차단하는 터널과 그것을 누출하는 터널은 서로 다른 설계이며, 성공한 요청으로 확인할 수 있는 것은 둘 중 하나뿐입니다.

5단계: 테스트가 증명하지 않은 것을 적으세요

다섯 번째 단계는 테스트가 증명하지 않은 것을 적는 것이며, 바로 이 부분이 빠지기 쉽습니다. 사설 엔드포인트에 대한 성공한 테스트는 공용 IPv6 이그레스를 증명하지 않고, DNS 동작을 증명하지 않으며, 터널에서 제외한 애플리케이션을 다루지 않습니다. 각각은 저마다의 목적지와 관찰이 필요합니다. 호스트 하나에 요청 하나를 보낸 뒤 IPv6가 작동한다는 메모는 발견이 아니라 타임스탬프가 붙은 추측입니다.

남길 가치가 있는 기록은 짧습니다: 목적지, 이름, 호스트가 선택한 원본 주소, 관찰된 원격 주소, 시간입니다. RFC 7359는 관련 IPv6 경로가 실제로 사용 가능한지 테스트하는 방법을 다루며, 이 절차가 더 단순한 도구로 접근하려는 표준입니다. 결론이 참이 되려면 공용 검사기가 필요하다면, 테스트는 충분히 구체적이지 않았습니다.