깡민쓰~IT Story

Azure DNS Private Resolver는 VM 기반 DNS 서버를 배포하지 않고 온-프레미스 환경에서 Azure DNS 프라이빗 영역을 쿼리하거나 그 반대로 쿼리할 수 있는 새로운 서비스입니다.

Azure DNS Private Resolver에는 Azure Virtual Network가 필요합니다. 가상 네트워크 내에서 Azure DNS Private Resolver를 만들면 DNS 쿼리의 대상으로 사용할 수 있는 하나 이상의 인바운드 엔드포인트가 설정됩니다. 확인자의 아웃바운드 엔드포인트는 구성하는 DNS 전달 규칙 집합을 기반으로 하여 DNS 쿼리를 처리합니다. 규칙 집합에 연결된 네트워크에서 시작된 DNS 쿼리는 다른 DNS 서버에 보낼 수 있습니다.

Azure DNS Private Resolver를 사용하기 위해 VM(가상 머신)의 DNS 클라이언트 설정을 변경할 필요가 없습니다.

Azure DNS Private Resolver를 사용할 때의 DNS 쿼리 프로세스는 다음과 같이 요약됩니다.

1. 가상 네트워크의 클라이언트에서 DNS 쿼리를 실행합니다.
2. 이 가상 네트워크에 대한 DNS 서버가 사용자 지정되면 쿼리를 지정된 IP 주소로 전달합니다.
3. 기본(Azure 제공) DNS 서버가 가상 네트워크에 구성되어 있고 동일한 가상 네트워크에 연결된 프라이빗 DNS 영역이 있는 경우 이러한 영역을 참조합니다.
4. 쿼리가 가상 네트워크에 연결된 프라이빗 DNS 영역과 일치하지 않는 경우 DNS 전달 규칙 집합에 대한 가상 네트워크 링크를 참조합니다.
5. 규칙 집합 링크가 없는 경우 Azure DNS를 사용하여 쿼리를 확인합니다.
6. 규칙 집합 링크가 있는 경우 DNS 전달 규칙을 평가합니다.
7. 접미사가 일치하는 경우 쿼리를 지정된 주소로 전달합니다.
8. 여러 항목이 일치하는 경우 가장 긴 접미사를 사용합니다.
9. 일치하는 항목이 없는 경우 DNS 전달을 수행하지 않고 Azure DNS를 사용하여 쿼리를 확인합니다.

Azure DNS Private Resolver 아키텍처는 다음 그림에 요약되어 있습니다. Azure 가상 네트워크와 온-프레미스 네트워크 간의 DNS 확인에는 Azure ExpressRoute 또는 VPN이 필요합니다.

그림 1: Azure DNS Private Resolver 아키텍처

프라이빗 DNS 확인자를 만드는 방법에 대한 자세한 내용은 다음을 참조하세요.

• 빠른 시작: Azure Portal을 사용하여 Azure DNS Private Resolver 만들기
• 빠른 시작: Azure PowerShell을 사용하여 Azure DNS Private Resolver 만들기

Azure DNS Private Resolver에서 제공하는 이점은 다음과 같습니다.

• 완전 관리형: 기본 제공 고가용성, 영역 중복성
• 비용 절감: 운영 비용을 절감하고, 기존 IaaS 솔루션 가격의 일부로 실행합니다.
• 프라이빗 DNS 영역에 대한 프라이빗 액세스: 온-프레미스에서 조건부로 전달합니다.
• 확장성: 엔드포인트별 고성능
• DevOps 친숙한 기능: Terraform, ARM 또는 Bicep을 사용하여 파이프라인을 빌드합니다.

지역별 Azure 제품 - Azure DNS를 참조하세요.

Azure DNS Private Resolver는 확인자를 배포한 지역에서 고객 데이터를 이동하거나 저장하지 않습니다.

이 문서에서는 해결 프로그램 엔드포인트 및 규칙 집합에 대한 요약을 제공합니다. 엔드포인트 및 규칙 집합에 대한 자세한 내용은 Azure DNS Private Resolver 엔드포인트 및 규칙 집합을 참조하세요.

인바운드 엔드포인트를 사용하면 프라이빗 가상 네트워크 주소 공간의 일부인 IP 주소를 통해 온-프레미스 또는 다른 프라이빗 위치에서 이름을 확인할 수 있습니다. 온-프레미스에서 Azure 프라이빗 DNS 영역을 확인하려면 인바운드 엔드포인트의 IP 주소를 온-프레미스 DNS 조건부 전달자에 입력합니다. 온-프레미스 DNS 조건부 전달자는 가상 네트워크에 대한 네트워크 연결이 있어야 합니다.

인바운드 엔드포인트에는 프로비저닝된 VNet의 서브넷이 필요합니다. 서브넷은 Microsoft.Network/dnsResolvers에만 위임할 수 있으며 다른 서비스에는 사용할 수 없습니다. 인바운드 엔드포인트에서 받은 DNS 쿼리는 Azure로 들어갑니다. 자동 등록 또는 Private Link 사용 서비스를 사용하는 VM을 포함하여 프라이빗 DNS 영역이 있는 시나리오에서 이름을 확인할 수 있습니다.

아웃바운드 엔드포인트를 사용하면 이름 확인을 조건부로 Azure에서 온-프레미스, 다른 클라우드 공급자 또는 외부 DNS 서버로 전달할 수 있습니다. 이 엔드포인트에는 해당 서브넷에서 실행되는 다른 서비스가 없고 Microsoft.Network/dnsResolvers에만 위임할 수 있는 프로비전된 VNet의 전용 서브넷이 필요합니다. 아웃바운드 엔드포인트에 보낸 DNS 쿼리는 Azure에서 나갑니다.

가상 네트워크 링크는 DNS 전달 규칙 집합을 사용하여 아웃바운드 엔드포인트에 연결된 가상 네트워크에 대한 이름 확인을 사용하도록 설정합니다. 1:1 관계입니다.

DNS 전달 규칙 집합은 하나 이상의 아웃바운드 엔드포인트에 적용하거나 하나 이상의 가상 네트워크에 연결할 수 있는 DNS 전달 규칙(최대 1000개) 그룹입니다. 1:N 관계입니다. 규칙 집합은 특정 아웃바운드 엔드포인트와 연결됩니다. 자세한 내용은 DNS 전달 규칙 집합을 참조하세요.

DNS 전달 규칙에는 조건부 전달에 사용할 하나 이상의 대상 DNS 서버가 포함되며 다음으로 표시됩니다.

• 도메인 이름
• 대상 IP 주소
• 대상 포트 및 프로토콜(UDP 또는 TCP)

현재 Azure DNS Private Resolver에 적용되는 제한은 다음과 같습니다.

DNS 프라이빗 확인자1

1 포털이 업데이트될 때까지 Azure Portal에서 다른 한도가 적용될 수 있습니다. PowerShell을 사용하여 가장 최근 한도까지 요소를 프로비전합니다.

가상 네트워크와 관련된 제한 사항은 다음과 같습니다.

• 암호화가 사용하도록 설정된 VNet은 Azure DNS Private Resolver를 지원하지 않습니다.
• DNS 확인자는 DNS 확인자와 동일한 지역의 가상 네트워크만 참조할 수 있습니다.
• 가상 네트워크는 여러 DNS 확인자 간에 공유할 수 없습니다. 단일 가상 네트워크는 단일 DNS 확인자에서만 참조할 수 있습니다.

DNS 확인자에 사용되는 서브넷에 대한 제한 사항은 다음과 같습니다.

• 서브넷은 최소 /28 주소 공간 또는 최대 /24 주소 공간이어야 합니다. /28 서브넷은 현재 엔드포인트 한도를 수용하기에 충분합니다. /27에서 /24까지의 서브넷 크기는 이러한 한도가 변경되는 경우 유연성을 제공할 수 있습니다.
• 서브넷은 여러 DNS 확인자 엔드포인트 간에 공유할 수 없습니다. 단일 서브넷은 단일 DNS 확인자 엔드포인트에서만 사용할 수 있습니다.
• DNS 확인자 인바운드 엔드포인트에 대한 모든 IP 구성은 동일한 서브넷을 참조해야 합니다. 단일 DNS 확인자 인바운드 엔드포인트에 대한 IP 구성은 여러 서브넷을 포함할 수 없습니다.
• DNS 확인자 인바운드 엔드포인트에 사용되는 서브넷은 부모 DNS 확인자에서 참조하는 가상 네트워크 내에 있어야 합니다.
• 서브넷은 Microsoft.Network/dnsResolvers에만 위임할 수 있으며 다른 서비스에는 사용할 수 없습니다.

아웃바운드 엔드포인트에 대한 제한 사항은 다음과 같습니다.

• DNS 전달 규칙 집합과 그 아래의 가상 네트워크 링크가 삭제되지 않으면 아웃바운드 엔드포인트를 삭제할 수 없습니다.

• 규칙 집합은 최대 1000개의 규칙을 가질 수 있습니다.
• 규칙 집합의 교차 테넌트 연결은 지원되지 않습니다.

• IPv6 사용 서브넷은 지원되지 않습니다.
• DNS Private Resolver는 Azure ExpressRoute FastPath를 지원하지 않습니다.
• DNS Private Resolver는 Azure Lighthouse와 호환되지 않습니다.
  • Azure Lighthouse가 사용 중인지 확인하려면 Azure Portal에서 서비스 공급자를 검색하고 서비스 공급자 제품을 선택합니다.

• Azure PowerShell 또는 Azure Portal을 사용하여 Azure DNS Private Resolver를 만드는 방법을 알아봅니다.
• Azure DNS Private Resolver를 사용하여 Azure 및 온-프레미스 도메인을 확인하는 방법을 이해합니다.
• Azure DNS Private Resolver 엔드포인트 및 규칙 집합에 대해 알아봅니다.
• 프라이빗 해결 프로그램을 사용하여 DNS 장애 조치(failover) 설정 방법 알아보기
• 프라이빗 해결 프로그램을 사용하여 하이브리드 DNS를 구성하는 방법을 알아봅니다.
• Azure의 몇 가지 다른 주요 네트워킹 기능을 알아봅니다.
• 학습 모듈: Azure DNS 소개

애플리케이션 보안 그룹을 사용하면 네트워크 보안을 애플리케이션 구조의 자연 확장으로 구성하여 가상 머신을 그룹화하고 해당 그룹에 따라 네트워크 보안 정책을 정의할 수 있습니다. 명시적 IP 주소를 수동으로 유지 관리하지 않고 대규모 보안 정책을 재사용할 수 있습니다. 플랫폼은 명시적 IP 주소 및 여러 규칙 집합의 복잡성을 처리하여 비즈니스 논리에 집중할 수 있도록 합니다. 애플리케이션 보안 그룹에 대해 보다 정확하게 이해하려면 다음 예제를 잘 살펴보세요.

이전 그림에서 NIC1 및 NIC2는 AsgWeb 애플리케이션 보안 그룹의 멤버입니다. NIC3는 AsgLogic 애플리케이션 보안 그룹의 멤버입니다. NIC4는 AsgDb 애플리케이션 보안 그룹의 멤버입니다. 이 예시에서는 각 네트워크 인터페이스(NIC)가 단 하나의 애플리케이션 보안 그룹의 멤버이지만, 네트워크 인터페이스는 Azure 제한 내에서 여러 애플리케이션 보안 그룹의 멤버가 될 수 있습니다. 어떤 네트워크 인터페이스에도 네트워크 보안 그룹이 연결되지 않았습니다. NSG1은 두 서브넷에 연결되었으며 다음 규칙을 포함하고 있습니다.

이 규칙은 인터넷에서 웹 서버로 가는 트래픽을 허용하기 위해 필요합니다. 인터넷의 인바운드 트래픽을 DenyAllInbound 기본 보안 규칙에서 거부하기 때문에 AsgLogic 또는 AsgDb 애플리케이션 보안 그룹에 대한 규칙을 추가하지 않아도 됩니다.

AllowVNetInBound 기본 보안 규칙은 동일한 가상 네트워크의 리소스 간 통신을 모두 허용하므로, 모든 리소스에서 들어오는 트래픽을 거부하려면 이 규칙이 필요합니다.

이 규칙은 AsgLogic 애플리케이션 보안 그룹에서 AsgDb 애플리케이션 보안 그룹으로 가는 트래픽을 허용합니다. 이 규칙의 우선 순위는 Deny-Database-All 규칙의 우선 순위보다 높습니다. 결과적으로 이 규칙이 Deny-Database-All 규칙보다 먼저 처리되므로 AsgLogic 애플리케이션 보안 그룹의 트래픽은 허용되는 반면, 그 외의 트래픽은 모두 차단됩니다.

애플리케이션 보안 그룹의 구성원인 네트워크 인터페이스는 원본 또는 대상으로 지정하는 규칙을 적용합니다. 이 규칙은 다른 네트워크 인터페이스에 영향을 주지 않습니다. 네트워크 인터페이스가 애플리케이션 보안 그룹의 멤버가 아닌 경우에는 네트워크 보안 그룹이 서브넷과 연결되어도 규칙이 네트워크 인터페이스에 적용되지 않습니다.

Application Security Group에는 다음과 같은 제약 사항이 있습니다.

• 한 구독에 허용되는 애플리케이션 보안 그룹의 개수 제한 및 애플리케이션 보안 그룹과 관련된 기타 제한이 있습니다. 자세한 내용은 Azure 제한을 참조하세요.
• 애플리케이션 보안 그룹에 할당된 모든 네트워크 인터페이스는 애플리케이션 보안 그룹에 할당된 첫 번째 네트워크 인터페이스가 있는 가상 네트워크와 동일한 가상 네트워크에 있어야 합니다. 예를 들어 AsgWeb라는 애플리케이션 보안 그룹에 할당된 첫 번째 네트워크 인터페이스가 VNet1이라는 가상 네트워크에 있는 경우 ASGWeb에 할당되는 모든 후속 네트워크 인터페이스는 VNet1에 있어야 합니다. 서로 다른 가상 네트워크의 네트워크 인터페이스를 동일한 애플리케이션 보안 그룹에 추가할 수 없습니다.
• 애플리케이션 보안 그룹을 보안 규칙의 원본 및 대상으로 지정하는 경우, 두 애플리케이션 보안 그룹의 네트워크 인터페이스는 동일한 가상 네트워크에 있어야 합니다.
  • 예를 들어 AsgLogic에 VNet1의 네트워크 인터페이스가 있었고 AsgDb에 VNet2의 네트워크 인터페이스가 있었던 경우입니다. 이 경우 AsgLogic을 원본으로, AsgDb를 규칙의 대상으로 할당하는 것은 불가능합니다. 원본 및 대상 애플리케이션 보안 그룹에 대한 모든 네트워크 인터페이스는 동일한 가상 네트워크에 있어야 합니다.

• 네트워크 보안 그룹 만들기에 대해 알아보세요.

Azure Private Link를 사용하면 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure PaaS Services(예: Azure Storage 및 SQL Database)와 Azure 호스팅 고객 소유/파트너 서비스에 액세스할 수 있습니다.

가상 네트워크와 서비스 사이의 트래픽은 Microsoft 백본 네트워크를 통해 이동합니다. 서비스를 공용 인터넷에 더 이상 노출할 필요가 없습니다. 가상 네트워크에 자체 프라이빗 링크 서비스를 만들어서 고객에게 제공할 수도 있습니다. Azure Private Link를 사용한 설치 및 소비는 Azure PaaS, 고객 소유 및 공유 파트너 서비스에서 일관적입니다.

Azure Private Link는 다음과 같은 이점이 있습니다.

• Azure 플랫폼의 프라이빗 액세스 서비스: 프라이빗 엔드포인트를 사용하여 가상 네트워크를 Azure에서 애플리케이션 구성 요소로 사용할 수 있는 모든 서비스에 연결합니다. 서비스 공급자는 자체 가상 네트워크에서 서비스를 렌더링할 수 있으며, 소비자는 로컬 가상 네트워크에서 이러한 서비스에 액세스할 수 있습니다. Private Link 플랫폼은 Azure 백본 네트워크를 통해 소비자와 서비스 간의 연결을 처리합니다.
• 온-프레미스 및 피어링된 네트워크: 프라이빗 엔드포인트를 사용하여 온-프레미스에서 ExpressRoute 개인 피어링, VPN 터널 및 피어링된 가상 네트워크를 통해 Azure에서 실행되는 서비스에 액세스할 수 있습니다. 서비스에 연결하기 위해 ExpressRoute Microsoft 피어링을 구성하거나 인터넷을 트래버스할 필요가 없습니다. Private Link는 워크로드를 Azure로 안전하게 마이그레이션하는 방법을 제공합니다.
• 데이터 유출 방지: 프라이빗 엔드포인트는 전체 서비스가 아닌 PaaS 리소스의 인스턴스에 매핑됩니다. 소비자는 특정 리소스에만 연결할 수 있습니다. 서비스의 다른 리소스에 대한 액세스는 차단됩니다. 이 메커니즘은 데이터 유출 위험을 방지합니다.
• Global Reach: 다른 지역에서 실행되는 서비스에 비공개로 연결합니다. 소비자의 가상 네트워크는 A 지역에 있으며, B 지역의 Private Link 뒤에 있는 서비스에 연결할 수 있습니다.
• 사용자 고유의 서비스로 확장: 동일한 환경과 기능을 사용하여 자체 서비스를 Azure의 소비자에게 비공개로 렌더링할 수 있습니다. 서비스를 표준 Azure Load Balancer 뒤에 배치하여 Private Link에 사용할 수 있습니다. 그러면 소비자는 자체 가상 네트워크에서 프라이빗 엔드포인트를 사용하여 서비스에 직접 연결할 수 있습니다. 승인 호출 흐름을 사용하여 연결 요청을 관리할 수 있습니다. Azure Private Link는 다른 Microsoft Entra 테넌트에 속하는 소비자 및 서비스에 대해 작동합니다.

Private Link를 지원하는 Azure 서비스에 대한 자세한 내용은 Azure Private Link 가용성을 참조하세요.

최신 알림은 Azure Private Link 업데이트 페이지를 확인하세요.

Azure Private Link는 Azure Monitor와 통합되었습니다. 이 조합을 통해 다음을 수행할 수 있습니다.

• 스토리지 계정에 로그를 보관합니다.
• 이벤트를 Event Hubs로 스트리밍합니다.
• Azure Monitor 로깅이 가능합니다.

Azure Monitor에서 다음 정보에 액세스할 수 있습니다.

• 프라이빗 엔드포인트:
  • 프라이빗 엔드포인트에서 처리한 데이터(수신/송신)
• Private Link 서비스:
  • Private Link 서비스에서 처리한 데이터(수신/송신)
  • NAT 포트 가용성

가격 책정에 대한 자세한 내용은 Azure Private Link 가격 책정을 참조하세요.

FAQ는 Azure Private Link FAQ를 참조하세요.

제한은 Azure Private Link 제한을 참조하세요.

SLA는 Azure Private Link에 대한 SLA를 참조하세요.

Azure 네트워크 보안 그룹을 사용하여 Azure 가상 네트워크의 Azure 리소스 간의 네트워크 트래픽을 필터링할 수 있습니다. 네트워크 보안 그룹에는 여러 종류의 Azure 리소스에서 오는 인바운드 트래픽 또는 이러한 리소스로 나가는 아웃바운드 네트워크 트래픽을 허용하거나 거부하는 보안 규칙이 포함됩니다. 규칙마다 원본 및 대상, 포트, 프로토콜을 지정할 수 있습니다.

이 문서에서는 네트워크 보안 그룹 규칙의 속성, 적용되는 기본 보안 규칙 및 강화된 보안 규칙을 만들기 위해 수정할 수 있는 규칙 속성을 설명합니다.

네트워크 보안 그룹은 Azure 구독 제한 내에서 필요한 개수 만큼 규칙을 포함합니다. 각 규칙은 다음 속성을 지정합니다.

보안 규칙은 5-튜플(원본, 원본 포트, 대상, 대상 포트, 프로토콜) 정보를 기반으로 평가 및 적용됩니다. 우선 순위와 방향이 같은 두 개의 보안 규칙을 만들 수 없습니다. 기존 연결에 대한 흐름 레코드가 만들어집니다. 통신은 흐름 레코드의 연결 상태에 따라 허용 또는 거부됩니다. 흐름 레코드는 네트워크 보안 그룹의 상태 저장을 허용합니다. 예를 들어 포트 80을 통해 모든 주소에 대한 아웃바운드 보안 규칙을 지정하는 경우 아웃바운드 트래픽에 대한 응답에 인바운드 보안 규칙을 지정하지 않아도 됩니다. 통신이 외부에서 시작된 경우 인바운드 보안 규칙을 지정하기만 하면 됩니다. 반대의 경우도 마찬가지입니다. 포트를 통해 인바운드 트래픽이 허용되는 경우 포트를 통해 트래픽에 응답하도록 아웃바운드 보안 규칙을 지정하지 않아도 됩니다.

연결을 허용한 보안 규칙을 제거해도 기존 연결이 중단되지 않을 수 있습니다. 네트워크 보안 그룹 규칙을 수정하면 새 연결에만 영향을 줍니다. 네트워크 보안 그룹에서 새 규칙을 만들거나 기존 규칙을 업데이트하는 경우 새 연결에만 적용됩니다. 기존 연결은 새 규칙으로 재평가되지 않습니다.

한 네트워크 보안 그룹에 만들 수 있는 보안 규칙 수에는 제한이 있습니다. 자세한 내용은 Azure 제한을 참조하세요.

Azure는 사용자가 만드는 각 네트워크 보안 그룹에 다음과 같은 기본 규칙을 만듭니다.

원본 및 대상 열에서 VirtualNetwork, AzureLoadBalancer 및 인터넷은 IP 주소가 아닌 서비스 태그입니다. 프로토콜 열에서 모두는 TCP, UDP 및 ICMP를 포함합니다. 규칙을 만들 때 TCP, UDP, ICMP 또는 모두를 지정할 수 있습니다. 소스 및 대상 열에서 0.0.0.0/0은 모든 주소를 나타냅니다. Azure Portal, Azure CLI 또는 PowerShell과 같은 클라이언트는 이 식에 * 또는 모두를 사용할 수 있습니다.

기본 규칙을 제거할 수 없지만 더 높은 우선 순위의 규칙을 만들어서 재정의할 수 있습니다.

보강된 보안 규칙은 가상 네트워크에 대한 보안 정의를 간소화하여 더 적은 규칙으로 크고 복잡한 네트워크 보안 정책을 정의할 수 있도록 합니다. 여러 포트, 여러 명시적 IP 주소 및 범위를 이해하기 쉬운 단일 보안 규칙으로 결합할 수 있습니다. 규칙의 원본, 대상 및 포트 필드에서 보강된 규칙을 사용합니다. 보안 규칙 정의를 간단히 유지 관리하려면 보강된 보안 규칙을 서비스 태그 또는 애플리케이션 보안 그룹과 결합합니다. 한 규칙에서 지정할 수 있는 주소, 범위 및 포트 수가 제한됩니다. 자세한 내용은 Azure 제한을 참조하세요.

서비스 태그는 지정된 Azure 서비스의 IP 주소 접두사 그룹을 나타냅니다. 네트워크 보안 규칙에 대한 빈번한 업데이트의 복잡성을 최소화하는 데 도움이 됩니다.

자세한 내용은 Azure 서비스 태그를 참조하세요. Storage 서비스 태그를 사용하여 네트워크 액세스를 제한하는 방법에 대한 예제는 PaaS 리소스에 대한 네트워크 액세스 제한을 참조하세요.

애플리케이션 보안 그룹을 사용하면 네트워크 보안을 애플리케이션 구조의 자연 확장으로 구성하여 가상 머신을 그룹화하고 해당 그룹에 따라 네트워크 보안 정책을 정의할 수 있습니다. 명시적 IP 주소를 수동으로 유지 관리하지 않고 대규모 보안 정책을 재사용할 수 있습니다. 자세한 내용은 애플리케이션 보안 그룹을 참조하세요.

• 호스트 노드의 가상 IP: DHCP, DNS, IMDS, 상태 모니터링과 같은 기본 인프라 서비스는 가상화된 호스트 IP 주소 168.63.129.16 및 169.254.169.254를 통해 제공됩니다. 이러한 IP 주소는 Microsoft에 속하며, 이 용도로 모든 지역에서 유일하게 사용되는 가상화된 IP 주소입니다. 기본적으로 이러한 서비스는 각 서비스에 특정한 서비스 태그로 대상이 지정되지 않는 한 구성된 네트워크 보안 그룹의 적용을 받지 않습니다. 이 기본 인프라 통신을 재정의하기 위해 네트워크 보안 그룹 규칙에서 AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM과 같은 서비스 태그를 사용하여 트래픽을 거부하는 보안 규칙을 만들 수 있습니다. 네트워크 트래픽 필터링을 진단하고 네트워크 라우팅을 진단하는 방법을 알아봅니다.
• 라이선싱(키 관리 서비스): 가상 머신에서 실행되는 Windows 이미지는 사용이 허가되어 있어야 합니다. 사용 허가를 위해 라이선스 요청이 이러한 쿼리를 처리하는 키 관리 서비스 호스트 서버로 전송됩니다. 요청은 1688 포트를 통해 아웃바운드로 수행됩니다. 기본 경로 0.0.0.0/0 구성을 사용한 배포에 대해 이 플랫폼 규칙은 사용하지 않도록 설정됩니다.
• 부하가 분산된 풀의 가상 머신: 적용되는 원본 포트와 주소 범위는 부하 분산 장치가 아닌 원래 컴퓨터에서 가져옵니다. 대상 포트와 주소 범위는 부하 분산 장치가 아닌 대상 컴퓨터에서 가져옵니다.
• Azure 서비스 인스턴스: HDInsight, 애플리케이션 서비스 환경 및 Virtual Machine Scale Sets와 같은 몇 가지 Azure 서비스의 인스턴스는 가상 네트워크 서브넷에 배포됩니다. 가상 네트워크에 배포할 수 있는 서비스의 전체 목록은 Azure 서비스에 대한 가상 네트워크를 참조하세요. 서브넷에 네트워크 보안 그룹을 적용하기 전에 각 서비스의 포트 요구 사항을 숙지합니다. 서비스에 필요한 포트를 거부하면 서비스가 제대로 작동하지 않습니다.
• 아웃바운드 전자 메일 보내기: 인증된 SMTP 릴레이 서비스(일반적으로 587 TCP 포트를 통해 연결되지만 종종 다른 방법도 사용)를 활용하여 Azure Virtual Machines에서 전자 메일을 보내는 것이 좋습니다. SMTP 릴레이 서비스는 타사 전자 메일 공급자에서 메시지를 거부할 가능성을 최소화하기 위해 보낸 사람 신뢰도를 특수화합니다. 이러한 SMTP 릴레이 서비스는 Exchange Online Protection 및 SendGrid를 포함하지만 여기에 제한되지 않습니다. SMTP 릴레이 서비스는 구독 유형에 관계 없이 Azure에서 제한되지 않고 사용할 수 있습니다.
  • 기업계약: 표준 기업계약 구독에 배포된 VM의 경우 TCP 포트 25의 아웃바운드 SMTP 연결이 차단되지 않습니다. 그러나 외부 도메인은 VM에서 들어오는 이메일을 수락한다는 보장이 없습니다. 외부 도메인에서 이메일을 거부하거나 필터링하는 경우 외부 도메인의 이메일 서비스 공급자에게 문의하여 문제를 해결해야 합니다. 이러한 문제는 Azure 지원에서 다루지 않습니다.이 차단에서 구독을 제외하고 VM이 중지되었다가 다시 시작되면 해당 구독의 모든 VM은 제외됩니다. 예외는 요청된 구독에만 적용되고 인터넷으로 직접 라우팅되는 VM 트래픽에만 적용됩니다.
  • Enterprise 개발/테스트 구독의 경우 기본적으로 포트 25가 차단됩니다. 이 차단을 제거하는 것이 가능합니다. 차단을 제거하도록 요청하려면 Azure Portal의 Azure Virtual Network 리소스에 대한 진단 및 해결 설정 페이지의 이메일을 보낼 수 없음(SMTP-포트 25) 섹션으로 이동하여 진단을 실행합니다. 그러면 정규화된 엔터프라이즈 개발/테스트 구독이 자동으로 제외됩니다.
  • 종량제: 모든 리소스에서 아웃바운드 포트 25 통신이 차단되었습니다. 요청이 승인되지 않았기 때문에 제한 제거를 요청할 수 없습니다. 가상 머신에서 이메일을 보내야 하는 경우 SMTP 릴레이 서비스를 사용해야 합니다.
  • MSDN, Azure Pass, Azure in Open, Education 및 평가판: 모든 리소스에서 아웃바운드 포트 25 통신이 차단되었습니다. 요청이 승인되지 않았기 때문에 제한 제거를 요청할 수 없습니다. 가상 머신에서 이메일을 보내야 하는 경우 SMTP 릴레이 서비스를 사용해야 합니다.
  • 클라우드 서비스 공급자: 모든 리소스에서 아웃바운드 포트 25 통신이 차단되었습니다. 요청이 승인되지 않았기 때문에 제한 제거를 요청할 수 없습니다. 가상 머신에서 이메일을 보내야 하는 경우 SMTP 릴레이 서비스를 사용해야 합니다.
• 2017년 11월 15일까지 Azure 구독을 만든 경우 SMTP 릴레이 서비스를 사용할 수 있을 뿐만 아니라 TCP 포트 25를 통해 직접 전자 메일을 보낼 수 있습니다. 2017년 11월 15일 이후에 구독을 만든 경우 포트 25를 통해 직접 전자 메일을 보낼 수 없습니다. 포트 25를 통한 아웃바운드 통신 동작은 다음과 같이 구독 형식에 따라 다릅니다.

• 가상 네트워크에 배포하고 네트워크 보안 그룹이 연결된 Azure 리소스에 대한 자세한 내용은 Azure 서비스용 가상 네트워크 통합을 참조하세요
• 네트워크 보안 그룹을 사용하여 트래픽을 평가하는 방법에 대한 자세한 내용은 네트워크 보안 그룹의 작동 방법을 참조하세요.
• 네트워크 보안 그룹을 만들어 본 경험이 전혀 없는 경우 빠른 자습서를 완료하여 직접 경험해 볼 수 있습니다.
• 네트워크 보안 그룹에 익숙하고 네트워크 보안 그룹을 관리해야 하는 경우 네트워크 보안 그룹 관리를 참조하세요.
• 통신에 문제가 있고 네트워크 보안 그룹 문제를 해결해야 하는 경우 가상 머신 네트워크 트래픽 필터 문제 진단을 참조하세요.
• 네트워크 보안 그룹 흐름 로그를 사용하여 연결된 네트워크 보안 그룹이 있는 리소스와 주고 받는 네트워크 트래픽을 분석하는 방법을 알아보세요.

서비스 태그는 지정된 Azure 서비스의 IP 주소 접두사 그룹을 나타냅니다. Microsoft는 서비스 태그에 포함되는 주소 접두사를 관리하고 주소가 변경되면 서비스 태그를 자동으로 업데이트하여 네트워크 보안 규칙을 자주 업데이트할 때 발생하는 복잡성을 최소화합니다.

서비스 태그를 사용하여 네트워크 보안 그룹, Azure Firewall 및 사용자 정의 경로에서 네트워크 액세스 제어를 정의할 수 있습니다. 보안 규칙 및 경로를 만들 때 특정 IP 주소 대신 서비스 태그를 사용합니다. 서비스 태그 이름(예: ApiManagement)을 보안 규칙의 적절한 원본 또는 대상 필드에 지정하면 해당 서비스에 대한 트래픽을 허용하거나 거부할 수 있습니다. 경로의 주소 접두사에 서비스 태그 이름을 지정하면 서비스 태그로 캡슐화된 접두사에 대한 트래픽을 원하는 다음 홉 유형으로 라우팅할 수 있습니다.

퍼블릭 엔드포인트가 있는 Azure 서비스에 액세스하면서, 서비스 태그를 사용하여 네트워크 격리를 수행하고 일반 인터넷에서 Azure 리소스를 보호할 수 있습니다. 인바운드/아웃바운드 네트워크 보안 그룹 규칙을 만들어 인터넷에서 들어오고 나가는 트래픽을 거부하고 AzureCloud 또는 특정 Azure 서비스의 다른 사용 가능한 서비스 태그에서 들어오고 나가는 트래픽을 허용합니다.

다음 표에는 네트워크 보안 그룹 규칙에서 사용할 수 있는 모든 서비스 태그가 나와 있습니다.

열은 태그가 다음에 해당하는지 여부를 나타냅니다.

• 인바운드 또는 아웃바운드 트래픽을 포함하는 규칙에 적합합니다.
• 지역 범위를 지원합니다.
• Azure Firewall 규칙에서 인바운드 또는 아웃바운드 트래픽에 대해서만 대상 규칙으로 사용할 수 있습니다.

기본적으로 서비스 태그는 전체 클라우드의 범위를 반영합니다. 일부 서비스 태그는 해당 IP 범위를 지정된 지역으로 제한하여 보다 자세히 제어할 수 있습니다. 예를 들어, 서비스 태그 Storage는 전체 클라우드의 Azure Storage를 나타내지만 Storage.WestUS는 범위를 WestUS 지역의 스토리지 IP 주소 범위로 좁힙니다. 다음 표에서는 각 서비스 태그가 이러한 지역 범위를 지원하는지 여부를 나타내며 각 태그에 대해 나열된 방향이 권장 사항입니다. 예를 들어 AzureCloud 태그를 사용하여 인바운드 트래픽을 허용할 수 있습니다. 대부분의 시나리오에서는 다른 Azure 고객이 사용하는 IP가 서비스 태그의 일부로 포함되어 있으므로 모든 Azure IP의 트래픽을 허용하지 않는 것이 좋습니다.

클래식 배포 모델(Azure Resource Manager 이전)에서는 이전 표에 나열된 태그 중 일부만 지원합니다. 클래식 배포 모델의 태그는 다음 표와 같이 철자가 다릅니다.

다음은 현재 UDR(사용자 정의 경로)에 사용하기 위해 지원되지 않는 태그 목록입니다.

• AzurePlatformDNS
• AzurePlatformIMDS
• AzurePlatformLKM
• VirtualNetwork
• AzureLoadBalancer
• 인터넷

온-프레미스 방화벽 구성의 일부로 포함할 현재 서비스 태그 및 범위 정보를 얻을 수 있습니다. 이 정보는 각 서비스 태그에 해당하는 IP 범위의 현재 지정 시간 목록입니다. 다음 섹션에 설명된 대로 프로그래밍 방식으로 또는 JSON 파일 다운로드를 통해 이 정보를 가져올 수 있습니다.

IP 주소 범위 세부 정보와 함께 서비스 태그의 현재 목록을 프로그래밍 방식으로 검색할 수 있습니다.

• REST (영문)
• Azure PowerShell
• Azure CLI

예를 들어 스토리지 서비스 태그에 대한 모든 접두사를 검색하려면 다음 PowerShell cmdlet을 사용합니다.

$serviceTags = Get-AzNetworkServiceTag -Location eastus2
$storage = $serviceTags.Values | Where-Object { $_.Name -eq "Storage" }
$storage.Properties.AddressPrefixes

현재 서비스 태그 목록이 포함된 JSON 파일을 IP 주소 범위 정보와 함께 다운로드할 수 있습니다. 이러한 목록은 매주 업데이트되고 게시됩니다. 각 클라우드의 위치는 다음과 같습니다.

• Azure 공용
• Azure 미국 정부
• 21Vianet에서 운영하는 Microsoft Azure
• Azure 독일

해당 파일의 IP 주소 범위는 CIDR 표기법으로 되어 있습니다.

다음 AzureCloud 태그에는 일반 스키마에 따라 서식이 지정된 지역 이름이 없습니다.

• AzureCloud.centralfrance(FranceCentral)
• AzureCloud.southfrance(FranceSouth)
• AzureCloud.germanywc(GermanyWestCentral)
• AzureCloud.germanyn(GermanyNorth)
• AzureCloud.norwaye(NorwayEast)
• AzureCloud.norwayw(NorwayWest)
• AzureCloud.switzerlandn(SwitzerlandNorth)
• AzureCloud.switzerlandw(SwitzerlandWest)
• AzureCloud.usstagee(EastUSSTG)
• AzureCloud.usstagec(SouthCentralUSSTG)
• AzureCloud.brazilse(BrazilSoutheast)

• 네트워크 보안 그룹 만들기에 대해 알아보세요.

중첩된 가상화는 Hyper-V VM(가상 머신) 내에서 Hyper-V를 실행할 수 있는 기능입니다. 중첩된 가상화는 가상 컴퓨터에서 Visual Studio 휴대폰 에뮬레이터를 실행하거나 일반적으로 여러 호스트가 필요한 구성을 테스트하는 데 유용합니다.

Dv3, Dv4, Ev3, Ev4처럼 nested virtualization을 지원하는 SKU를 사용해서 hyper-v를 사용 수 있습니다.

(위에서 언급한 SKU외에도 nested virtualization을 지원하는 SKU는 다수 있습니다)

필수 구성 요소

• Hyper-V 호스트는 Windows Server 2016 이상 또는 Windows 10 이상이어야 합니다.
• VM 구성 버전 8.0 이상.

• Hyper-V 호스트는 Windows Server 2022 이상 또는 Windows 11 이상이어야 합니다.
• VM 구성 버전 9.3 이상.
•  

Windows Server 2019를 첫 번째 수준 VM으로 사용하는 경우 vCPU 수는 225개 이하여야 합니다

중첩된 가상화를 사용하여 가상 컴퓨터에서 Hyper-V 실행Run Hyper-V in a Virtual Machine with Nested Virtualization | 마이크로소프트 런(Microsoft T

중첩된 가상화를 사용하여 가상 컴퓨터에서 Hyper-V 실행Run Hyper-V in a Virtual Machine with Nested Virtualization | 마이크로소프트 런(Microsoft T

Hyper-V 호스트 원격 관리 | 마이크로소프트 런(Microsoft T

Windows Server에 Hyper-V 역할 설치 | 마이크로소프트 런(Microsoft T

Install-WindowsFeature (ServerManager) | 마이크로소프트 런(Microsoft T

끝.

hub and spoke 구조는 Virtual WAN을 사용하지 않고 virtual network 로만 구성하고자 할때 Azure에서 권장하는 구조입니다. 일반적으로 온프레미스와 virtual network gateway간 연결해서 사용할 때 자주 볼 수 있는 아키텍쳐이며, 본 포스트는 아래와 같은 구조에서 virtual machine끼리 통신하도록 하는 예제입니다.

단순 vnet peering 만으로는 spoke1-vm과 spoke2-vm간 통신이 불가능하고, route tables라는 리소스를 생성해서 적용해 줘야 합니다. Azure 공식 문서에는 잠깐의 언급만 하고 자세히 다루지는 않아서 본 포스트에서 spoke1-vm과 spoke2-vm간 통신하는 예제를 다루어 보았습니다.

*링크 : Create, change, or delete an Azure virtual network peering | Microsoft Docs

리소스 그룹 생성

포털에 resource group 검색 후 create 버튼 클릭

virtual network 생성

총 3개의 vnet을 생성합니다.

hub-vnet : 10.50.0.0/16, default 10.50.1.0/24, GatewaySubnet 10.50.2.0/24

(게이트웨이 서브넷 이름은 무조건 'GatewaySubnet'이어야 함)

spoke1-vnet : 10.60.0.0/16, default 10.60.1.0/24

spoke2-vnet : 10.61.0.0/16, default 10.61.1.0/24

spoke1-vnet과 spoke2-vnet도 위와 같이 생성합니다.

Virtual network gateway 생성

포털에서 virtual network gateway 검색 후 create 클릭

피어링 설정

hub-vnet과 spoke1-vnet간 vnet peering을, hub-vnet과 spoke2-vnet간 vnet peering을 맺습니다

add 버튼 클릭

hub-vnet과 spoke2-vnet에 대해서도 위와 같이 설정해 줍니다.

Virtual Machine 생성

spoke1-vm과 spoke2-vm을 생성합니다.

아래 화면처럼 spoke1-vnet을 선택해 줍니다.

spoke2-vm에 대해서도 위와 같이 생성해 줍니다.

spoke1-vm에 ssh 연결해서 spoke2-vm으로 ping을 보내면 전부 packet loss 됨을 확인할 수 있습니다.

Route tables 생성 및 적용

spoke1-udr, spoke2-udr을 각각 만들어 줍니다

*udr : user defined route

Routes 탭에서 add 버튼을 클릭한 후, destination ip addresses에 spoke2-vnet의 대역을 입력합니다

(마찬가지로 spoke2-udr에는 spoke1-vnet의 대역을 입력합니다)

route 생성 후, 아래와 같이 spoke1-vnet의 default 서브넷, spoke2-vnet의 default 서브넷에 각각 적용시켜 줍니다

route table 을 각 서브넷에 적용 후, spoke1-vm에서 spoke2-vm으로 ping을 날리면 정상적으로 패킷 송수신이 되는 것을 확인하실 수 있습니다.

테스트가 완료되었을 경우 resource group을 삭제합니다.

Windows Server의 RRAS (Routing and Remote Access Service) 기능을 사용하여 Azure Virtual Network와 S2S VPN을 연결하는 방법을 소개합니다.

S2S (Site to Site) VPN은 온프레미스 네트워크와 Azure Virtual Network 간의 연결을 의미하는데, 온프레미스의 VPN 장비와 Azure의 VPN Gateway를 서로 연결해서 구성합니다.

S2S VPN 구성을 테스트하고 싶어도 온프레미스에 VPN 장비가 없으면 테스트가 거의 불가능합니다.

이 글에서는 Azure Virtual Network를 온프레미스 네트워크라고 가정하고, Windows Server에 RRAS 역할을 설치하여 VPN 장비처럼 동작하도록 구성하는 방법을 소개합니다.

테스트 구성도를 보시면 좀 더 쉽게 이해하실 수 있을겁니다.

왼쪽의 Virtual Network를 온프레미스 네트워크라고 가정하고, rras-vm을 VPN 장비처럼 동작하도록 구성하는 방법을 소개할 예정입니다.

테스트 환경 구성이 완료되면 온프레미스의 dmz-svr01과 Azure의 mgmt-vm간에 private ip 주소로 통신이 가능해집니다.

*중요 Microsoft는 Azure 의 Windows Server 가상 머신에서의 RRAS 사용을 공식적으로는 지원하지 않습니다. https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines 따라서, Azure에서는 테스트 용도로만 RRAS를 사용해야 합니다. Azure에서 RRAS를 사용하다가 문제가 생기더라도 Microsoft로부터 지원을 받을 수 없습니다.

*테스트에서는 Azure Korea Central 지역을 사용합니다.

1. 가상 네트워크 구성

구성도와 같이 두 개의 가상 네트워크를 만듭니다.

2. VPN Gateway 생성

Hub-VNET에 VPN Gateway를 만듭니다.

저는 아래와 같이 설정하였습니다.

VPN Gateway가 생성되면 Public IP address를 확인합니다.

3. RRAS용 Windows VM 생성

Windows Server 2019 VM을 생성합니다.

저는 아래와 같이 설정했습니다만, 동일하게 설정하지 않으셔도 됩니다.

• Image : Windows Server 2019 Datacenter - Gen2
• Size : Standard D2as_v4

Virtual network와 Subnet은 아래와 동일하게 설정합니다.

• Virtual network : OnPrem-NW
• Subnet : RRAS-Subnet

RRAS VM 생성이 완료되면 VM을 중지합니다. 

VM이 중지되면 IP 주소를 테스트 구성도처럼 지정합니다.

첫 번째 NIC의 IP 주소를 테스트 구성도처럼 지정합니다. (192.168.100.101)

두 번째 NIC 추가 및 테스트 구성도처럼 IP 주소를 지정합니다. (192.168.200.101)

두 번째 NIC는 DMZ-Subnet에 연결합니다.

두 번째 NIC의 IP configurations 메뉴에서 IP forwarding을 Enabled로 변경합니다.

RRAS VM을 시작합니다.

4. RRAS VM Windows 방화벽 중지 및 NSG 설정

RRAS VM의 Windows 방화벽을 중지합니다.

VPN Gateway와 S2S VPN 연결을 위해, RRAS VM의 NSG의 Inbound 규칙에 아래의 Port들을 허용으로 추가합니다.
*Source는 VPN Gateway의 Public IP 주소, Destination은 RRAS VM의 첫 번째 NIC의 Private IP 주소
- TCP port 443 (SSTP)
- UDP port 500 (IKEv2)
- UDP port 4500 (IKEv2 NAT traversal)

5. VPN Gateway 설정

Local Network Gateway와 Connection 리소스를 생성합니다.

Local Network Gateway를 생성할 때,

IP address에는 RRAS VM의 Public IP 주소를 입력하고,

Address Space에는 온프레미스 IP 대역을 입력합니다. (192.168.0.0/16)

Connection 리소스를 생성할 때, Connection type은 Site-to-site (IPsec)을 선택합니다.

Virtual network gateway, Local network gateway, Shared key(PSK)를 지정합니다.

나머지 옵션은 기본값을 사용합니다.

* Shared key는 RRAS 구성에서도 사용됩니다.

6. RRAS 역할 설치

RRAS VM에 원격으로 접속한 후 RRAS 역할을 설치하고 구성합니다.

Server Manager - Add Roles and Features

Server Roles에서 Remote Access를 선택합니다.

Role Services에서 DirectAccess and VPN (RAS), Routing을 선택합니다.

나머지 옵션들은 기본값을 사용해서 RRAS 역할을 설치합니다.

7. RRAS 구성

* 이 부분이 이번 글에서 핵심입니다.

RRAS 역할이 설치된 후 Azure VPN Gateway와 연결하기 위해 RRAS를 구성합니다.

Routing and Remote Access 관리 콘솔을 실행합니다.

RRAS VM을 오른쪽 버튼 클릭하고 'Configure and Enable Routing and Remote Access'를 클릭합니다.

Routing and Remote Access Server Setup Wizard

• [Next]

Configuration

• 'Secure connection between two private networks' 
• [Next]

Demand-Dial Connections

• 'No' 
• [Next]

Completing the Routing and Remote Access Server Setup Wizard

• [Finish]

Network Interfaces 오른쪽 버튼 클릭 - 'New Demand-dial Interface' 클릭

Demand-Dial Interface Wizard

• [Next]

Interface Name

• Interface name : AzureVPNGW
• [Next]

Connection Type

• Connect using virtual private networking(VPN)
• [Next]

VPN Type

• IKEv2
• [Next]

Destination Address

• VPN Gateway의 Public IP 주소 입력
• [Next]

Protocols and Security

• Route IP packets on this interface
• [Next]

Static Routes for Remote Networks

• [Add]
• Azure IP 대역 등록 (172.16.0.0/16)
• [Next]

Dial-Out Credentials

• [Next]

Completing the Demand-Dial Interface Wizard

• [Finish]

*Preshared key를 지정합니다.

새로 생성된 Network Interface 오른쪽 버튼 클릭 - 'Properties'

[Security] 탭

• Use preshared key for authentication - Preshared key 입력 ('12345')
• [OK]

*Azure VPN Gateway와 연결합니다.

AzureVPNGW 오른쪽 버튼 클릭 - 'Connect'

연결 완료 (Connection State가 Connected로 표시됩니다.)

VPN Gateway Connection 리소스를 확인해보면, Status가 Connected로 표시됩니다.

(Connected로 표시되기까지 약 3~5분 정도 걸립니다.)

이제 S2S VPN 연결이 완료되었습니다.

8. 테스트용 VM 생성

네트워크 통신 테스트를 위한 VM들을 온프레미스 네트워크(OnPrem-NW)와 Azure Virtual Network(Hub-VNET)에 생성합니다.

(dmz-svr01, mgmt-vm)

*VM을 생성하는 과정에 대한 설명은 생략합니다.

9. 온프레미스 서브넷에 UDR 설정

*이 부분도 중요합니다.

온프레미스(OnPrem-NW)에서 Azure Virtual network(Hub-VNET)의 IP 대역으로 나가는 트래픽이 RRAS를 통과하도록 하기위해 UDR을 사용합니다.

Routes에서

• Address prefix는 Azure IP 대역을 지정하고 (172.16.0.0/16),
• Next hop type은 'Virtual appliance',
• Next hop IP address는 RRAS의 두 번째 NIC의 IP 주소를 입력합니다 (192.168.200.101).

UDR을 온프레미스 서브넷(DMZ-Subnet)에 연결합니다.

10. 네트워크 통신 테스트

테스트를 위해 VM의 Windows 방화벽은 중지합니다.

두 VM 간에 Private IP 주소로 통신이 가능한지 확인해봅니다.

끝.

Azure 가상 네트워크에 Azure Firewall을 배포하고, 가상 네트워크 간 라우팅, DNAT, 네트워크 필터링 규칙을 구성하는 방법을 설명합니다.

아래와 같은 테스트 환경을 구성하고 Azure Firewall을 테스트하였습니다.

• 허브(Hub) 네트워크에 Azure Firewall을 배치하여 스포크(Spoke) 네트워크 간 라우팅 처리
• Azure Firewall의 DNAT 규칙으로 인터넷 인바운드 처리
• Azure Firewall의 네트워크 규칙(Network rule)으로 스포크 네트워크 간 RDP 연결 처리

위 테스트 환경 구성은 일반적인 허브-스포크(Hub-Spoke) 구성입니다.

허브 네트워크에 Azure VPN Gateway와 Azure Firewall을 배치하고, 온프레미스와는 S2S VPN으로 연결하고, 다른 Azure 가상 네트워크는 Peering으로 연결합니다.

테스트에서는 온프레미스의 Windows Server 2019에 RRAS(Routing and Remote Access Service) 역할을 구성하여 Azure VPN Gateway와 S2S로 연결하였습니다.

1. 가상 네트워크 생성 및 Peering으로 연결

Azure에 아래와 같이 3개의 가상 네트워크를 만듭니다.

허브 네트워크(VNET-Hub)에 VPN Gateway를 배포하고, 온프레미스와 S2S VPN을 연결합니다. (온프레미스와 S2S VPN 연결에 대한 설명은 생략합니다.)

허브 네트워크(VNET-Hub)와 스포크 네트워크들(PRD-VNET, DEV-VNET)은 Peering으로 연결하였습니다.

참고로, Peering 옵션에서 Gateway transit을 사용하도록 설정하였습니다.

가상 네트워크 구성이 완료된 후 가상 머신을 배포합니다.

2. Azure Firewall 배포

허브 네트워크(VNET-Hub)에 Azure Firewall을 배포합니다. Azure Firewall은 AzureFirewallSubnet이라는 이름의 전용 서브넷에 배포되어야 합니다. 서브넷 사이즈는 /26으로 만듭니다.

Azure Firewall 배포

Azure Firewall 배포가 완료되면 Azure Firewall의 Private IP 주소를 확인합니다.

3. 라우팅 테이블 구성 (UDR)

네트워크 간 트래픽이 Azure Firewall을 거치도록 라우팅 테이블을 구성합니다.

스포크 네트워크들(PRD-VNET, DEV-VNET)은 Next hop을 Azure Firewall로 지정합니다.

GatewaySubnet은 Next hop으로  Azure Firewall을 지정합니다.

4. DNAT 규칙 추가

인터넷에서 PRD-VNET의 WEB VM으로 HTTP (TCP 80) 접속을 허용하는 DNAT 규칙을 Azure Firewall에 추가합니다.

DNAT(Destination NAT) 규칙을 사용하면, 인터넷에서 Azure 가상 네트워크의 VM으로의 직접적인 연결은 차단하고, Azure Firewall의 공인 IP 주소를 통해 Azure VM으로 연결될 수 있도록 구성할 수 있습니다.

우선 Azure Firewall에 Public IP 주소를 하나 추가합니다.

Azure Firewall의 Rule - NAT rule collection에 아래와 같이 DNAT 규칙을 추가합니다.

브라우저에서 DNAT 규칙의 공인 IP 주소로 접속해봅니다.

5. 네트워크 규칙 추가

Azure Firewall에 온프레미스와 Azure PRD, DEV 네트워크간 RDP 연결을 허용하는 규칙을 생성합니다. 

네트워크 규칙(Network rule)으로 Azure VM으로 들어오고 나가는 네트워크 연결을 허용하거나 차단할 수 있습니다.

Azure Firwall - Rules - Network rule collection에 RDP 허용 규칙을 추가합니다.

RDP 허용 규칙 추가 후 각 네트워크 간 RDP 연결이 되는지 확인해봅니다.

온프레미스 -> PRD-VNET의 VM으로 RDP 연결

PRD-VNET의 VM에서 DEV-VNET VM으로 RDP 연결

-끝