IPv6 AAAA 레코드와 관련된 지연을 방지하는 방법은 무엇입니까?

Windows 서버는 AAAAWindows DNS 서버에 IPv6 레코드를 등록 하고 있습니다. 그러나 네트워크에서 IPv6 라우팅을 사용하도록 설정하지 않았기 때문에 종종 정지 동작이 발생합니다.

Microsoft RDP는 최악의 범죄자입니다. AAAADNS에 레코드 가있는 서버에 연결 하면 원격 데스크톱 클라이언트는 먼저 IPv6을 시도하고 연결 시간이 초과 될 때까지 IPv4로 대체되지 않습니다. 고급 사용자는 IP 주소에 직접 연결하여이 문제를 해결할 수 있습니다. IPv4 주소를 확인하면 ping -4 hostname.foo항상 즉시 작동합니다.

이 지연을 피하려면 어떻게해야합니까?

• 클라이언트에서 IPv6을 비활성화 하시겠습니까?
  • Microsoft는 IPv6이 Windows 운영 체제의 필수 부분 이라고 말합니다 .
  • 클라이언트가 너무 많아서 어디에서나 일관성있게 설정할 수 있습니다.
  • 나중에 IPv6을 구현할 때 더 많은 문제가 발생합니다.
• 서버에서 IPv6을 비활성화 하시겠습니까?
  • Microsoft는 IPv6이 Windows 운영 체제의 필수 부분 이라고 말합니다 .
  • 전체 IPv6 스택을 비활성화하려면 불편한 레지스트리 해킹 이 필요합니다 .
  • 이것이 모든 서버에 올바르게 설정되어 있는지 확인하는 것은 불편합니다.
  • 나중에 IPv6을 구현할 때 더 많은 문제가 발생합니다.
• 사용자 팩스 ​​DNS 되풀이에 IPv6 레코드를 마스크 하시겠습니까?
  • 아니요, 우리는 NLNet Unbound를 사용하고 있으며 이를 지원하지 않습니다 .
• Microsoft DNS 서버에 IPv6 AAAA 레코드를 등록하지 못합니까?
  • 나는 그것이 가능하다고 생각하지 않습니다.

이 시점에서 DNS 영역에서 모든 AAAA 레코드를 제거하는 스크립트 작성을 고려하고 있습니다. 더 나은 길을 찾도록 도와주세요.

업데이트 : DNS 확인은 문제 가 되지 않습니다 . @joeqwerty가 그의 답변에서 지적한 것처럼 DNS 레코드는 즉시 반환됩니다. 모두 A와 AAAA기록을 즉시 사용할 수 있습니다. 문제는 일부 클라이언트 ( mstsc.exe)가 우선적으로 IPv6을 통한 연결을 시도하고 IPv4로 대체되는 데 시간이 걸린다는 것입니다.

이것은 라우팅 문제처럼 보입니다. ping목적지 주소가 unroutable 때문에 명령은 "일반 실패"오류 메시지를 생성합니다.

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

이 동작의 패킷 캡처를 얻을 수 없습니다. 이 (실패한) ping 명령을 실행해도 Microsoft 네트워크 모니터에서 패킷이 생성되지 않습니다. 마찬가지로, 레코드가 mstsc.exe있는 호스트와 연결을 시도하면 AAAAIPv4로 폴백 할 때까지 트래픽이 생성되지 않습니다.

업데이트 : 우리 호스트는 모두 공개적으로 라우팅 가능한 IPv4 주소를 사용하고 있습니다. 이 문제는 6to4 구성이 손상되었을 수 있습니다. 6to4는 공용 IP 주소와 RFC1918 주소가있는 호스트에서 다르게 작동합니다.

업데이트 : 내 네트워크에는 6to4와 분명히 비린내가 있습니다. Windows 클라이언트에서 6to4를 비활성화하면 연결이 즉시 해결됩니다.

netsh int ipv6 6to4 set state disabled

그러나 @joeqwerty가 말했듯이 이것은 문제를 가릴뿐입니다. 여전히 네트워크에서 IPv6 통신이 작동하지 않는 이유를 찾으려고 노력하고 있습니다.

이 질문은 매우 흥미롭고 나는이 행동을 본 적이 없다는 것을 인정해야합니다. 더 잘 이해하고 이해하기 위해 다른 W2K8R2 서버에서 내 W2K8R2 RDS 서버 중 하나를 쿼리하는 nslookup 스 니펫을 가져 와서 동일한 테스트 서버에서 동일한 RDS 서버로 RDP 세션 스 니펫을 캡처했습니다. . Nslookup은 IPv6 레코드를 반환하는 데 지연이 없었으며 nslookup은 IPv6 레코드를 쿼리하기 전에 테스트 서버가 IPv4 레코드를 쿼리하는 것으로 나타났습니다. 캡처의 시간 델타는 어느 쿼리에서나 감지 가능한 지연이 없음을 보여줍니다.

편집하다

지금 당신은 무언가에 있습니다.

Microsoft 6To4 어댑터의 트래픽을 캡처하고 있는지 확인하십시오. 그렇지 않으면 IPv6이 표시되지 않습니다.

내 RDS 서버의 nslookup 결과는 다음과 같습니다. IPv6 주소를 기록해 두십시오.

다음은 캡처 한 내용입니다.

마지막으로 netstat의 스 니펫은 연결을 보여줍니다.

따라서 확인한 바와 같이 DNS 확인은 문제가되지 않습니다. 문제는 RDP 연결이 IPv4보다 IPv6을 선호한다는 것입니다 (Windows의 경우 기본값-Windows는 IPv4보다 IPv6을 선호 함). IPv4. IPv6보다 IPv4를 선호하도록 클라이언트를 구성하여이 문제를 해결할 수 있지만 문제를 숨기는 것일뿐입니다. 더 나은 해결책은 IPv6이 작동하지 않는 이유를 파악하고 해결하는 것입니다. IPv6에 대해 충분히 알지 못하지만 DNS로 반환되는 IPv6 레코드는 RDS 호스트가 존재하는 서브넷에서만 유효한 "로컬"주소이며 클라이언트가 다른 서브넷에 있으므로 해당 IPv6 주소에 도달하지 마십시오.

6to4라는 IPv6 전환 기술은 이와 같은 문제를 일으키는 것으로 유명 합니다. 직장에는 여러 가지 요소가 있습니다. 개별적으로 무해하지만 최종 사용자는 연결 지연을 경험할 수 있습니다.

완화에 대한 가능한 요소 및 생각 목록이 아래에 나와 있습니다.

Windows는 기본적으로 6to4를 활성화합니다

호스트에서 최신 버전의 Windows (Vista 이상)를 실행중인 경우 공개적으로 라우팅 가능한 IPv4 주소를 사용할 수있는 경우 Windows는 6to4 터널링을 기회 적으로 활성화합니다. 비판적으로 이것은 서버와 클라이언트 모두에 적용됩니다.

시스템이 6to4를 사용하고 있는지 확인하려면 ipconfig6to4 접두어로 시작하는 IPv6 주소를 실행 하십시오 2002:. 이런 식으로 보일 것입니다.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• 끝 점이 Active Directory에 연결된 경우 그룹 정책을 사용하여 6to4 및 Teredo와 같은 전환 프로토콜을 비활성화 할 수 있습니다. 이것은 KB929852에 잘 설명되어 있습니다 . (이를 클라이언트 나 서버에 적용하는 것으로 충분하지만이 단계를 수행하는 경우 클라이언트 와 서버 모두에서이를 비활성화하는 것이 좋습니다.)
• 소수의 호스트 만 관리하는 경우 사례별로 6to4를 비활성화 할 수 있습니다. 이것은 IPv6을 완전히 비활성화하는 것보다 훨씬 낫습니다.netsh int ipv6 6to4 set state disabled
• 다른 클라이언트 운영 체제를 사용하십시오. 예를 들어, Mac OS X에는 기본적으로 6to4가 활성화되어 있지 않습니다.

공개적으로 라우팅 가능한 IPv4 주소가 사용 중입니다

6to4는 공개적으로 라우팅 가능한 IPv4 주소가있는 호스트에서만 작동하므로이 문제는 NAT 방화벽 뒤의 호스트에 영향을 미치지 않습니다.

• 클라이언트 및 / 또는 서버를 NAT 방화벽 뒤로 이동하고 RFC1918 주소 지정을 사용할 수 있습니다. 그러나 경우에 따라 공개적으로 라우팅 가능한 주소가 실제로 선호됩니다. 전체 네트워크의 주소 지정을 변경하는 것도 비현실적인 선택 일 수 있습니다.

네트워크에서 6to4가 올바르게 작동하지 않습니다

애니 캐스트 모드에서 6to4 문제를 해결하는 것은 매우 어렵습니다. IETF에 공식적인 요청이있어 6to4를 역사적으로 재 분류해야한다는 것은 매우 귀찮은 일입니다 . 이 저자의 의견으로는 6to4는 더 이상 사용되지 않습니다.

간단히 말해 6to4는 6in4 (IP 프로토콜 = 41)라는 프로토콜을 사용하여 IPv6 패킷을 IPv4 패킷으로 캡슐화하여 작동합니다. IPv4 패킷은 192.88.99.1인터넷 어딘가에 작동하는 6to4 릴레이에 도착하기를 희망하는 애니 캐스트 주소로 주소가 지정됩니다 . 운이 좋으면 지리적으로 가까운 곳일 수도 있습니다.

실제로 일부 6to4 릴레이가 잘못 설정되어 있고 많은 네트워크에서 6in4 트래픽이 방화벽을 통과하도록 허용하지 않습니다. 일반적으로 방화벽은 모든 아웃 바운드 트래픽을 허용하지만 IP 프로토콜 41 패킷이 방화벽을 통해 반환되도록 명시 적으로 허용하지 않는 경우에 발생합니다. 이 문제 ( "인바운드 블랙홀") 및 기타 여러 가지 사항은 RFC 6343에 설명되어 있습니다.

• 네트워크 내부의 호스트에서 전송 될 때 IP 프로토콜 41 (TCP 재설정)을 크게 거부하도록 방화벽을 설정하십시오. 이로 인해 결정적이지 않은 연결 지연보다 더 "실패한"동작이 발생합니다. 이것은 제한된 테스트 환경에서 작동하는 것으로 입증 되었습니다 .
• 6to4 릴레이를 작동 시키려면 ISP 또는 첫 번째 홉 대중 교통 제공자에게 문의하십시오. 이 작업을 올바르게 수행하면 최종 사용자에게 최고의 경험이 될 것입니다. 공개적으로 라우팅 가능한 IPv4 주소를 가진 모든 최종 사용자는 IPv6 인터넷에 참여할 수 있습니다.

동적 DNS 등록

일반적인 Active Directory 환경에서 모든 컴퓨터는 DNS 서버에 자체 주소를 등록 할 수 있습니다. 호스트가 멀티 홈 인 경우 6to4 터널에서도 모든 주소를 등록합니다.

대부분의 인터넷 서비스는 동적 DNS를 사용하지 않으므로이 문제는 일반적으로 클라이언트와 서버가 모두 동일한 네트워크에 "내부"인 엔터프라이즈 사이트로 제한됩니다.

• 동적 DNS 업데이트를 비활성화하도록 선택할 수 있습니다. 그런 다음 AAAA 리소스 레코드를 영역 파일에 넣지 않으면 해당 서비스가 제공되지 않습니다. 그러나 내부 DNS 서버에는 종종 동적 DNS가 바람직합니다. 이렇게하면 이미있을 수있는 AAAA 레코드도 삭제해야합니다.
• AAAA 리소스 레코드에 대한 답변을 제공하지 않도록 DNS 서버를 설정하십시오. 그러나 IPv6 구현을 시작하려고 할 때 실제로 문제가 발생하므로이 작업을 수행하지 마십시오. (무료 / 오픈 소스 DNS 방화벽을 아는 사람이 있습니까?)

클라이언트 응용 프로그램이 정상적으로 실패하지 않습니다

Microsoft의 RDP 클라이언트는 IPv6 라우팅 문제를 정상적으로 처리하지 않는 클라이언트 응용 프로그램의 한 예입니다. 대부분의 웹 브라우저는 이와 같은 IPv6 엣지 케이스를 처리하는 것이 더 낫기 때문에 이러한 동작을 나타내지 않습니다.

• 다른 클라이언트를 사용해보십시오. 운이 좋을 수도 있습니다.

이 상황에서는 그다지 도움이되지는 않지만 유사한 딜레마에 직면 한 구현 자에게는 "Happy Eyeballs" (RFC 6555)라는 구현 기술이 있으며 ipv4와 ipv6에 동시에 연결하고 먼저 연결할 것을 선택하는 기술을 지정합니다.

여기 내 해결책이있었습니다. 기본적으로 Windows는 IPv6 경로에 IPv4 경로보다 우선 순위가 높습니다. IPv6 접두사 정책을 편집하면이 동작을 변경하여 IPv6보다 기본적으로 IPv4를 사용하도록 할 수 있습니다.

네트워크의 모든 시스템이 동일한 방식으로 설정되도록하기 위해 머신을 빌드하거나 리퍼브 한 후 소프트웨어 설치 중에 실행되는 .bat 스크립트에 다음 명령을 넣었습니다.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

이것이 무엇을하는지 설명하려면 :

처음 3 줄은 내장 터널링 인터페이스를 비활성화합니다. 대부분의 네트워크에 중복되어 있기 때문입니다. 컴퓨터에 자체 IPv6 주소를 제공하지 않으면이 세 줄을 사용하지 않을 수도 있습니다. 필자의 경우 터널링 연결을 위해 IPv6을 할당하는 DHCPv6 서버 및 관련 인프라가 있습니다.

두 번째 명령 블록은 기존의 모든 IPv6 라우팅 접두사 정책을 삭제합니다.

그런 다음 세 번째 블록은 IPv6 접두사 정책을 다시 작성하지만 다른 우선 순위 세트를 사용합니다. 따라서 IPv4에 해당하는 접두사에 IPv6보다 우선권이 주어지며 응용 프로그램에서 IPv6 사용을 지정하지 않는 한 머신은 IPv4를 사용하려고합니다.

이 솔루션은 기능적인 이중 스택 기능을 유지하지만 IPv4를 선호하는 것은 불완전하거나 신뢰할 수 없거나 성능이 좋지 않은 IPv6 사이트는 시스템의 프로그램에서 지시하지 않는 한이를 사용하지 않는 것을 의미합니다.

IPv4보다 운영 체제가 IPv6을 사용하게 만드는 것이 실제로 채택을 방해하고 있다고 생각합니다. 전환 기간 동안 호스트가 IPv6 연결을 가지고 있다고 생각하지만 실제로는 제대로 작동하지 않아 소프트웨어 오작동 및 큰 지연이 발생할 수 있습니다. 필자가 아는 많은 사람들은 처음에 완전한 연결을 설정하기 전에 끊어진 방식으로 IPv6을 배포하는 ISP의 해결책으로 라우터에서 IPv6을 완전히 비활성화했습니다.이 사람들은 라우터를 다시 구성 할 때까지 IPv6없이 다시 활성화하는 것을 잊어 버릴 것입니다.