VMware의 IPv6 NAT를 사용해 보면 IPv4 only 호스트에 연결되지 않습니다 (from Windows 10 VM)
소개
VMware Fusion 8, Workstation 12, Player 12는 IPv6 NAT(NAPT) 기능을 제공합니다. NAT 부하의 VM에 ULA를 배포하고, 호스트 OS IPv6 주소를 1개만 가지고 있으면, 포트 변환까지 통신할 수 있다.
|
| 2001:db8::xxxx (GUA)
[VMware]
[ NAT ] ↓↓↓↓↓ホストOS内の仮想ネットワークの世界
|
| RA fd01:2::/64 (IPv6 ULA)
| DHCPv4 192.168.46.0/24 (IPv4プライベート)
---+-----------------------+---
|
[VM: Windows10]
NAT하에 Windows 10의 VM을 두고, RA로 ULA를 배포해 보니, IPv4 only의 사이트(예를 들면 github.com)에 연결되지 않게 되어 버렸다. ULA 배포를 그만두면 문제없이 연결된다.
애플리케이션 동작
FireFox와 Visual Studio 2015에 번들로 제공되는 git for Windows의 작동 예. 둘 다 이름 해석에 실패하고 동작이 멈춘다. 그러나 IPv4 인터넷에는 연결되어 있으며 DNS 서버는 A 쿼리에 대해 A 응답을 반환합니다.
이름 해석 API getaddrinfo() 의 움직임
테스트
호출의 전제로 github.com에 두 개의 A 레코드가 있다고 가정합니다.
github.com. IN A 192.30.253.112
github.com. IN A 192.30.253.113
IPv6 듀얼 스택, VMware DNS 프록시를 사용하고 다음 인수로 github.com의 이름 확인을 시도하면
int getaddrinfo(hints, ai0, nodename, servname)
IN hints
.ai_family = PF_UNSPEC;
.ai_socktype = SOCK_STREAM;
.ai_flags = 0;
OUT ai0
IN nodename = "github.com";
IN servname = "https";
호출 함수 반환값(결과)은
OS
IPv6 있음(듀얼 스택)
IPv6 없음(IPv4 only)
Windows 10 Pro
실패(EAI_FAIL)※1
성공※2
우분투 16.04 LTS
성공※3
성공※3
FreeBSD 11.0-RELEASE
성공※4
성공※4
분석 및 추측
케이스※1 (Windows 듀얼 스택)
getaddrinfo() 자신이 실패로 끝나기 때문에 IPv4 주소도 취할 수 없다. CNAME의 루프를 처리할 수 없게 되어 EAI_FAIL가 돌려주는 것이 아닐까 생각한다. EAI_FAIL의 텍스트 표현, gai_sterror() 의 출력은 "non-recoverable failure in name resolution"
케이스※2 (Windows IPv4 only)
Windows Vista 이후에서는, IPv4 only의 환경에서는 AAAA 쿼리의 생성하지 않기 때문에, AAAA 쿼리의 응답에 대한 대답을 해석하지 않는다. CNAME의 루프를 처리 할 필요가 없기 때문에 성공을 반환한다고 추측하고 있습니다.
케이스※3 (Linux glibc)
이름 해석은 성공하지만 동일한 주소가 2개 겹친 주소 리스트가 얻어진다.
|
| 2001:db8::xxxx (GUA)
[VMware]
[ NAT ] ↓↓↓↓↓ホストOS内の仮想ネットワークの世界
|
| RA fd01:2::/64 (IPv6 ULA)
| DHCPv4 192.168.46.0/24 (IPv4プライベート)
---+-----------------------+---
|
[VM: Windows10]
FireFox와 Visual Studio 2015에 번들로 제공되는 git for Windows의 작동 예. 둘 다 이름 해석에 실패하고 동작이 멈춘다. 그러나 IPv4 인터넷에는 연결되어 있으며 DNS 서버는 A 쿼리에 대해 A 응답을 반환합니다.
이름 해석 API getaddrinfo() 의 움직임
테스트
호출의 전제로 github.com에 두 개의 A 레코드가 있다고 가정합니다.
github.com. IN A 192.30.253.112
github.com. IN A 192.30.253.113
IPv6 듀얼 스택, VMware DNS 프록시를 사용하고 다음 인수로 github.com의 이름 확인을 시도하면
int getaddrinfo(hints, ai0, nodename, servname)
IN hints
.ai_family = PF_UNSPEC;
.ai_socktype = SOCK_STREAM;
.ai_flags = 0;
OUT ai0
IN nodename = "github.com";
IN servname = "https";
호출 함수 반환값(결과)은
OS
IPv6 있음(듀얼 스택)
IPv6 없음(IPv4 only)
Windows 10 Pro
실패(EAI_FAIL)※1
성공※2
우분투 16.04 LTS
성공※3
성공※3
FreeBSD 11.0-RELEASE
성공※4
성공※4
분석 및 추측
케이스※1 (Windows 듀얼 스택)
getaddrinfo() 자신이 실패로 끝나기 때문에 IPv4 주소도 취할 수 없다. CNAME의 루프를 처리할 수 없게 되어 EAI_FAIL가 돌려주는 것이 아닐까 생각한다. EAI_FAIL의 텍스트 표현, gai_sterror() 의 출력은 "non-recoverable failure in name resolution"
케이스※2 (Windows IPv4 only)
Windows Vista 이후에서는, IPv4 only의 환경에서는 AAAA 쿼리의 생성하지 않기 때문에, AAAA 쿼리의 응답에 대한 대답을 해석하지 않는다. CNAME의 루프를 처리 할 필요가 없기 때문에 성공을 반환한다고 추측하고 있습니다.
케이스※3 (Linux glibc)
이름 해석은 성공하지만 동일한 주소가 2개 겹친 주소 리스트가 얻어진다.
github.com. IN A 192.30.253.112
github.com. IN A 192.30.253.113
int getaddrinfo(hints, ai0, nodename, servname)
IN hints
.ai_family = PF_UNSPEC;
.ai_socktype = SOCK_STREAM;
.ai_flags = 0;
OUT ai0
IN nodename = "github.com";
IN servname = "https";
첫 번째는 AAAA 쿼리에 대해 얻은 A 응답에서 만든 요소, 후자의 두 개가 A 쿼리에 대해 얻은 A 응답에서 요소를 만들고 전체 목록을 만들고 있다고 추측합니다.
케이스※4 (FreeBSD libc)
이름 해석은 성공적으로 반환되는 주소 목록도
중복은 없다. 덧붙여서, syslog에는 gethostby*.getanswer: asked for "github.com IN AAAA", got type A 라고 출력된다.
원인
VMware의 DNS 프록시가 AAAA 쿼리를 제대로 처리할 수 없기 때문입니다. 동작의 상세를 이하의 노트의 정리하고 있다.
workaround
VMware NAT의 DNS 프록시를 사용하지 않습니다.
Reference
이 문제에 관하여(VMware의 IPv6 NAT를 사용해 보면 IPv4 only 호스트에 연결되지 않습니다 (from Windows 10 VM)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/ip6/items/af4677e9afe9661b521d
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
Reference
이 문제에 관하여(VMware의 IPv6 NAT를 사용해 보면 IPv4 only 호스트에 연결되지 않습니다 (from Windows 10 VM)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/ip6/items/af4677e9afe9661b521d텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)