IPv6만 있는 네트워크는 터널이 시작되기 전에 VPN을 깨뜨린다

노트북이 IPv6만 배포하는 회의장 Wi-Fi에 접속하고 VPN 클라이언트는 계속 돌다가 실패하지만, 같은 프로필은 한 시간 전 호텔에서는 동작했다. 자격 증명은 아무것도 바뀌지 않았다. 바뀐 것은 클라이언트가 이제 IPv6만 전달하는 네트워크를 통해 IPv4 목적지에 도달해야 한다는 점이며, 모든 클라이언트가 그 방법을 아는 것은 아니다.

패킷이 지나는 것과 같은 다섯 단계를 따라가 본다.

단계 1: 이름 조회를 지켜본다

프로필이 호스트 이름을 사용한다면 첫 질문은 리졸버가 무엇을 반환하는가이다. dig AAAA vpn.example.com은 IPv6만 있는 네트워크에서 실제 AAAA 레코드, DNS64가 합성한 레코드, 또는 아무것도 반환하지 않는다. 합성된 응답은 변환 프리픽스 안에 IPv4 목적지를 인코딩하며, 그때서야 IPv6 목적지가 없는 클라이언트가 도달할 수 있다. IPv4 주소를 하드코딩한 프로필은 합성할 이름이 없기 때문에 여기까지 오지 못한다.

그 한 가지 차이가 ‘저기서는 되고 여기서는 안 된다’는 보고의 대부분을 설명하며, 보려면 명령 하나면 충분한다.

단계 2: 클라이언트가 부른 주소 체계를 본다

진행 표시줄이 아니라 소켓을 본다. IPv6만 있는 링크에서 IPv4 주소로 IPv4 소켓을 여는 클라이언트는 보낼 곳이 없고, 실패는 이름 오류가 아니라 시간 초과로 나타난다. 클라이언트가 연결하는 동안 ss -tanp를 실행하면 원격 주소와 시도한 주소 체계가 보인다. 이를 ip -6 route와 비교해 기본 경로가 실제 IPv6 다음 홉인지 확인한다.

소켓 테이블의 주소 체계가 사실이다. 진행 표시줄은 다른 누군가가 쓴 요약이다.

단계 3: 변환과 터널을 분리한다

NAT64와 DNS64는 액세스 네트워크가 IPv4 목적지에 도달하는 방식이며, 터널이 올라온 뒤에는 터널을 위해 아무것도 하지 않는다. 변환된 경로 위에 세운 터널은 여전히 자체 내부 주소 지정을 협상하고, 내부 IPv4 또는 IPv6 커버리지는 별개의 정책 문제이다. 클라이언트가 연결된 뒤 아무것에도 도달하지 못한다면, 이미 변환을 지나 라우팅으로 들어온 것이며, 이는 다른 증거를 가진 다른 조사이다.

변환 실패는 아예 연결되지 않는 것처럼 보인다. 내부 커버리지 실패는 연결되지만 아무것에도 도달하지 못하는 것처럼 보인다.

단계 4: 같은 프로필을 다른 네트워크에서 시험한다

같은 프로필, 클라이언트 버전, 자격 증명을 이중 스택 네트워크로 가져가 반복한다. 거기서 동작하고 IPv6만 있는 경로에서 실패한다면 변수는 프로필이 아니라 액세스 네트워크이다. 최종 수정은 클라이언트 업데이트이거나 다른 목적지이므로, 티켓에 클라이언트 버전과 네트워크 상태를 기록한다.

VPN이 고장 났다는 보고는 조치할 수 없다. IPv6만 있는 액세스에서만 실패한다는 보고는 버그 보고이다.

단계 5: 보안 설정이 아니라 경로를 고친다

유혹적인 복구는 모두 상황을 더 나쁘게 만든다. IPv6를 끄면 네트워크가 제공하는 유일한 경로가 사라진다. 클라이언트를 공용 리졸버로 돌리면, 그 합성이 변환기 뒤의 리졸버에서 와야 하는 DNS64 합성이 깨진다. 인증서 검증을 끄면 식별할 수 없는 무언가와의 연결을 얻게 된다. 어느 것도 복구가 아니며, 그중 둘은 사고보다 오래 남을 보안 회귀이다.

실제 선택지는 네트워크 변환 모델을 지원하는 클라이언트이거나 도달 가능한 IPv6 주소를 가진 목적지이다. 둘 중 하나를 요구한다.