Azure Virtual WAN의 Private Link 및 DNS에 대한 가이드

Azure Private Link

Azure DNS

Azure Firewall

Azure 가상 WAN

Azure Private Link를 사용하면 클라이언트가 공용 IP 주소 지정을 사용하지 않고 프라이빗 가상 네트워크에서 직접 Azure PaaS(Platform as a Service) 서비스에 액세스할 수 있습니다. 각 서비스에 대해 네트워크의 개인 IP 주소를 사용하는 프라이빗 엔드포인트를 구성합니다. 그런 다음 클라이언트는 프라이빗 엔드포인트를 사용하여 서비스에 비공개로 연결할 수 있습니다.

클라이언트는 서비스의 FQDN(정규화된 do기본 이름)을 계속 사용하여 연결합니다. 서비스의 FQDN을 프라이빗 엔드포인트의 개인 IP 주소로 확인하도록 네트워크에서 DNS를 구성합니다.

네트워크 디자인, 특히 DNS 구성은 서비스에 대한 프라이빗 엔드포인트 연결을 지원하는 핵심 요소입니다. 이 문서는 다양한 Private Link 시나리오 구현에 대한 지침을 제공하는 일련의 문서 중 하나입니다. 상황과 정확히 일치하는 시나리오가 없더라도 필요에 맞게 디자인을 조정할 수 있어야 합니다.

네트워크 토폴로지 시작

시작 네트워크 토폴로지는 이 문서 시리즈의 모든 시나리오에 대한 시작점으로 사용되는 네트워크 아키텍처입니다. 아키텍처는 Azure Virtual WAN을 사용하는 일반적인 허브-스포크 네트워크입니다.

그림 1: 모든 프라이빗 엔드포인트 및 DNS 시나리오에 대한 네트워크 토폴로지 시작

이 아키텍처의 Visio 파일을 다운로드합니다. 이 토폴로지의 특징은 다음과 같습니다.

Azure Virtual WAN으로 구현되는 허브-스포크 네트워크입니다.
각각 지역별 Azure Firewall 보안 가상 허브가 있는 두 지역이 있습니다.
각 보안 지역 가상 허브에는 Azure Virtual Network 연결에 대한 다음과 같은 보안 설정이 있습니다.
- 인터넷 트래픽: Azure Firewall 로 보호 - 인터넷으로 나가는 모든 트래픽은 지역 허브 방화벽을 통해 흐릅니다.
- 프라이빗 트래픽: Azure Firewall 로 보호 - 스포크에서 스포크로 전송되는 모든 트래픽은 지역 허브 방화벽을 통해 전달됩니다.
각 지역 가상 허브는 Azure Firewall로 보호됩니다. 지역 허브 방화벽에는 다음과 같은 설정이 있습니다.
- DNS 서버: 기본값(Azure 제공) - 지역 허브 방화벽은 규칙 컬렉션에서 FQDN 확인을 위해 Azure DNS를 명시적으로 사용합니다.
- DNS 프록시: 사용 - 지역 허브 방화벽이 포트 53의 DNS 쿼리에 응답합니다. 캐시되지 않은 값에 대한 쿼리를 Azure DNS에 전달합니다.
- 방화벽은 동일한 지역에 있는 Log Analytics 작업 영역에 규칙 평가 및 DNS 프록시 요청을 기록합니다. 이러한 이벤트의 로깅은 일반적인 네트워크 보안 로깅 요구 사항입니다.
연결된 각 가상 네트워크 스포크에는 지역 허브 방화벽의 개인 IP 주소로 구성된 기본 DNS 서버가 있습니다. 그렇지 않으면 FQDN 규칙 평가가 동기화되지 않을 수 있습니다.

다중 지역 라우팅

보안 가상 WAN 허브는 여러 개의 보안 가상 허브가 있는 경우 허브 간 연결을 제한적으로 지원합니다. 이 제한은 다중 허브, 지역 내 및 지역 간 시나리오에 영향을 줍니다. 따라서 네트워크 토폴로지는 Azure Firewall을 통해 프라이빗 지역 간 트래픽을 직접 필터링하는 데 도움이 되지 않습니다. 이 기능에 대한 지원은 Virtual WAN 허브 라우팅 의도 및 라우팅 정책을 사용하여 제공됩니다. 이 기능은 현재 미리 보기로 제공되고 있습니다.

이 일련의 문서에서는 내부 보안 트래픽이 여러 허브를 트래버스하지 않는다고 가정합니다. 여러 허브를 트래버스해야 하는 트래픽은 보안 가상 허브를 통해 프라이빗 트래픽을 필터링하지 않고 대신 통과하게 하는 병렬 토폴로지에서 수행해야 합니다.

스포크 네트워크 추가

스포크 네트워크를 추가할 때 시작 네트워크 토폴로지에서 정의된 제약 조건을 따릅니다. 특히 각 스포크 네트워크는 지역 허브에 있는 기본 경로 테이블과 연결되며 방화벽은 인터넷 및 개인 트래픽을 모두 보호하도록 구성됩니다. 다음 스크린샷은 구성 예제를 보여줍니다.

그림 2: 가상 허브의 가상 네트워크 연결에 대한 보안 구성

주요 과제

시작 네트워크 토폴로지에서는 프라이빗 엔드포인트에 대한 DNS를 구성하는 데 문제가 발생합니다.

Virtual WAN을 사용하면 관리형 허브 환경을 제공할 수 있지만, 가상 허브의 구성 또는 더 많은 구성 요소를 추가할 수 있는 기능에 영향을 주는 기능이 제한적이라는 단점이 있습니다. 기존의 허브-스포크 토폴로지에서는 자체 관리형 허브에서 DNS 레코드와 같은 일반적인 네트워크 서비스를 공유하면서 스포크에서 워크로드를 격리할 수 있습니다. Azure DNS가 클라이언트에 대한 프라이빗 엔드포인트 IP 주소를 확인할 수 있도록 일반적으로 프라이빗 DNS 영역을 허브 네트워크에 연결합니다.

그러나 프라이빗 DNS 영역을 Virtual WAN 허브에 연결할 수 없으므로 허브 내에서 발생하는 DNS 확인은 프라이빗 영역을 인식하지 못합니다. 특히 이 문제는 워크로드 스포크용으로 구성된 DNS 공급자인 Azure Firewall에서 FQDN 확인을 위해 DNS를 사용하는 문제입니다.

Virtual WAN 허브를 사용하는 경우 워크로드에서 DNS 확인을 기대하는 스포크 가상 네트워크에 프라이빗 DNS 영역을 연결하는 것이 직관적으로 보입니다. 그러나 아키텍처에서 설명한 대로 DNS 프록시는 지역 방화벽에서 사용하도록 설정되며 모든 스포크는 해당 지역 방화벽을 DNS 원본으로 사용할 것으로 예상됩니다. Azure DNS는 워크로드 네트워크 대신 방화벽에서 호출되므로 워크로드 네트워크의 프라이빗 DNS 영역 링크는 해결에 사용되지 않습니다.

참고 항목

지역 방화벽을 스포크의 dns 공급자로 구성하려면 스포크 가상 네트워크의 사용자 지정 DNS 서버를 일반적인 Azure DNS 값 대신 방화벽의 개인 IP를 가리키도록 설정합니다.

지역 방화벽에서 DNS 프록시를 사용하도록 설정하여 발생하는 복잡성을 고려하여 사용하도록 설정하는 이유를 검토해 보겠습니다.

Azure Firewall 네트워크 규칙은 애플리케이션 규칙이 처리하지 않는 송신 트래픽을 보다 정확하게 제어하기 위해 FQDN 기반 제한을 지원합니다. 이 기능을 사용하려면 DNS 프록시를 사용하도록 설정해야 합니다. 일반적인 용도는 NTP(네트워크 시간 프로토콜) 트래픽을 알려진 엔드포인트(예: )로 time.windows.com제한하는 것입니다.
보안 팀은 DNS 요청 로깅을 활용할 수 있습니다. Azure Firewall은 DNS 요청 로깅을 기본적으로 지원하므로 모든 스포크 리소스가 AZURE Firewall을 DNS 공급자로 사용하도록 요구하면 광범위한 로깅 적용 범위가 보장됩니다.

문제를 설명하기 위해 다음 섹션에서는 두 가지 구성에 대해 설명합니다. 작동하는 간단한 예제와 그렇지 않은 더 복잡한 예제가 있지만 실패는 유익합니다.

작업 시나리오

다음 예제는 기본 프라이빗 엔드포인트 구성입니다. 가상 네트워크에는 프라이빗 엔드포인트를 통해 PAAS 서비스를 사용해야 하는 클라이언트가 포함되어 있습니다. 가상 네트워크에 연결된 프라이빗 DNS 영역에는 서비스의 FQDN을 프라이빗 엔드포인트의 개인 IP 주소로 확인하는 A 레코드가 있습니다. 다음 다이어그램에서는 흐름을 보여 줍니다.

그림 3: 프라이빗 엔드포인트에 대한 기본 DNS 구성

이 아키텍처의 Visio 파일을 다운로드합니다.

클라이언트가 stgworkload00.blob.core.windows.net 요청을 실행합니다.
가상 네트워크에 대해 구성된 DNS 서버인 Azure DNS는 stgworkload00.blob.core.windows.net IP 주소에 대해 쿼리됩니다.

VM(가상 머신)에서 다음 명령을 실행하면 VM이 Azure DNS(168.63.129.16)를 DNS 공급자로 사용하도록 구성되어 있음을 보여 줍니다.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
프라이빗 DNS 영역 privatelink.blob.core.windows.net 은 워크로드 VNet에 연결되므로 Azure DNS는 워크로드 VNet의 레코드를 응답에 통합합니다.
A 레코드는 FQDN stgworkload00.privatelink.blob.core.windows.net을 매핑하는 프라이빗 DNS 영역에 있으므로 프라이빗 엔드포인트의 개인 IP 주소 10.1.2.4가 반환됩니다.

VM에서 다음 명령을 실행하면 스토리지 계정의 FQDN이 프라이빗 엔드포인트의 개인 IP 주소로 확인됩니다.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
이 경우 10.1.2.4인 프라이빗 엔드포인트의 개인 IP 주소에 요청이 발급됩니다.
요청은 Private Link를 통해 스토리지 계정으로 라우팅됩니다.

Azure DNS로 인해 디자인이 작동합니다.

가상 네트워크에 대해 구성된 DNS 서버입니다.
연결된 프라이빗 DNS 영역을 인식합니다.
영역 값을 사용하여 DNS 쿼리를 확인합니다.

비작업 시나리오

다음 예제는 시작 네트워크 토폴로지에서 프라이빗 엔드포인트를 사용하려는 순진한 시도입니다. 프라이빗 DNS 영역을 Virtual WAN 허브에 연결할 수 없습니다. 따라서 클라이언트가 방화벽을 DNS 서버로 사용하도록 구성된 경우 DNS 요청은 연결된 프라이빗 DNS 영역이 없는 가상 허브 내에서 Azure DNS로 전달됩니다. Azure DNS는 공용 IP 주소인 기본값을 제공하는 것 외에는 쿼리를 확인하는 방법을 모릅니다.

그림 4: 시작 네트워크 토폴로지에서 프라이빗 엔드포인트를 사용하려는 순진한 시도

이 아키텍처의 Visio 파일을 다운로드합니다.

클라이언트가 stgworkload00.blob.core.windows.net 요청을 실행합니다.

VM에서 다음 명령을 실행하면 VM이 가상 허브 방화벽을 DNS 공급자로 사용하도록 구성되어 있음을 보여 줍니다.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
방화벽에는 요청을 Azure DNS로 전달하기 위한 기본 설정으로 DNS 프록시가 활성화되어 있습니다. 요청이 Azure DNS로 전달됩니다.
Azure DNS는 다음과 같은 이유로 프라이빗 엔드포인트의 개인 IP 주소로 확인할 stgworkload00.blob.core.windows.net 수 없습니다.
1. 프라이빗 DNS 영역은 Virtual WAN 허브에 연결할 수 없습니다.
2. 워크로드 가상 네트워크에 대해 구성된 DNS 서버가 Azure Firewall이므로 Azure DNS는 워크로드 가상 네트워크에 연결된 프라이빗 DNS 영역을 인식하지 못합니다. Azure DNS는 스토리지 계정의 공용 IP 주소로 응답합니다.
VM에서 다음 명령을 실행하면 스토리지 계정의 FQDN이 스토리지 계정의 공용 IP로 확인됩니다.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Azure Firewall은 DNS 쿼리를 프록시하므로 이를 기록할 수 있습니다. 다음은 샘플 Azure Firewall DNS 프록시 로그입니다.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
클라이언트는 Private Link 엔드포인트에 대한 개인 IP 주소를 받지 않으며 스토리지 계정에 대한 프라이빗 연결을 설정할 수 없습니다.

위의 동작이 필요합니다. 시나리오에서 해결하는 문제입니다.

시나리오

이 문제에 대한 해결 방법은 비슷하지만 일반적인 워크로드 시나리오를 탐색하면 솔루션이 다양한 상황의 요구 사항을 해결하는 방법을 보여 줍니다. 대부분의 시나리오는 프라이빗 엔드포인트를 통해 하나 이상의 PaaS 서비스에 액세스하는 클라이언트로 구성됩니다. 시작 네트워크 토폴로지는 준수하지만 워크로드 요구 사항은 다릅니다. 시나리오는 단일 지역 PaaS 서비스에 액세스하는 클라이언트를 사용하여 간단히 시작됩니다. 점점 더 복잡해지므로 네트워크 가시성, 지역 및 PaaS 서비스가 더 많이 추가됩니다.

대부분의 시나리오에서 클라이언트는 VM으로 구현되고 클라이언트가 액세스하는 PaaS 서비스는 스토리지 계정입니다. 가상 네트워크에 노출되는 NIC가 있는 Azure 리소스(예: Virtual Machine Scale Sets, Azure Kubernetes Service 노드 또는 비슷한 방식으로 라우팅되는 다른 서비스)에 대해 VM을 스탠드인으로 고려해야 합니다.

Important

Azure Storage 계정에 대한 Private Link 구현은 미묘한 방식으로 다른 PaaS 서비스와 다를 수 있지만 많은 경우에 적합합니다. 예를 들어 일부 서비스는 Private Link를 통해 노출되는 동안 FQDN 레코드를 제거하므로 동작이 다를 수 있지만 이러한 차이는 일반적으로 이러한 시나리오에 대한 솔루션의 요인이 아닙니다.

각 시나리오는 원하는 끝 상태로 시작하고 시작 네트워크 토폴로지에서 원하는 끝 상태로 가져오는 데 필요한 구성을 자세히 설명합니다. 모든 시나리오에 대한 솔루션은 가상 허브 확장 패턴을 활용합니다. 이 패턴은 지역 허브에 대한 개념적 확장으로 격리되고 안전한 방식으로 공유 서비스를 노출하는 방법을 설명합니다. 다음 표에는 가상 허브 확장 패턴 및 시나리오에 대한 링크가 포함되어 있습니다.

가이드	설명
단일 지역, 전용 PaaS	단일 지역의 워크로드는 하나의 전용 PaaS 리소스에 액세스합니다.

다음 단계

단일 지역, 전용 PaaS 리소스 시나리오 읽기

다음을 통해 공유

Azure Virtual WAN의 Private Link 및 DNS에 대한 가이드