resolver가 피어링된 VNet에 있으면 Azure P2S DNS가 실패한다

클라이언트는 자신의 가상 네트워크에 도달하면서도 피어링된 네트워크의 이름을 확인하지 못할 수 있다. 피어링은 양쪽이 승인하기 전까지 게이트웨이 전송이 아니다.

VM에 ping을 보내면 응답한다. 이름을 물으면 클라이언트는 호스트를 알 수 없다고 말한다. resolver가 VPN 게이트웨이가 있는 네트워크가 아니라 피어링된 가상 네트워크에 있을 때 이 두 결과는 예상된 것이며, resolver를 아무리 진단해도 바뀌지 않는다. 빠진 것은 피어링이 기본으로 보류하는 라우팅 계약이다. 두 구성은 종이 위에서 거의 같아 보이고, 동작과 고장의 차이는 올바른 방향으로 설정된 한 쌍의 피어링 스위치다.

노트북이 VNet2의 게이트웨이로 터널을 열고, DNS를 제공하는 도메인 컨트롤러가 VNet1에 앉아 있는 상황을 상상해 보자.

두 구성, 하나의 차이

resolver를 게이트웨이 자체의 가상 네트워크 안에 두면 터널이 올라오는 순간 이름이 확인된다. 그 조회에 피어링 설정은 전혀 관여하지 않는다.

같은 resolver를 피어링 건너편으로 옮기면 클라이언트는 여전히 VM에서 응답을 받지만 이름은 알 수 없는 상태로 남는다. 인증서와 터널과 클라이언트는 그대로다. 움직인 것은 resolver가 사는 위치뿐이다. 피어링이 준 것은 그 주소로 가는 경로이며, 게이트웨이가 그곳으로 트래픽을 나르는 권한은 아니다.

측면 A: 게이트웨이 소유자 쪽에서 게이트웨이 전송을 허용한다

피어링은 두 가상 네트워크를 잇지만, 그 연결은 게이트웨이를 통해 들어오는 트래픽에 대해 전이적이지 않으며, 지점 간 요청은 정확히 그렇게 들어온다. 따라서 VNet2의 게이트웨이는 설계가 허락할 때까지 조회를 VNet1로 넘길 자격이 없다. 허락은 게이트웨이가 있는 네트워크가 소유한 피어링의 스위치다.

VNet2에서 VNet1로 향하는 피어링에 Allow gateway transit을 설정한다. 이 속성은 게이트웨이 리소스가 아니라 피어링 개체에 속하므로 피어링 블레이드에서 읽고 바꾼다. 측면 A는 이것이 전부다.

측면 B: 피어 쪽에서 원격 게이트웨이를 사용한다

나머지 절반은 거울상이다. VNet1에서 VNet2로 돌아가는 피어링에 Use remote gateways를 켠다. 같은 플래그를 양쪽 끝에서, 또는 한쪽 끝에서만 켜면 절반만 지어진 경로와 원래 증상이 그대로 남는다. 전송을 허용하는 것은 VPN 게이트웨이가 있는 네트워크뿐이며, 그것을 쓰는 쪽은 피어다.

마지막으로 연 포털 블레이드를 믿는 대신 두 네트워크에서 두 속성을 모두 읽는다.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

두 설정을 나란히 보는 것이 뒤집힌 설정을 잡는 가장 빠른 방법이다. 게이트웨이 쪽에서 AllowGatewayTransit false를 보고하는 피어링은 패킷 캡처 없이 전체 실패를 설명한다.

클라이언트가 여전히 받아야 하는 것

라우팅은 필요하지만 충분하지 않다. 지점 간 프로필은 전송이 동작한 뒤 응답하는 DNS 주소도 클라이언트에 넘겨야 한다. 플랫폼 resolver는 그 주소가 아니다. 가상 네트워크에 연결된 Azure Private DNS 영역에는 응답하지만, 자체 디렉터리 서버에서 호스팅하는 영역에는 아무것도 돌려주지 않으며, 이 배포가 쓰는 것이 바로 그것이다. 클라이언트를 그쪽으로 향하게 하면 공용 이름은 즐겁게 확인되고 내부 호스트는 알 수 없는 채로 남는다.

다른 것을 바꾸기 전에 연결된 노트북에서 resolver에 질의한다.

nslookup dc01.corp.example 10.1.0.4

시간 초과는 경로가 아직 없다고 말한다. 권위 있는 응답은 문제를 클라이언트로 되돌린다. 대개는 결코 덧붙지 않는 접미사이며, 그래서 짧은 이름이 공용 resolver로 흘러가 즐겁게 실패한다.

사이트 간 쪽에서 같은 계약을 비교한다

이 중 어느 것도 노트북만의 이야기가 아니다. 클라이언트를 사이트 간 지사로 바꾸면 양측 요구가 돌아온다. 지사는 게이트웨이 네트워크로 곧장 들어오고, 두 네트워크 떨어진 서비스는 여전히 피어링 뒤에 있다.

전송은 양쪽 피어링에서 허용되어야 하며, 그것을 허용하는 스위치는 클라이언트 유형이 아니라 피어링에 있다.

게이트웨이를 탓하기 전에

Windows는 어댑터마다 resolver 목록을 유지하므로, 게이트웨이를 탓하기 전에 터널 인터페이스가 실제로 무엇을 받았는지 확인한다.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

부정 응답은 캐시에서 라우팅 수정보다 오래 살아남고, 오래된 접미사 목록은 영역을 한 번도 호스팅하지 않은 곳으로 질의를 계속 보낸다. 플러시하고 다시 물은 뒤 어느 서버가 응답하는지 적어 둔다.

경로가 유지되는지는 두 가지 작은 조건이 결정한다: 주소 공간이 겹치면 안 된다, 그리고 resolver의 서브넷에 있는 네트워크 보안 그룹이 클라이언트 풀을 허용해야 한다. 클라이언트 풀은 또 하나의 원본 범위일 뿐이다. VM 쪽에서 유효 경로를 확인하고 클라이언트에서 직접 한 번 질의하여 그것을 증명하면, 영역 문제나 접미사 문제나 필터가 전송 부재로 오인되지 않는다.

관련 글