깡민쓰~IT Story

소개:

현재의 원격 작업 추세로 인해 원격 세션의 보안 및 규정 준수를 보장하는 것이 조직의 최우선 과제가 되었습니다. Azure Virtual Desktop은 원격 세션에서 새로운 수준의 보안 및 가시성을 제공하는 새로운 워터마크 기능을 통해 이러한 과제에 한 걸음 더 다가섰습니다. 이 블로그 게시물에서는 워터마킹 기능이 무엇인지, 그 이점, 설정 방법, 작업 방식을 혁신할 수 있는 방법에 대해 자세히 살펴보겠습니다.

워터마킹 기능이란 무엇입니까?

워터마크 기능은 Azure Virtual Desktop에 새로 추가된 기능으로, 연결 ID가 있는 QR 코드를 포함하여 원격 세션에 워터마크를 추가할 수 있습니다. 이렇게 하면 관리자가 특정 연결 및 사용자에 대한 무단 화면 캡처를 추적할 수 있으므로 추가 보안 계층이 제공됩니다.

워터마킹 기능이 중요한 이유는 무엇입니까?

워터마킹 기능은 기존 화면 캡처 보호의 한계를 해결하고 원격 세션에서 새로운 수준의 보안 및 규정 준수를 제공합니다. 이 기능을 통해 조직은 기밀 정보를 보호하고 무단 액세스 또는 데이터 유출을 방지할 수 있습니다.

필수 구성 요소:

AVD 워터마킹을 사용하려면 먼저 다음이 필요합니다.

• Windows 데스크톱 클라이언트 버전 1.2.3317 이상, Windows 10 이상.
• Azure Virtual Desktop Insights는 사용자 환경에 맞게 구성됩니다.
• Azure Virtual Desktop에 대한 관리 템플릿입니다.

워터마킹 기능을 설정하는 방법

워터마킹 기능을 설정하는 것은 간단하고 간단합니다. 따라야 할 단계는 다음과 같습니다.

1.AVD용 관리 템플릿 다운로드 및 추가

2.정책 설정 "Enable watermarking(워터마크 사용)"을 Enabled(사용)로 설정

3.세션 호스트에 정책 설정을 적용합니다.

4.그룹 정책 업데이트 또는 Intune 디바이스 동기화를 실행하여 클라이언트에 정책을 푸시합니다.

5.QR 코드가 표시되고 QR 기능의 유효성을 검사해야 하는 원격 세션에 연결합니다.

7.QR 코드를 사용하여 세션 정보를 찾습니다.

8.연결 진단을 위해 Azure Virtual Desktop Insights에 연결합니다.

9.Azure Log Analytics를 사용하여 세션 세부 정보를 가져옵니다.

QR 및 AVD Insights를 사용한 연결 진단:

• 이 링크를 사용하여 Azure Virtual Desktop Insights를 엽니다 https://aka.ms/avdi
• 관련 호스트 풀 및 시간 범위를 선택한 다음, 연결 진단 탭을 선택합니다.
• Success rate of (re)establishing a connection (% of connections) 섹션에서
• 첫 번째 시도, 연결 ID, 사용자 및 시도를 보여주는 모든 연결 목록이 있습니다.

  

   
• 이 목록의 QR 코드에서 연결 ID를 찾거나 Excel로 내보낼 수 있습니다.

Azure Log Analytics를 사용하여 세션 세부 정보를 가져옵니다.

• Azure Virtual Desktop 환경에 연결된 Log Analytics 작업 영역을 엽니다.
• 새 쿼리를 시작한 다음, 다음 쿼리를 실행하여 특정 연결 ID(Log Analytics에서 CorrelationId로 표시됨)에 대한 세션 정보를 가져오고 <연결 ID>를 QR 코드의 전체 또는 부분 값으로 바꿉니다.

특정 연결 ID에 대한 세션 정보를 가져오려면:

WVDConnections
|where CorrelationId contains == “<connection ID>”

워터마킹 기능이 작업 방식을 혁신하는 방법

워터마킹 기능은 원격 작업에 새로운 차원의 가시성과 제어 기능을 제공할 수 있습니다. 이 기능을 통해 조직은 다음을 수행할 수 있습니다.

1.특정 연결 및 사용자에 대한 무단 화면 캡처를 추적합니다.

2.원격 세션의 보안 및 규정 준수를 보장합니다.

3.원격 근무 관리를 간소화합니다.

4.원격 세션에서 가시성과 제어를 극대화합니다.

결론:

결론적으로 Azure Virtual Desktop의 워터마크 기능은 원격 인력 관리를 위한 게임 체인저입니다. 원격 세션에서 새로운 차원의 보안과 가시성을 제공하고 조직이 원격 작업 관리를 간소화할 수 있도록 합니다. 이 흥미로운 새로운 기능을 놓치지 마세요 – 지금 설정하고 원격 작업을 한 단계 업그레이드하세요!

https://youtu.be/imKyyhK-tb4

#Install the Az module if you haven't done so already.
#Install-Module Az
#Login to your Azure account.
#Login-AzAccount
#Define the following parameters for the virtual machine.
$vmAdminUsername = "vmadm"
$vmAdminPassword = ConvertTo-SecureString "Pa$$w0rd!!!" -AsPlainText -Force
$vmComputerName = "test-vm12"
#Define the following parameters for the Azure resources.
$azureLocation              = "Korea Central"
$azureResourceGroup         = "test-vm-rg"
$azureVmName                = "test-vm12"
$azureVmOsDiskName          = "test-vm12-OS"
$azureVmSize                = "Standard_D8s_v3"
#Define the networking information.
$azureNicName               = "test-vm12-NIC"
$azurePublicIpName          = "test-vm12-IP"
#Define the existing VNet information.
$azureVnetName              = "test-vm-vnet"
$azureVnetSubnetName        = "default"
#Define the VM marketplace image details.
$azureVmPublisherName = "MicrosoftWindowsServer"
$azureVmOffer = "WindowsServer"
#$azureVmSkus = "2019-Datacenter"
$azureVmSkus = "2022-Datacenter"
#Get the subnet details for the specified virtual network + subnet combination.
$azureVnetSubnet = (Get-AzVirtualNetwork -Name $azureVnetName -ResourceGroupName $azureResourceGroup).Subnets | Where-Object {$_.Name -eq $azureVnetSubnetName}
#Create the public IP address.
#$azurePublicIp = New-AzPublicIpAddress -Name $azurePublicIpName -ResourceGroupName $azureResourceGroup -Location $azureLocation -AllocationMethod Dynamic
$azurePublicIp = New-AzPublicIpAddress -Name $azurePublicIpName -ResourceGroupName $azureResourceGroup -Location $azureLocation -AllocationMethod Static 
#Create the NIC and associate the public IpAddress.
$azureNIC = New-AzNetworkInterface -Name $azureNicName -ResourceGroupName $azureResourceGroup -Location $azureLocation -SubnetId $azureVnetSubnet.Id -PublicIpAddressId $azurePublicIp.Id
#Store the credentials for the local admin account.
$vmCredential = New-Object System.Management.Automation.PSCredential ($vmAdminUsername, $vmAdminPassword)
#Define the parameters for the new virtual machine.
$VirtualMachine = New-AzVMConfig -VMName $azureVmName -VMSize $azureVmSize
$VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName $vmComputerName -Credential $vmCredential -ProvisionVMAgent -EnableAutoUpdate
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $azureNIC.Id
$VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine -PublisherName $azureVmPublisherName -Offer $azureVmOffer -Skus $azureVmSkus -Version "latest"
$VirtualMachine = Set-AzVMBootDiagnostic -VM $VirtualMachine -Disable
$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -StorageAccountType "Premium_LRS" -Caching ReadWrite -Name $azureVmOsDiskName -CreateOption FromImage
#Create the virtual machine.
New-AzVM -ResourceGroupName $azureResourceGroup -Location $azureLocation -VM $VirtualMachine -Verbose



업데이트 : VM에 데이터 디스크를 추가하려면 아래 코드 스 니펫을 사용할 수 있습니다.
#Define the following parameters for the Azure resources. Add this to the "#Define the following parameters for the Azure resources." code section.
$azureVmDataDisk01Name      = "BS-SRV-SQL01-Data01"
#Optionally, add an additional data disk. Add this to the "#Define the parameters for the new virtual machine." code section.
$vmDataDisk01Config = New-AzDiskConfig -SkuName Standard_LRS -Location $azureLocation -CreateOption Empty -DiskSizeGB 127
$vmDataDisk01 = New-AzDisk -DiskName $azureVmDataDisk01Name -Disk $vmDataDisk01Config -ResourceGroupName $azureResourceGroup
$VirtualMachine = Add-AzVMDataDisk -VM $VirtualMachine -Name $azureVmDataDisk01Name -CreateOption Attach -ManagedDiskId $vmDataDisk01.Id -Lun 0

1. So with that here’s what I’m going to cover in this demo

1.1Create your Function App

1.2Set Function App Trigger

1.3Add the Custom domain

1.4Test and validateResources:

By default, all users are accessing their browser-based virtual desktops is via the same link using a Microsoft URL which is same for all customer (https://rdweb.wvd.microsoft.com/webclient/index.html)

As this URL is a bit long as well as not that easy to memorize, most of entities will be looking for setting their own Custom URL using the corporate domain name. same idea as myapps.3tallah.com or mail. 3tallah.com, for sure it would be up to you to set your preferred subdomain name.

In this blogpost we are going to use Azure Functions, which allows you to execute your code in a serverless compute platform, and the consumption plan pricing includes a monthly free grant of 1 million requests, this would be saving you from the hassle of creating, configuring and securing an IIS virtual machine and will as the cost of compute.

So with that here’s what I’m going to cover in this demo

1.Create your Function App

2.Set HTTP Trigger

3.Add the Custom domain

4.Test and validate

Create your Function App

Open Create a Function App blade

• Subscription: Select the subscription where the new Function App will be created.
• Resource group: Create a new resource group or use an existing one.
• Function App name: Enter globally unique name for the Function App (Ex.wvdwebredirect01)
• Publish: Select (Code)
• Runtime stack: .NET CoreVersion: 3.1
• Region: Select the (Region) where you want to create the Function App

When creating a function app, you must create or link to a general-purpose Azure Storage account that supports Blobs, Queue, and Table storage. Select The Operating System that’s recommended for you based on your selection of runtime stack, And The plan that dictates how your app scales, what features are enabled, and how it is priced.

• Storage: Create a new StorageAccount or use an existing one.
• Operating system: Select (Windows),
• Plan: Select (Consumption Servless)

Application Insights is a code-less attach to provide detailed observability into your application.Don’t enable Application Insights as its not really required for this scenario.

Function app creation is completed and that gives us an app service that’s the function app itself, an app service plan which is the compute that it’s connected to when it runs, and there’s also a storage account here in case we need to store any data.

Set Function App Trigger

1.Open

Function App blade

2.Click on the created Function App in our case (wvdwebredirection)

3.Click on the Function tab > Click Add

4.Click on the HTTP Trigger

1. Give the New Trigger Function a Name ( Ex. WVDHttpTrigger )
   
2. Select Funcation as Authorization level >Create

1.Once created open Code + Test Tab, So that we’re going to just delete all the exist code and use Tom’s Code below

2.Github Link

3.Only change that you have to do is it change this part (“wvd.3tallah.com“) with yours

4. Click Save > Click Get function URL > Copy the URL

1.Go back the created Function App main blade in our case (wvdwebredirection)

2.Click on the Proxies tab > Click Add > Give it a Name

3.Route template just add (/)

4.Backend URL: paste the Copied function URL > Click Create

Add the Custom domain

Last step is to add your corporate domain as a custom domain lets hit to Custom domains tab so we can configure and manage custom domains assigned to your app.

1.Open

   Function App blade

2.Click on the created Function App in our case (wvdwebredirection)

3.Copy Function App URL and Custom Domain Verification ID

4.Open your DNS Provider to Create new DNS Record.

5.Create CNAME Record for this Function App URL in DNS provider.

1.Create TXT Record in DNS provider verify your ownership of the custom domain.

1.Back to the Function App blade

2.Click on the Custom domains tab > Click Add custom domain

3.Enter your corporate URL (Ex. wvd.3tallah.com) > Click Validate

It’ll show that you do own your domain and the hostname is available and then you can click the add custom domain button and then added for HTTP but not for an SSL state so if you want you can add a SSL certificate and do a binding here or that you can make this secure I’m gonna skip this step because this is just my lab now we should be able to test.

Test and validate

Open http://wvd.3tallah.com

Resources:

Code that have been used in this demo is being developed by Tom Hickling

SYSVOL is a folder shared by domain controller to hold its logon scripts, group policies and other items related to AD. All the domain controllers in network will replicate the content of SYSVOL folder. The default path for SYSVOL folder is %SystemRoot%\SYSVOL. This folder path can define when you install the active directory. 
Windows Server 2003 and 2003 R2 uses File Replication Service (FRS) to replicate SYSVOL folder content to other domain controllers. But Windows server 2008 and later uses Distributed File System (DFS) for the replication.  DFS is more efficient than FRS. Since windows server 2003 is going out of support, most people already done or still looking for migrate in to latest versions. However migrating FSMO roles WILL NOT migrate SYSVOL replication from FRS to DFS. Most of the engineers forget about this step when they migrate from windows 2003 to new versions. 
For FRS to DFS migration we uses the Dfsrmig.exe utility. More info about it available on https://technet.microsoft.com/en-au/library/dd641227(v=ws.10).aspx
For the demo I am using windows server 2012 R2 server and I migrated FSMO roles already from a windows server 2003 R2 server. 
In order to proceed with the migration forest function level must set to windows server 2008 or later. So if your organization not done this yet first step is to get the forest and domain function level updated. 
You can verify if the system uses the FRS using dfsrmig /getglobalstate , To do this
1)    Log in to domain controller as Domain admin or Enterprise Admin
2)    Launch powershell console and type dfsrmig /getglobalstate. Output explains it’s not initiated DFRS migration yet. 

Before move in to the configurations we need to look into stages of the migration. 
There are four stable states going along with the four migration phases. 
1)    State 0 – Start
2)    State 1 – Prepared
3)    State 2 – Redirected 
4)    State 3 – Eliminated 
State 0 – Start
With initiating this state, FRS will replicate SYSVOL folder among the domain controllers. It is important to have up to date copy of SYSVOL before begins the migration process to avoid any conflicts. 
State 1 – Prepared
In this state while FRS continues replicating SYSVOL folder, DFSR will replicate a copy of SYSVOL folder. It will be located in %SystemRoot%\SYSVOL_DFRS by default. But this SYSVOL will not response for any other domain controller service requests. 
State 2 – Redirected
In this state the DFSR copy of SYSVOL starts to response for SYSVOL service requests. FRS will continue the replication of its own SYSVOL copy but will not involve with production SYSVOL replication.
State 3 – Eliminated
In this state, DFS Replication will continue its replication and servicing SYSVOL requests. Windows will delete original SYSVOL folder users by FRS replication and stop the FRS replication. 
In order to migrate from FRS to DFSR its must to go from State 1 to State 3.
Let’s look in to the migration steps.
Prepared State
1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 1 and press enter

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached prepared state

Redirected State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 2 and press enter


4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached redirected state

Eliminated State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 3 and press enter

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached eliminated state

This completes the migration process and to confirm the SYSVOL share, type net share command and enter.

Also make sure in each domain controller FRS service is stopped and disabled.

Password reset for AD users is a common call, ticket for the help desk. This is sometime negatively affecting company operations. Because users will not have access to systems and applications until the password reset by help desk engineers. What if we can allow end users to reset their passwords them self in a secure manner?
Yes Azure AD is now gives opportunity to enable self-service password reset for the end-users. Also the password resets can sync with on-premises AD.
This feature is disabled by default. In this demo I will explain how to enable this feature and configure. 
On the demo setup I am using have Azure AD instance which is sync with on-premises windows server 2016 TP4 AD.
1)    Log in to the Azure Portal and load the Azure AD Instance
2)    Then in Dashboard, under configure services you can find option “Self Service Password Reset” By default it’s disabled. Click on “Configure” to proceed with configuration. 

3)    Then in next page under User Password Reset Policy select option “Yes” next to “Users enabled for password reset”

4)    Now it will give you options to configure the policy for the password reset. Let’s look in to  some of these options and understand what they do. 
Restrict access to password reset – Using this option password reset can only allow for a security group instead of allowing it for every user in the instance. Any member of allowed security group will get option to do a self-service password reset. 
Authentication Methods Available to Users – its allow you to use following options to select with. We can allow to use any selected authentication methods for users.  
Number of Authentication Methods Required – In this option we can choose how many methods required for successful password reset

Require users to register when signing in? – When this option is enabled users can register their own authentication method when sign up. 

Write back passwords to on-premises active directory – with this option if a user reset password using self-service portal it will write back to the on-premises AD too.
In order to get this write back option work, it need to be enabled in Azure AD connect in on-premises AD. 

5)    In demo I am configuring “Security Questions” as authentication method. With that option you can define the different security questions, as well as the number of questions required to answer. 

6)    Once options are configure click on save to apply the changes.

7)    Let’s see how it works in user end.  I am trying to log in to azure portal as standard user. In first login it’s ask additional information to setup for password reset. Click on setup to provide the additional info.

8)    Now all the additional info is saved. Let’s see how it works. I am going to log in with wrong password to simulate it. As soon as I done it, it ask if you need to reset the login. 

9)    Clicked on “Forgot your password ?” option

10)    As first check it’s asking to enter the characters in picture. Click next to continue

11)    Then it ask which option to use for the password reset, according to the policy. Select the option you like to use. 

12)    Then it’s ask for the second authentication. As per the policy.

13)    Once authentication success, it’s ask to submit the new password. 

14)    Once its finish you can successfully login with new password. 

.

1. Application Gateway의 암호화

2. Application Gateway를 통한 트래픽 암호화 로직

3. Application Gateway의 TLS Termination

3.1 Backend Server TLS 암호화

4. Application Gateway의 TLS Termination 구성

4.1 SSL Certificate 만들기

4.1.1 회원 가입

4.1.2 Certificate 생성

4.1.3 도메인 인증

4.1.4 Certificate Download

4.1.5 SSL Certificate 포맷 변환 (.crt → .pfx)

4.2 Application Gateway에 Certificate 업로드

4.2.1 수신기 생성 및 Certificate 업로드

4.2.2 규칙 생성

4.3 HTTPS를 사용하여 Application 접근

            SSL/TLS란? 
https://sundlscha.tistory.com/11

 

SSL/TLS 알아 보기
1. SSL와 TLS란? SSL(Secure Socket Layer; 보안 전송 계층) 암호화 기반 인터넷 보안 프로토콜로 웹사이트와 브라우저 사이 또는 두 서버 사이에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기
sundlscha.tistory.com


 
1. Application Gateway의 암호화
먼저 Application Gateway의 암호화에 대해 정리해 보았습니다.  

Application Gateway Flow (https://learn.microsoft.com/ko-kr/training/modules/end-to-end-encryption-with-app-gateway/2-application-gateway-and-encryption)



Application Gateway는 전송 중 데이터 암호화를 위해 인증 기관에서 인증서를 구매하여 서버로 들어오고 나가는 메시지를 암호화할 수 있습니다. 이러한 암호화를 통해 전송 중인 메시지를 권한 없는 사용자가 가로채서 그 안에 있는 정보를 볼 수 없게 됩니다. 
Application Gateway는 HTTP 트래픽 로드 밸런싱, WAF 방화벽 및 데이터의 SSL 암호화 지원과 같은 기능을 제공합니다. 또한 사용자와 Application Gateway 간의 트래픽, Application Server와 Application Gateway 간의 트래픽 암호화를 지원합니다. 

기본적으로 SSL Termination 수행 시 사용자와 Application Gateway 간의 트래픽은 HTTPS로 암호화되고 Application Gateway와 Backend Server 간의 트래픽은 HTTP로 통신이 이루어집니다. 
만일, Application Gateway에서 Backend Server로 가는 트래픽 역시 HTTPS로 암호화하여 구성하고 싶을 경우 Application Gateway에서 지원하는 End-to-End TLS 암호화를 구성하면 됩니다. End-to-End TLS Encryption 설명 

(https://learn.microsoft.com/en-us/azure/application-gateway/ssl-overview#end-to-end-tls-encryption)




Application Gateway에서 SSL Termination을 수행할 경우 서버에 인증서를 설치하고 SSL을 구성할 필요가 없어집니다. 

 
2. Application Gateway를 통한 트래픽 암호화 로직
Application Gateway를 통한 트래픽이 암호화 되는 방식에 대해 좀 더 알아보겠습니다.
Application Gateway 구성 요소

 (https://learn.microsoft.com/ko-kr/training/modules/end-to-end-encryption-with-app-gateway/2-application-gateway-and-encryption)



트래픽은 Frontend의 포트를 통해 들어오고 수신기를 거쳐 규칙에 맞게 수신 요청을 Backend Pool에 전달합니다. 
수신기 (Listener)

특정 호스트, 특정 IP 주소의 특정 포트를 수신 대기하도록 설정된 리소스로 SSL 인증서를 사용하여 Application Gateway로 들어오는 트래픽을 암호 해독 할 수 있습니다. 
수신기가 지원하는 포트 (여러 포트 open 가능)는 다음과 같습니다.

3. Application Gateway의 TLS Termination
그렇다면 TLS Termination 구성의 장점은 무엇일까요?
(https://learn.microsoft.com/ko-kr/azure/application-gateway/ssl-overview#tls-termination에 대해서 읽어보시는 것을 권장 드립니다.)

●TLS 암호 해독 시 성능에 가장 부하를 주는 것은 초기 Handshake이기 때문에 Application Gateway에서 TLS Termination을 수행할 경우, Client의 모든 요청에 대해 캐시된 값을 사용할 수 있습니다. cf) Backend Server에서 TLS Termination 수행할 경우, Client의 요청이 다른 Server로 갈 때마다 Client가 다시 인증을 해야 하는 번거로움이 발생합니다. 
● SSL/TLS 통신 시 CPU 사용률이 높으며 SSL/TLS 통신 시 사용하는 키의 크기가 커짐에 따라 이 사용률은 더 증가하고 있습니다. 그렇기 때문에 Backend Server에서 이 작업을 하지 않을 경우 Server는 데이터를 가장 효율적으로 전달할 수 있는 방식에 대해서만 집중할 수 있게 됩니다.
● Application Gateway가 트래픽의 암호를 해독할 때 헤더, URI 등에 액세스 할 수 있기 때문에 이를 활용하여 요청을 지능적으로 라우팅할 수 있습니다.
● Application Gateway에만 Certificate를 설치하면 되기 때문에 시간과 비용을 절약할 수 있습니다. 

 
이를 통해 Application Gateway는 들어오는 트래픽을 해독하고 Client에 대한 response 트래픽을 암호화할 수 있습니다. 
 
3.1 Backend Server TLS 암호화
※ 이번 포스팅에서는 이 부분에 대한 테스트를 다루고 있지는 않습니다.

●  Backend Server로 전달되는 트래픽을 암호화하여 보내고자 할 경우 Application Gateway의 End-to-End TLS 암호화 기능을 사용하면 됩니다. 
●  End-to-End TLS는 백 엔드 설정에서 백 엔드 프로토콜을 HTTPS로 변경하여 사용 가능합니다. 

 
4. Application Gateway의 TLS Termination 구성
4.1 SSL Certificate 만들기
4.1.1 회원 가입


●  SSL Certificate를 무료로 발급할 수 있는 사이트(ex. https://www.sslforfree.com/) 접속한 후 회원 가입을 진행합니다.

Certificate 관련 메일이 수신되기 때문에 사용하는 메일을 이용해야 합니다.

4.1.2 Certificate 생성
[New Certificate] 클릭

Certificate를 발급 받고자 하는 도메인을 입력합니다.

[90-Day Certificate]를 선택합니다.

 
4.1.3 도메인 인증

실제로 도메인을 소유하고 있는지 여부를 확인하기 위한 단계로 제공하는 3가지 방법 (Email Verification, DNS(CNAME), HTTP File Upload) 중 가능한 방법으로 인증하면 됩니다. 
※ 본 테스트에서는 DNS(CNAME)을 사용하였습니다. 
 


Name, Point To, TTL을 각각 복사하여 DNS Provider에 CNAME Record를 추가합니다.

가비아에서 구매한 도메인에 대해 Azure DNS의 Name Server를 사용하도록 설정해 두었기 때문에 Azure Portal에 접속하여 해당 DNS Zone에 Record를 등록해야 합니다. 

 


4.1.4 Certificate Download

[Download Certificate (.zip)] 버튼을 클릭합니다. 

zip 파일을 압축 해제 합니다.

 
 
4.1.5 SSL Certificate 포맷 변환 (.crt → .pfx)

Win64 OpenSSL Command Prompt 실행한 후 다운로드 받은 폴더로 Directory를 변경합니다. 

pfx 파일로 변환하기 위해 하기와 같은 명령어를 입력합니다.

pkcs12 -export -out hyein-certificate.pfx -inkey private.key -in certificate.crt -certfile ca_bundle.crt

상기 명령어 실행 시 “Enter Export Password” 문구가 출력되면 Certificate의 암호로 사용할 password를 입력합니다.


변환된 Certificate를 확인합니다.

 
4.2 Application Gateway에 Certificate 업로드
4.2.1 수신기 생성 및 Certificate 업로드

 

프로토콜 : HTTPS
포트 : 443 # 기존에 수신기가 이미 존재할 경우, 그 수신기와 겹치지 않는 포트 기입 필요
PFX 인증서 파일 : # pfx 파일로 변환한 Certificate 업로드
암호 : # pfx 형식의 Certificate 생성 시 입력한 암호 입력

 
4.2.2 규칙 생성

[수신기] 선택

[백 엔드 대상] 선택

 
4.3 HTTPS를 사용하여 Application 접근

https://hyein.<domain name>을 입력하면 아래와 같이 정상적으로 Application에 접근이 가능한 것을 확인할 수 있습니다.

하기와 같이 주소창 옆  [사이트 정보 보기] 버튼을 클릭한 후 "이 연결은 안전합니다."라는 항목을 클릭할 시, 아래와 같이 인증서와 관련된 정보를 확인할 수 있습니다.

Azure Firewall을 사용하여 Spoke 간 통신하기

1. 테스트 아키텍처

2. Hub 대역 구성 

2.1 리소스 그룹 생성

2.2 가상 네트워크 생성

2.3 Azure Firewall 배포 

2.4 방화벽 규칙 생성

2.5 가상 머신 생성

2.6 Private DNS Zone 생성 

2.7 가상 네크워크 링크 생성 

3. Spoke 1 대역 구성 

3.1 리소스 그룹 생성

3.2 가상 네트워크 생성

3.3 Hub - Spoke 1 간 VNet Peering 

3.4 경로 테이블 생성

3.5 경로 테이블 구성 

3.6 가상 머신 생성  

3.7 가상 네크워크 링크 생성 

4. Spoke 2 대역 구성 

4.1 리소스 그룹 생성

4.2 가상 네트워크 생성

4.3 Hub - Spoke 2 간 VNet Peering 

4.4 경로 테이블 생성

4.5 경로 테이블 구성 

4.6 Azure Database for MySQL Flexible Server 생성

 4.7 가상 네크워크 링크 생성

 5. 통신 테스트 

5.1 Network Watcher를 통한 Next Hop 확인 

5.2 Azure Firewall 진단 설정을 통한 방화벽 규칙 적용 확인

5.3 Spoke 1 대역 VM → Spoke 2 대역 MySQL Server 접근 테스트

1. 테스트 아키텍처

 
Spoke 1 대역의 VM에서 Azure Firewall을 거쳐 Spoke 2 대역의 MySQL Flexible Server에 접근할 수 있도록 Azure 환경을 구성하는 것이 이번 주제의 목표입니다.
 
2. Hub 대역 구성 
2.1 리소스 그룹 생성

리소스 그룹 : rg-hub-test # 원하는 리소스 그룹 이름 입력영역 : (Asia Pachific) Korea Central 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역 [리소스 그룹]을 생성합니다. 

 
2.2 가상 네트워크 생성

리소스 그룹 : rg-hub-test 가상 네트워크 이름 : vnet-hub-test # hub용 가상 네트워크 이름 입력영역 : (Asia Pachific) Korea Central 
 

주소 공간 : 10.10.0.0/24 # 가상 네트워크 대역 입력서브넷 : AzureFirewallSubnet, snet-vm 추가 # [+ 서브넷 추가] 버튼을 클릭하여 주소 범위와 크기 입력 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역의 [가상 네트워크]를 생성합니다.

 
2.3 Azure Firewall 배포 
1. [가상 머신]과 Azure Database for MySQL - Flexible Server이 3306 포트를 통해 통신할 수 있도록 규칙 추가 필요2. 방화벽 규칙은 Firewall Manager을 통해 관리됨 

[기본 사항] 탭




리소스 그룹 : rg-hub-test이름 : fw-test방화벽 SKU : 표준Firewall policy : fw-policy-test # [Add new] 버튼을 클릭하여 새로운 policy 생성가상 네트워크 선택 # 기존 항목 사용가상 네트워크 : vnet-hub-test # AzureFirewallSubnet이 있는 Hub 네트워크 선택공용 IP 주소 : pip-fw-test # [새로 추가] 버튼을 클릭하여 새로운 공용 IP 생성
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역에 [방화벽]을 생성합니다.

 
2.4 방화벽 규칙 생성

[방화벽] > [개요] 




[설정] > [네트워크 규칙] > [+ 규칙 컬렉션 추가]

1. [규칙]의 상위 개념인 [규칙 컬렉션]을 먼저 생성하여야 합니다.([규칙 컬렉션]을 생성하지 않은 상태로 [+ Add rule]을 클릭하여 [규칙]을 생성할 수 없습니다.)2. 가장 상위 개념인 [규칙 컬렉션 그룹]의 경우, 기본값을 사용하거나 [설정] > [규칙 컬렉션] 탭에서 [+ Add] > [Rule collection group]을 클릭하여 신규로 생성할 수 있습니다.cf) 기본값은 다음과 같이 3개가 존재합니다.(DefaultDnatRuleCollectionGroup, DefaultNetworkRuleCollectionGroup, DefaultApplicationRuleCollectionGroup)3. [규칙 컬렉션 그룹], [규칙 컬렉션]은 모두 우선 순위를 가지며 [규칙]은 상위 개념들의 우선 순위를 따라갑니다.



[규칙 컬렉션] 및 [규칙]을 추가합니다.



이름 : rule-collection-nw # 규칙 컬렉션 이름 입력규칙 컬렉션 형식 : 네트워크 우선 순위 : 100 # 같은 [규칙 컬렉션] 내에서의 우선 순위를 의미함규칙 추가1. spoke1 대역에서 spoke 2 대역의 MySQL Flexible Server에 접근하기 위한 3306 포트 open(원본 : Spoke 1 대역, 대상 : Spoke 2 대역)2. spoke2 대역에서 spoke 1 대역으로 응답 보낼 수 있도록 하기 위한 3306 포트 open(원본 : Spoke 2 대역, 대상 : Spoke 1 대역)
 

[추가]를 클릭하여 [규칙 컬렉션] 및 [규칙]을 생성합니다.

 
2.5 가상 머신 생성
Spoke 1 대역에 배포될 가상 머신에 접근하거나 Azure Portal에 로그인하여 Private하게 구성된 리소스들을 조회하기 위한 VM을 생성합니다.

[기본 사항] 탭




리소스 그룹 : rg-hub-test # Hub 대역 리소스 그룹 선택가상 머신 이름 : vm-bastion-test   이미지 : Windows 11 Pro, version 22H2 - X64 Gen2 크기 : Standard_D4s_v5 - 4 vcpu, 16 GiB 메모리관리자 계정- 사용자 이름 : azureuser # 원하는 이름 사용- 암호인바운드 포트 선택 : RDP (3389)라이선싱 : 체크 박스 클릭
 

[네트워킹] 탭



가상 네트워크 : vnet-hub-test 선택서브넷 : snet-vm 선택공용 IP : pip-vm-bastion # [새로 만들기] 클릭하여 원하는 이름 입력
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역의 bastion용 [가상 머신]을 생성합니다.

 
2.6 Private DNS Zone 생성 
Spoke 2 대역에 배포될 Azure Database for MySQL Flexible Server (VNet Integration)를 Private DNS Zone과 통합하기 위하여 Hub 대역에 Private DNS Zone(private.mysql.database.azure.com)을 생성합니다. 

[기본 사항] 탭



리소스 그룹 : rg-hub-test 선택이름 : private.mysql.database.azure.com 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역에 [Private DNS Zone]을 생성합니다.

 
2.7 가상 네크워크 링크 생성 

[설정] > [가상 네트워크 링크] > [+ 추가]



링크 이름 : vnet-link-hub # 원하는 가상 네트워크 링크 이름 입력가상 네트워크 : vnet-hub-test # Hub 대역의 가상 네트워크 선택
 
3. Spoke 1 대역 구성 
3.1 리소스 그룹 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-01 # 원하는 리소스 그룹 이름 입력영역 : (Asia Pachific) Korea Central 
 

[태그] 탭




[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [리소스 그룹]을 생성합니다.

 
3.2 가상 네트워크 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-01가상 네트워크 이름 : vnet-spoke-01 # spoke 1용 가상 네트워크 이름 입력영역 : (Asia Pachific) Korea Central 
 

[IP 주소] 탭



주소 공간 : 10.20.0.0/26 # 가상 네트워크 대역 입력서브넷 : snet-vm 추가 # [+ 서브넷 추가] 버튼을 클릭하여 주소 범위와 크기 입력 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [가상 네트워크]를 생성합니다.

 
3.3 Hub - Spoke 1 간 VNet Peering 

vnet-spoke-01 > [설정] > [피어링] > [+ 추가]




Hub - Spoke 1 간 VNet Peering을 구성합니다.  




[추가] 버튼을 클릭하여 VNet Peering을 생성합니다. 



 
3.4 경로 테이블 생성
Spoke 1 VNet에서 Hub의 Azure Firewall을 통해 Spoke 2 VNet 내 Azure Database for MySQL - Flexible Server에 접근할 수 있도록 사용자 지정 경로를 생성 및 구성합니다. 

[기본] 탭



리소스 그룹 : rg-spoke-test-01 이름 : rt-spoke-01게이트웨이 경로 전파 : No # VPN 게이트웨이를 통해 온-프레미스 네트워크에 연결된 가상 네트워크의 서브넷에 경로 테이블을 연결하고 온-프레미스 경로를 서브넷의 네트워크 인터페이스에 전파하지 않으려는 경우 No 옵션 선택 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [경로 테이블]을 생성합니다. 

 
3.5 경로 테이블 구성 

경로 구성

rt-spoke-01 > [설정] > [경로] > [+ 추가]





경로 이름 : To-Spoke2 # Spoke 2 대역으로 가기 위해 사용자 지정 경로(UDR) 생성대상 IP 주소/CIDR 범위 : 10.30.0.0/24 # Spoke 2 대역 IP 주소 입력다음 홉 형식 : 가상 어플라이언스 # 방화벽을 거쳐서 Spoke 2 대역으로 이동다음 홉 주소 : # Azure Firewall의 Private IP 주소 입력
 

[추가] 버튼을 클릭하여 사용자 지정 경로를 생성합니다. 
서브넷 연결

rt-spoke-01 > [설정] > [서브넷] > [+ 연결]





가상 네트워크 : vnet-spoke-01 # spoke 1 대역의 VNet 선택서브넷 : snet-vm # 경로 테이블과 연결할 subnet 선택
 
3.6 가상 머신 생성  
Spoke 2 대역에 배포될 Azure Database for MySQL Flexible Server에 접근하기 위한 client VM을 생성합니다. 

[기본 사항] 탭




리소스 그룹 : rg-spoke-test-01 # Spoke 1 대역 리소스 그룹 선택가상 머신 이름 : vm-client-test   이미지 : Ubuntu Server 20.04 LTS - x64 Gen2크기 : Standard_D4s_v5 - 4 vcpu, 16 GiB 메모리관리자 계정- 인증 형식 : 암호- 사용자 이름 : azureuser # 원하는 이름 사용- 암호인바운드 포트 선택 : SSH (22)
 

[네트워킹] 탭



가상 네트워크 : vnet-spoke-01 선택서브넷 : snet-vm 선택공용 IP : 없음 # Hub 대역에 배포한 [가상 머신]을 통해 접속할 것이므로 공용 IP 불필요 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [가상 머신]을 생성합니다. 

 
3.7 가상 네크워크 링크 생성 

[설정] > [가상 네트워크 링크] > [+ 추가]



링크 이름 : vnet-link-spoke-01 # 원하는 가상 네트워크 링크 이름 입력가상 네트워크 : vnet-spoke-01 # Spoke 1 대역의 가상 네트워크 선택
 
4. Spoke 2 대역 구성 
4.1 리소스 그룹 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-02 # 원하는 리소스 그룹 이름 입력영역 : (Asia Pachific) Korea Central 
 

[태그] 탭




[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 2 대역의 [리소스 그룹]을 생성합니다. 

 
4.2 가상 네트워크 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-02가상 네트워크 이름 : vnet-spoke-02 # spoke 2용 가상 네트워크 이름 입력영역 : (Asia Pachific) Korea Central 
 

[IP 주소] 탭



주소 공간 : 10.30.0.0/24 # 가상 네트워크 대역 입력서브넷 : snet-mysql-delegated 추가 # [+ 서브넷 추가] 버튼을 클릭하여 주소 범위와 크기 입력 프라이빗 서브넷 사용 : 체크 X # 위임된 서브넷의 경우 DefaultOutboundConnectivity를 false로 설정해서는 안 됨 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 2 대역의 [가상 네트워크]를 생성합니다.

 
4.3 Hub - Spoke 2 간 VNet Peering 

vnet-spoke-02 > [설정] > [피어링] > [+ 추가]




Hub - Spoke 2 간 VNet Peering을 구성합니다.  




[추가] 버튼을 클릭하여 VNet Peering을 생성합니다. 



 
4.4 경로 테이블 생성
Spoke 1 대역의 가상 머신이 Azure Database for MySQL - Flexible Server에 접근할 때와 동일한 루트로 통신할 수 있도록 사용자 지정 경로를 구성합니다. 

[기본] 탭



리소스 그룹 : rg-spoke-test-02 이름 : rt-spoke-02게이트웨이 경로 전파 : No # VPN 게이트웨이를 통해 온-프레미스 네트워크에 연결된 가상 네트워크의 서브넷에 경로 테이블을 연결하고 온-프레미스 경로를 서브넷의 네트워크 인터페이스에 전파하지 않으려는 경우 No 옵션 선택 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 2 대역의 [경로 테이블]을 생성합니다. 

 
4.5 경로 테이블 구성 

경로 구성

rt-spoke-02 > [설정] > [경로] > [+ 추가]





경로 이름 : To-Spoke1 # Spoke 1 대역으로 가기 위해 사용자 지정 경로(UDR) 생성대상 IP 주소/CIDR 범위 : 10.20.0.0/26 # Spoke 1 대역 IP 주소 입력다음 홉 형식 : 가상 어플라이언스 # 방화벽을 거쳐서 Spoke 1 대역으로 이동다음 홉 주소 : # Azure Firewall의 Private IP 주소 입력
 

[추가] 버튼을 클릭하여 사용자 지정 경로를 생성합니다. 
서브넷 연결

rt-spoke-02 > [설정] > [서브넷] > [+ 연결]





가상 네트워크 : vnet-spoke-02 # spoke 2 대역의 VNet 선택서브넷 : snet-mysql-delegated # 경로 테이블과 연결할 subnet 선택
 
4.6 Azure Database for MySQL Flexible Server 생성 
VNet Integration?- 가상 네트워크 인프라를 통해서만 서버에 대해 액세스할 수 있도록 합니다. - Azure Database for MySQL - Flexible Server 전용으로 위임된 서브넷이 필요합니다. - 단일 VNet 또는 여러 VNet에 포함될 수 있습니다. 

[기본] 탭




리소스 그룹 : rg-spoke-test-02 # spoke 2 대역의 리소스 그룹 선택서버 이름 : db-mysql-flexible-test MySQL 버전 : 8.0 # 기본값 유지인증 방법 : MySQL 인증만- 관리자 사용자 이름 : sqladmin # 원하는 사용자 이름 입력- 암호
 

[네트워킹] 탭




네트워크 연결 - 연결 방법 : 프라이빗 액세스(VNet 통합)가상 네트워크 : vnet-spoke-02 # Azure Database for MySQL Flexible Server가 생성될 VNet 선택서브넷 : # 위임될 subnet 선택프라이빗 DNS 통합- 구독 : # Hub 대역이 있는 구독 선택- 프라이빗 DNS 영역 : # 기 생성한 프라이빗 DNS 영역 선택
 
4.7 가상 네크워크 링크 생성 

[설정] > [가상 네트워크 링크] > [+ 추가]



링크 이름 : vnet-link-spoke-02 # 원하는 가상 네트워크 링크 이름 입력가상 네트워크 : vnet-spoke-02 # Spoke 1 대역의 가상 네트워크 선택
 
5. 통신 테스트 
5.1 Network Watcher를 통한 Next Hop 확인 

[Network Watcher] > [네트워크 진단 도구] > [다음 홉] 



리소스 그룹 : rg-spoke-test-01 # Client용 가상 머신이 있는 Spoke 1 대역의 리소스 그룹 선택가상 머신 : vm-client-test 선택대상 IP 주소 : 10.30.0.4 # Azure Database for MySQL Flexible Server의 IP 주소 입력
 

[다음 홉] 버튼을 클릭하여 조회 시 [다음 홉 형식]은 VirtualAppliance, IP 주소는 방화벽의 Private IP 주소가 출력되는 것을 확인할 수 있습니다. 

 
5.2 Azure Firewall 진단 설정을 통한 방화벽 규칙 적용 확인

[방화벽] > [모니터링] > [진단 설정] > [+ 진단 설정 추가]




[진단 설정] 구성



진단 설정 이름 : Diagnostics-Setting-FW # 원하는 진단 설정 이름 입력범주 : Azure Firewall Network Rule # 현재 방화벽에 Network 규칙만 있으므로 관련된 범주만 선택대상 세부 정보- 스토리지 계정에 보관 # 방화벽 규칙에 의해 트래픽이 허용/거부되는지 확인을 위해 스토리지 계정에 로그 적재스토리지 계정 : # 없는 경우 먼저 생성 필요
 

[스토리지 계정] > [데이터 스토리지] > [컨테이너] > [insights-logs-azurefirewall] 컨테이너 클릭




조회하고자 하는 로그 파일을 다운로드합니다.



경로 : resourceId=/SUBSCRIPTIONS/{구독 id}/RESOURCEGROUPS/{Resource Group 명}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{Firewall 명}/년/월/일/시/분/PT1H.json
 

로그 세부 내용 확인



Action : 해당 트래픽의 허용 여부 Policy : 어떤 방화벽 정책을 사용하는지 RuleCollectionGroup : 트래픽을 허용/거부하는 [규칙]이 어떤 [규칙 컬렉션 그룹]에 속해 있는지RuleCollection : 트래픽을 허용/거부하는 [규칙]이 어떤 [규칙 컬렉션]에 속해 있는지Rule : 어떤 [규칙]에 의해 트래픽이 허용/거부되는지 
※ 방화벽 테스트를 위해 Spoke 2 대역에 [가상 머신]을 추가로 생성하였습니다. 
 
5.3 Spoke 1 대역 VM → Spoke 2 대역 MySQL Server 접근 테스트

Hub 대역의 Bastion용 [가상 머신]에 접속합니다. 




Spoke 1 대역의 Client용 [가상 머신]에 접속합니다. 




Spoke 2 대역의 MySQL Flexible Server 접근을 위한 MySQL Client를 설치합니다. (명령어 하기 박스 참고)

1. sudo apt-get update2. sudo apt-get install mysql-client (Y 입력)3. mysql -V # 입력 시 mysql Ver 8.0.35-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu)) 출력 

Azure Database for MySQL Flexible Server 접근 

[Azure Database for MySQL Flexible Server] > [설정] > [연결] > [브라우저에서 또는 로컬에서 연결] 클릭 후 명령어를 복사합니다. 






Spoke 1 대역의 [가상 머신]에서 해당 명령어를 입력하여 정상 접근을 확인합니다. 



 

RG
● Region

vNet
●  RG
●  Region
●  IP address prefixes
●  subnet

Subnet
●  IP address prefixes
●  NAT gateway

NIC
●  RG
●  vNet
●  Subnet
●  NSG

대규모 Azure 고객들 사이에서 흔한 시나리오는 온-프레미스 데이터 센터에서 후면 계층에 액세스할 수 있으면서도 인터넷에 노출된 2계층 애플리케이션을 제공해야 하는 경우입니다. 이 문서에서는 다음 요구 사항을 충족하는 2계층 환경을 배포하기 위해 경로 테이블, VPN Gateway, 네트워크 가상 어플라이언스를 사용하는 시나리오를 안내합니다.

웹 애플리케이션은 공용 인터넷에서만 액세스할 수 있어야 합니다.
애플리케이션을 호스팅하는 웹 서버는 백 엔드 애플리케이션 서버에 액세스할 수 있어야 합니다.
인터넷에서 웹 애플리케이션으로 이동하는 모든 트래픽은 방화벽 가상 어플라이언스를 통해야 합니다. 이 가상 어플라이언스는 인터넷 트래픽에 대해서만 사용됩니다.
애플리케이션 서버로 이동하는 모든 트래픽은 방화벽 가상 어플라이언스를 통과해야 합니다. 이 가상 어플라이언스는 백 엔드 서버에 액세스하고 VPN Gateway를 통해 온-프레미스 네트워크에서 들어오는 액세스에 사용됩니다.
관리자는 관리 목적으로 독점적으로 사용된 세 번째 방화벽 가상 어플라이언스를 사용하여 온-프레미스 컴퓨터에서 방화벽 가상 어플라이언스를 관리할 수 있어야 합니다.
이 예제는 DMZ 및 보호된 네트워크를 사용하는 표준 경계 네트워크(DMZ라고도 함) 시나리오입니다. NSG(네트워크 보안 그룹), 방화벽 가상 어플라이언스 또는 이 두 가지를 조합하여 Azure에서 이 시나리오를 구성할 수 있습니다.

다음 표에서는 NSG와 방화벽 가상 어플라이언스의 장단점을 보여 줍니다.


테이블 확장
Item 장점 단점
NSG 무료입니다.
Azure 역할 기반 액세스에 통합되었습니다.
Azure Resource Manager 템플릿에서 규칙을 만들 수 있는 기능. 대규모 환경에서 복잡성이 달라질 수 있습니다.
방화벽 데이터 평면을 완벽히 제어합니다.
방화벽 콘솔을 통해 중앙에서 관리합니다. 방화벽 어플라이언스의 비용이 듭니다.
Azure 역할 기반 액세스와 통합되지 않습니다.
다음 솔루션은 방화벽 가상 어플라이언스를 사용하여 경계 네트워크(DMZ)/보호된 네트워크 시나리오를 구현합니다.

고려 사항
현재 사용 가능한 기능을 사용하여 Azure에 이전 환경을 배포할 수 있습니다.

가상 네트워크: Azure 가상 네트워크는 온-프레미스 네트워크와 비슷한 방식으로 작동합니다. 트래픽을 격리하고 문제를 격리하기 위해 하나 이상의 서브넷으로 분할할 수 있습니다.
가상 어플라이언스: 여러 파트너가 이전에 설명한 세 개의 방화벽에 사용할 Azure Marketplace의 가상 어플라이언스를 제공합니다.
경로 테이블: 경로 테이블은 Azure 네트워킹에서 가상 네트워크 내의 패킷 흐름을 제어하는 데 사용됩니다. 이러한 경로 테이블을 서브넷에 적용할 수 있습니다. 하이브리드 연결에서 Azure 가상 네트워크로 들어오는 모든 트래픽을 가상 어플라이언스로 전달하는 경로 테이블을 GatewaySubnet에 적용할 수 있습니다.
IP 전달: 기본적으로 Azure 네트워킹 엔진은 패킷 대상 IP 주소가 NIC IP 주소와 일치하는 경우에만 가상 NIC(네트워크 인터페이스 카드)에 패킷을 전달합니다. 패킷을 특정 가상 어플라이언스로 보내야 한다고 경로 테이블에 정의된 경우 Azure 네트워킹 엔진은 해당 패킷을 삭제합니다. 패킷의 실제 대상이 아닌 VM(이 경우 가상 어플라이언스)에 패킷이 제공되도록 하려면 가상 어플라이언스에 대해 IP 전달을 사용하도록 설정해야 합니다.
네트워크 보안 그룹: 다음 예에서는 NSG를 사용하지 않지만 이 솔루션에서는 서브넷이나 NIC에 적용된 NSG를 사용할 수 있습니다. NSG는 해당 서브넷 및 NIC에서 유입 및 유출되는 트래픽을 추가로 필터링합니다.


이 예에서 구독에는 다음 항목이 포함됩니다.

두 개의 리소스 그룹(다이어그램에 표시되지 않음):

ONPREMRG: 온-프레미스 네트워크를 시뮬레이트하는 데 필요한 모든 리소스를 포함합니다.
AZURERG: Azure 가상 네트워크 환경에 필요한 모든 리소스를 포함합니다.
onpremvnet이라는 가상 네트워크가 분할되어 온-프레미스 데이터 센터를 모방하는 데 사용됩니다.

onpremsn1: 온-프레미스 서버를 모방하기 위해 Linux 배포판을 실행하는 VM(가상 머신)이 포함된 서브넷입니다.
onpremsn2: 관리자가 사용하는 온-프레미스 컴퓨터를 모방하기 위해 Linux 배포판을 실행하는 VM이 포함된 서브넷입니다.
onpremvnet에서 하나의 방화벽 가상 어플라이언스가 OPFW로 명명되었습니다. azurevnet에 대한 터널을 유지하는 데 사용됩니다.

azurevnet이라는 가상 네트워크는 다음과 같이 세분화됩니다.

azsn1: 외부 방화벽에 독점적으로 사용되는 외부 방화벽 서브넷입니다. 모든 인터넷 트래픽은 이 서브넷을 통해 들어옵니다. 이 서브넷에는 외부 방화벽에 연결된 NIC만 포함되어 있습니다.
azsn2: 인터넷에서 액세스하는 웹 서버로 실행되는 VM을 호스팅하는 프런트 엔드 서브넷입니다.
azsn3: 프런트 엔드 웹 서버에서 액세스하는 백 엔드 애플리케이션 서버를 실행하는 VM을 호스팅하는 백 엔드 서브넷입니다.
azsn4: 모든 방화벽 가상 어플라이언스에 대한 관리 액세스를 제공하는 데 독점적으로 사용되는 관리 서브넷입니다. 이 서브넷에는 솔루션에서 사용되는 각 방화벽 가상 어플라이언스에 대한 NIC만 포함되어 있습니다.
GatewaySubnet: Azure ExpressRoute와 Azure VPN Gateway가 Azure 가상 네트워크와 다른 네트워크 간의 연결을 제공하는 데 필요한 Azure 하이브리드 연결 서브넷입니다.
azurevnet 네트워크에 3개의 방화벽 가상 어플라이언스가 있습니다.

AZF1: Azure에서 공용 IP 주소 리소스를 사용하여 공용 인터넷에 노출되는 외부 방화벽입니다. Azure Marketplace 또는 어플라이언스 공급업체에서 직접 3개 NIC 가상 어플라이언스를 배포하는 템플릿이 있는지 확인해야 합니다.
AZF2: azsn2와 azsn3 사이의 트래픽을 제어하는 데 사용되는 내부 방화벽입니다. 이 방화벽도 3개의 NIC로 구성된 가상 어플라이언스입니다.
AZF3: 온-프레미스 데이터 센터에서 관리자가 액세스할 수 있고 모든 방화벽 어플라이언스를 관리하는 데 사용되는 관리 서브넷에 연결된 관리 방화벽입니다. Azure Marketplace에서 두 개의 NIC 가상 어플라이언스 템플릿을 찾을 수 있습니다. 어플라이언스 공급업체에 직접 요청할 수도 있습니다.
경로 테이블
Azure의 각 서브넷을 경로 테이블에 연결하여 해당 서브넷에서 시작된 트래픽이 라우팅되는 방식을 정의합니다. UDR(사용자 정의 경로)이 정의되지 않은 경우 Azure는 기본 경로를 사용하여 트래픽이 한 서브넷에서 다른 서브넷으로 흐르도록 허용합니다. 경로 테이블과 트래픽 라우팅을 더 잘 이해하려면 Azure 가상 네트워크 트래픽 라우팅을 참조하세요.

이전에 나열된 마지막 요구 사항에 따라 적절한 방화벽 어플라이언스를 통해 통신이 수행되도록 하려면 azurevnet에 다음 경로 테이블을 만들어야 합니다.

azgwudr
이 시나리오에서 온-프레미스에서 Azure로 흐르는 유일한 트래픽은 AZF3에 연결하여 방화벽을 관리하는 데 사용되며, 해당 트래픽은 내부 방화벽인 AZF2를 통과해야 합니다. GatewaySubnet에는 여기에 표시된 것처럼 하나의 경로만 필요합니다.


테이블 확장
대상 다음 홉 설명
10.0.4.0/24 10.0.3.11 온-프레미스 트래픽이 관리 방화벽 AZF3에 도달하도록 허용합니다.
azsn2udr

테이블 확장
대상 다음 홉 설명
10.0.3.0/24 10.0.2.11 AZF2를 통해 애플리케이션 서버를 호스팅하는 백 엔드 서브넷으로의 트래픽을 허용합니다.
0.0.0.0/0 10.0.2.10 다른 모든 트래픽이 AZF1을 통해 라우팅되도록 허용합니다.
azsn3udr

테이블 확장
대상 다음 홉 설명
10.0.2.0/24 10.0.3.10 azsn2에 대한 트래픽이 앱 서버에서 웹 서버로 AZF2를 통해 흐르도록 허용합니다.
또한 온-프레미스 데이터 센터를 모방하기 위해 onpremvnet의 서브넷에 대한 경로 테이블도 만들어야 합니다.

onpremsn1udr

테이블 확장
대상 다음 홉 설명
192.168.2.0/24 192.168.1.4 onpremsn2에서 OPFW까지의 트래픽을 허용합니다.
onpremsn2udr

테이블 확장
대상 다음 홉 설명
10.0.3.0/24 192.168.2.4 OPFW를 통해 Azure의 백 엔드 서브넷으로의 트래픽을 허용합니다.
192.168.1.0/24 192.168.2.4 onpremsn1에서 OPFW까지의 트래픽을 허용합니다.
IP 전달
경로 테이블 및 IP 전달은 가상 어플라이언스가 Azure 가상 네트워크의 트래픽 흐름을 제어하도록 허용하는 데 함께 사용할 수 있는 기능입니다. 가상 어플라이언스는 방화벽이나 네트워크 주소 변환 디바이스와 같이 네트워크 트래픽을 처리하는 데 사용되는 애플리케이션을 실행하는 VM일 뿐입니다.

이 가상 어플라이언스 VM은 주소가 자신으로 지정되지 않은 들어오는 트래픽을 받을 수 있어야 합니다. VM이 다른 대상으로 주소가 지정된 트래픽을 받을 수 있도록 하려면 해당 VM에서 IP 전달을 사용하도록 설정해야 합니다. 이 설정은 Azure 설정으로 게스트 운영 체제에서 설정할 수 없습니다. 가상 어플라이언스는 수신 트래픽을 처리하고 적절하게 라우팅하기 위해 일부 유형의 애플리케이션을 계속 실행해야 합니다.

IP 전달에 대한 자세한 내용은 Azure 가상 네트워크 트래픽 라우팅을 참조하세요.

예를 들어, Azure 가상 네트워크에 다음과 같은 설정이 있다고 가정해 보겠습니다.

서브넷 onpremsn1에 onpremvm1이라는 VM이 포함되어 있습니다.
서브넷 onpremsn2에 onpremvm2이라는 VM이 포함되어 있습니다.
OPFW라는 가상 어플라이언스가 onpremsn1 및 onpremsn2에 연결되어 있습니다.
onpremsn1에 연결된 UDR은 onpremsn2에 대한 모든 트래픽이 OPFW로 전송되어야 함을 지정합니다.
이 시점에서 onpremvm1이 onpremvm2와 연결을 설정하려고 하면 UDR이 사용되고 트래픽은 다음 홉으로 OPFW로 전송됩니다. 실제 패킷 대상은 변경되지 않습니다. 아직도 대상이 onpremvm2라고 나와있습니다.

OPFW에 대해 IP 전달을 사용하도록 설정하지 않으면 패킷의 대상이 VM의 IP 주소인 경우에만 패킷이 VM으로 전송되도록 허용하므로 Azure 가상 네트워킹 논리가 패킷을 삭제합니다.

IP 전달을 사용하면 Azure 가상 네트워크 논리가 원래 대상 주소를 변경하지 않고 OPFW에 패킷을 전달합니다. OPFW는 패킷을 처리하고 수행할 작업을 결정해야 합니다.

이전 시나리오가 작동하려면 라우팅에 사용되는 OPFW, AZF1, AZF2, AZF3의 NIC에서 IP 전달을 사용하도록 설정해야 합니다(관리 서브넷에 연결된 NIC를 제외한 모든 NIC).

방화벽 규칙
이전에 설명한 대로 IP 전달은 패킷이 가상 어플라이언스로 전송되는 것만 보장합니다. 어플라이언스는 여전히 해당 패킷으로 수행할 작업을 결정해야 합니다. 이전 시나리오에서는 어플라이언스에 다음 규칙을 만들어야 합니다.

onpremsn2
OPFW는 다음 규칙을 포함하는 온-프레미스 디바이스를 나타냅니다.

경로: 10.0.0.0/16(azurevnet)에 대한 모든 트래픽은 터널 ONPREMAZURE를 통해 전송되어야 합니다.
정책: port2와 ONPREMAZURE 사이의 양방향 트래픽을 모두 허용합니다.
AZF1
AZF1은 다음 규칙을 포함하는 Azure 가상 어플라이언스를 나타냅니다.

정책: port1와 port2 사이의 양방향 트래픽을 모두 허용합니다.

AZF2
AZF2은 다음 규칙을 포함하는 Azure 가상 어플라이언스를 나타냅니다.

정책: port1와 port2 사이의 양방향 트래픽을 모두 허용합니다.

AZF3
AZF3은 다음 규칙을 포함하는 Azure 가상 어플라이언스를 나타냅니다.

경로: 192.168.0.0/16(onpremvnet)에 대한 모든 트래픽은 port1을 통해 Azure 게이트웨이 IP 주소(즉, 10.0.0.1)로 전송되어야 합니다.

네트워크 보안 그룹
이 시나리오에서 NSG는 사용되지 않습니다. 그러나 각 서브넷에 NSG를 적용하여 수신 및 발신 트래픽을 제한할 수 있습니다. 예를 들어, 다음 NSG 규칙을 외부 방화벽 서브넷에 적용할 수 있습니다.

수신

서브넷의 모든 VM에서 포트 80에 대한 인터넷에서 오는 모든 TCP 트래픽을 허용합니다.
인터넷에서 오는 다른 모든 트래픽을 거부합니다.
발신

인터넷으로 가는 모든 트래픽을 거부합니다.

대략적인 단계
이 시나리오를 배포하려면 다음 단계를 따릅니다.

Azure 구독에 로그인합니다.

온-프레미스 네트워크를 가장하는 가상 네트워크를 배포하려는 경우 ONPREMRG에 포함된 리소스를 배포합니다.

AZURERG의 일부인 리소스를 배포합니다.

onpremvnet에서 azurevnet까지 터널을 배포합니다.

모든 리소스가 프로비전된 후 onpremvm2에 로그인하고 10.0.3.101에 ping을 보내 onpremsn2와 azsn3 사이의 연결을 테스트합니다.