깡민쓰~IT Story

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 사이의 연결을 테스트합니다.

프라이빗 엔드포인트는 가상 네트워크의 개인 IP 주소를 사용하는 네트워크 인터페이스입니다. 프라이빗 엔드포인트는 Azure Private Link에서 제공하는 서비스에 비공개로 안전하게 연결합니다. 프라이빗 엔드포인트를 사용하도록 설정하면 서비스를 가상 네트워크로 가져올 수 있습니다.

서비스는 다음과 같은 Azure 서비스일 수 있습니다.

• Azure Storage
• Azure Cosmos DB
• Azure SQL Database
• Private Link 서비스를 사용하는 자체 서비스입니다.

프라이빗 엔드포인트는 다음 속성을 지정합니다.

프라이빗 엔드포인트를 만들 때 다음을 고려합니다.

• 프라이빗 엔드포인트를 사용하면 동일한 고객 간에 연결이 가능합니다.
  • 가상 네트워크
  • 지역적으로 피어링된 가상 네트워크
  • 전역적으로 피어링된 가상 네트워크
  • VPN 또는 Express Route를 사용하는 온-프레미스 환경
  • Private Link에서 제공하는 서비스
• 네트워크 연결은 프라이빗 엔드포인트에 연결하는 클라이언트에서만 시작할 수 있습니다. 서비스 공급자는 서비스 고객에 대한 연결을 만들기 위한 라우팅 구성이 없습니다. 연결은 단일 방향으로만 설정할 수 있습니다.
• 프라이빗 엔드포인트의 수명 주기에 대해 읽기 전용 네트워크 인터페이스가 자동으로 만들어집니다. 이 인터페이스에는 프라이빗 링크 리소스에 매핑되는 서브넷의 동적 개인 IP 주소가 할당됩니다. 프라이빗 IP 주소의 값은 프라이빗 엔드포인트의 전체 수명 주기 동안 변경되지 않고 유지됩니다.
• 프라이빗 엔드포인트는 가상 네트워크와 동일한 지역 및 구독에 배포되어야 합니다.
• 프라이빗 링크 리소스는 가상 네트워크 및 프라이빗 엔드포인트의 지역이 아닌 다른 지역에 배포할 수 있습니다.
• 동일한 프라이빗 링크 리소스를 사용하여 여러 프라이빗 엔드포인트를 만들 수 있습니다. 일반적인 DNS 서버 구성을 사용하는 단일 네트워크의 경우 지정된 프라이빗 링크 리소스에 단일 프라이빗 엔드포인트를 사용하는 것이 좋습니다. DNS 확인 시 중복 항목 또는 충돌을 방지하려면 이 방법을 사용합니다.
• 동일한 가상 네트워크 내에서 동일하거나 다른 서브넷에 여러 프라이빗 엔드포인트를 만들 수 있습니다. 하나의 구독에서 만들 수 있는 프라이빗 엔드포인트 수는 제한됩니다. 자세한 내용은 Azure 제한을 참조하세요.
• 프라이빗 링크 리소스를 포함하는 구독은 Micosoft 네트워크 리소스 공급자에 등록해야 합니다. 프라이빗 엔드포인트를 포함하는 구독은 Micosoft 네트워크 리소스 공급자에도 등록해야 합니다. 자세한 내용은 Azure Resource Providers를 참조하세요.

프라이빗 링크 리소스는 지정된 프라이빗 엔드포인트의 대상입니다. 다음 표에는 프라이빗 엔드포인트를 지원하는 사용 가능한 리소스를 나와 있습니다.

프라이빗 엔드포인트를 사용하는 경우 트래픽은 프라이빗 링크 리소스로 보호됩니다. 플랫폼은 네트워크 연결의 유효성을 검사하여 지정된 프라이빗 링크 리소스에 도달하는 연결만 허용합니다. 동일한 Azure 서비스 내에서 더 많은 하위 리소스에 액세스하려면 해당 대상이 있는 더 많은 프라이빗 엔드포인트가 필요합니다. 예를 들어 Azure Storage 경우 파일 및 blob 하위 리소스에 액세스하려면 별도의 프라이빗 엔드포인트가 필요합니다.

프라이빗 엔드포인트는 Azure 서비스에 비공개로 액세스할 수 있는 IP 주소를 제공하지만 공용 네트워크 액세스를 반드시 제한하지는 않습니다. 그러나 다른 모든 Azure 서비스에는 추가 액세스 제어가 필요합니다. 이러한 컨트롤은 리소스에 추가 네트워크 보안 계층을 제공하여 프라이빗 링크 리소스와 연결된 Azure 서비스에 대한 액세스를 방지하는 데 도움이 되는 보호를 제공합니다.

프라이빗 엔드포인트는 네트워크 정책을 지원합니다. 네트워크 정책을 사용하면 NSG(네트워크 보안 그룹), UDR(사용자 정의 경로) 및 ASG(애플리케이션 보안 그룹)를 지원할 수 있습니다. 프라이빗 엔드포인트에 대한 네트워크 정책을 사용하도록 설정하는 방법에 대한 자세한 내용은 프라이빗 엔드포인트에 대한 네트워크 정책 관리를 참조하세요. 프라이빗 엔드포인트에서 ASG를 사용하려면 프라이빗 엔드포인트를 사용하여 ASG(애플리케이션 보안 그룹) 구성을 참조하세요.

다음 연결 승인 방법을 사용하여 프라이빗 링크 리소스에 연결할 수 있습니다.

• 자동 승인: 사용자가 특정 프라이빗 링크 리소스를 소유하거나 권한이 있는 경우 이 방법을 사용합니다. 필요한 권한은 다음 형식의 프라이빗 링크 리소스 종류를 기준으로 합니다.
• Microsoft.<Provider>/<resource_type>/privateEndpointConnectionsApproval/action
• 수동 요청: 필요한 사용 권한이 없고 액세스를 요청하려는 경우 이 방법을 사용합니다. 승인 워크플로가 시작됩니다. 프라이빗 엔드포인트와 이후의 프라이빗 엔드포인트 연결은 보류 중 상태로 만들어집니다. Private Link 리소스 소유자가 연결을 승인해야 합니다. 승인된 후 다음 승인 워크플로 다이어그램에 표시된 것처럼 프라이빗 엔드포인트가 트래픽을 정상적으로 보낼 수 있습니다.

프라이빗 엔드포인트 연결을 통해 프라이빗 링크 리소스 소유자는 다음을 수행할 수 있습니다.

• 모든 프라이빗 엔드포인트 연결 세부 정보를 검토합니다.
• 프라이빗 엔드포인트 연결을 승인합니다. 해당 프라이빗 엔드포인트는 트래픽을 프라이빗 링크 리소스로 보낼 수 있도록 사용하도록 설정됩니다.
• 프라이빗 엔드포인트 연결을 거부합니다. 해당 프라이빗 엔드포인트는 상태를 반영하도록 업데이트됩니다.
• 모든 상태의 프라이빗 엔드포인트 연결을 삭제합니다. 해당 프라이빗 엔드포인트는 작업을 반영하기 위해 연결이 끊긴 상태로 업데이트됩니다. 프라이빗 엔드포인트 소유자는 이 시점에서만 리소스를 삭제할 수 있습니다.

별칭은 서비스 소유자가 표준 부하 분산 장치 뒤에 프라이빗 링크 서비스를 만들 때 생성되는 고유한 모니커입니다. 서비스 소유자는 이 별칭을 서비스 소비자와 오프라인으로 공유할 수 있습니다.

소비자는 리소스 URI 또는 별칭을 사용하여 프라이빗 링크 서비스에 대한 연결을 요청할 수 있습니다. 별칭을 사용하여 연결하려면 수동 연결 승인 방법을 사용하여 프라이빗 엔드포인트를 만듭니다. 수동 연결 승인 방법을 사용하려면 프라이빗 엔드포인트 만들기 흐름에서 수동 요청 매개 변수를 True로 설정합니다. 자세한 내용은 New-AzPrivateEndpoint 및 az network private-endpoint create를 참조하세요.

프라이빗 링크 리소스에 연결하는 데 사용하는 DNS 설정이 중요합니다. 기존 Azure 서비스에는 공용 엔드포인트를 통해 연결할 때 사용할 DNS 구성이 이미 있을 수 있습니다. 프라이빗 엔드포인트를 통해 동일한 서비스에 연결하려면 프라이빗 DNS 영역을 통해 구성되는 별도의 DNS 설정이 필요합니다. 연결에 FQDN(정규화된 도메인 이름)을 사용하는 경우 DNS 설정이 올바른지 확인합니다. 프라이빗 엔드포인트의 개인 IP 주소를 확인하려면 DNS 구성을 변경합니다.

프라이빗 엔드포인트와 연결된 네트워크 인터페이스에는 DNS를 구성하는 데 필요한 정보가 포함되어 있습니다. 이 정보에는 프라이빗 링크 리소스에 대한 FQDN 및 개인 IP 주소가 포함됩니다.

프라이빗 엔드포인트에 대한 DNS 구성 권장 사항에 대한 자세한 내용은 프라이빗 엔드포인트 DNS 구성을 참조하세요.

다음 정보에는 프라이빗 엔드포인트 사용에 대한 알려진 제한 사항이 나와 있습니다.

• 프라이빗 엔드포인트에서 거부된 아웃바운드 트래픽은 서비스 공급자가 트래픽을 생성할 수 없기 때문에 유효한 시나리오가 아닙니다.
• 다음 서비스는 프라이빗 엔드포인트를 사용하고 NSG 보안 필터를 추가할 때 모든 대상 포트를 열어야 할 수 있습니다.
  • Azure Cosmos DB - 자세한 내용은 서비스 포트 범위를 참조하세요.

• 프라이빗 엔드포인트 및 Private Link에 대한 자세한 내용은 Azure Private Link란?을 참조하세요.
• 웹앱에 대한 프라이빗 엔드포인트 만들기를 시작하려면 빠른 시작: Azure Portal을 사용하여 프라이빗 엔드포인트 만들기를 참조하세요.

VNet(가상 네트워크) 서비스 엔드포인트는 Azure 백본 네트워크에서 최적화된 경로를 통해 Azure 서비스에 대한 안전한 직접 연결을 제공합니다. 엔드포인트를 사용하면 가상 네트워크에 대해 중요한 Azure 서비스 리소스를 보호할 수 있습니다. 서비스 엔드포인트를 통해 VNet의 개인 IP 주소는 VNet에 공용 IP 주소가 없어도 Azure 서비스의 엔드포인트에 연결할 수 있습니다.

서비스 엔드포인트는 다음 Azure 서비스 및 지역에서 제공됩니다. Microsoft.* 리소스는 괄호 안에 있습니다. 서비스에 대한 서비스 엔드포인트를 구성하는 동안 서브넷 쪽에서 이 리소스를 사용하도록 설정합니다.

일반 공급

• Azure Storage(Microsoft.Storage): 일반적으로 모든 Azure 지역에서 제공됩니다.
• Azure Storage 지역 간 서비스 엔드포인트(Microsoft.Storage.Global): 일반적으로 모든 Azure 지역에서 사용할 수 있습니다.
• Azure SQL Database(Microsoft.Sql): 일반적으로 모든 Azure 지역에서 제공됩니다.
• Azure Synapse Analytics(Microsoft.Sql): 일반적으로 모든 Azure 지역에서 전용 SQL 풀(이전의 SQL DW)에 대해 제공됩니다.
• Azure Database for PostgreSQL 서버(Microsoft.Sql): 일반적으로 데이터베이스 서비스를 사용할 수 있는 Azure 지역에 제공됩니다.
• Azure Database for MySQL 서버(Microsoft.Sql): 일반적으로 데이터베이스 서비스를 사용할 수 있는 Azure 지역에 제공됩니다.
• Azure Database for MariaDB(Microsoft.Sql): 일반적으로 데이터베이스 서비스를 사용할 수 있는 Azure 지역에 제공됩니다.
• Azure Cosmos DB(Microsoft.AzureCosmosDB): 일반적으로 모든 Azure 지역에서 제공됩니다.
• Azure Key Vault(Microsoft.KeyVault): 일반적으로 모든 Azure 지역에서 제공됩니다.
• Azure Service Bus(Microsoft.ServiceBus): 일반적으로 모든 Azure 지역에서 제공됩니다.
• Azure Event Hubs(Microsoft.EventHub): 일반적으로 모든 Azure 지역에서 제공됩니다.
• Azure App Service(Microsoft.Web): 일반적으로 App Service를 사용할 수 있는 모든 Azure 지역에서 제공됩니다.
• Azure Cognitive Services(Microsoft.CognitiveServices): 일반적으로 Azure AI 서비스를 사용할 수 있는 모든 Azure 지역에서 제공됩니다.

공개 미리 보기

• Azure Container Registry(Microsoft.ContainerRegistry): Azure Container Registry를 사용할 수 있는 제한된 Azure 지역에서 사용 가능한 미리 보기입니다.

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

서비스 엔드포인트는 다음과 같은 이점을 제공합니다.

• Azure 서비스 리소스의 보안 향상: VNet 프라이빗 주소 공간은 겹칠 수 있습니다. 겹치는 공간을 사용하여 VNet에서 발생하는 트래픽을 고유하게 식별할 수 없습니다. 서비스 엔드포인트는 VNet ID를 서비스로 확장하여 Azure 서비스 리소스를 가상 네트워크에 안전하게 연결합니다. 가상 네트워크에서 서비스 엔드포인트를 사용하면 가상 네트워크 규칙을 추가하여 가상 네트워크에 대한 Azure 서비스 리소스를 보호할 수 있습니다. 규칙을 추가하면 리소스에 대한 퍼블릭 인터넷 액세스가 완전히 제거되고 가상 네트워크의 트래픽만 허용하여 보안이 향상됩니다.
• Virtual Network의 Azure 서비스 트래픽에 대한 최적의 라우팅: 현재 온-프레미스 및/또는 가상 어플라이언스에 인터넷 트래픽을 강제하는 가상 네트워크의 모든 경로는 Azure 서비스 트래픽이 인터넷 트래픽과 동일한 경로를 사용하도록 강제할 수도 있습니다. 서비스 엔드포인트는 Azure 트래픽에 대한 최적의 라우팅을 제공합니다.
• 엔드포인트는 가상 네트워크의 서비스 트래픽을 직접 Microsoft Azure 백본 네트워크의 서비스로 항상 이동시킵니다. 트래픽을 Azure 백본 네트워크에 유지하면 서비스 트래픽에 영향을 주지 않고 강제 터널링을 통해 가상 네트워크의 아웃바운드 인터넷 트래픽을 계속 감사하고 모니터링할 수 있습니다. 사용자 정의 경로 및 강제 터널링에 대한 자세한 내용은 Azure 가상 네트워크 트래픽 라우팅을 참조하세요.
• 관리 오버 헤드를 덜 사용하여 간단히 설정: IP 방화벽을 통해 Azure 리소스를 보호하기 위해 가상 네트워크에서 예약된 공용 IP 주소가 더 이상 필요하지 않습니다. 서비스 엔드포인트를 설정하는 데 NAT(Network Address Translation) 또는 게이트웨이 디바이스가 필요하지 않습니다. 서브넷에서 단일 선택을 통해 서비스 엔드포인트를 구성할 수 있습니다. 엔드포인트를 유지하기 위한 추가 오버헤드가 없습니다.

• 이 기능은 Azure Resource Manager 배포 모델을 통해 배포된 가상 네트워크에만 사용할 수 있습니다.
• 엔드포인트는 Azure 가상 네트워크에서 구성된 서브넷에서 활성화됩니다. 온-프레미스 서비스에서 Azure 서비스로의 트래픽에 엔드포인트를 사용할 수 없습니다. 자세한 내용은 온-프레미스에서 Azure 서비스 액세스 보안 유지를 참조하세요.
• Azure SQL의 경우 서비스 엔드포인트는 가상 네트워크의 지역 내에서 Azure 서비스 트래픽에만 적용됩니다.
• Azure Data Lake Storage(ADLS) Gen 1의 경우 VNet 통합 기능은 동일한 지역 내의 가상 네트워크에서만 사용할 수 있습니다. ADLS Gen1에 대한 가상 네트워크 통합에서는 가상 네트워크와 Microsoft Entra ID 간에 가상 네트워크 서비스 엔드포인트 보안을 사용하여 액세스 토큰에서 추가 보안 클레임을 생성하게 됩니다. 그런 다음, 이러한 클레임을 사용하여 Data Lake Storage Gen1 계정에 대해 가상 네트워크를 인증하고 액세스를 허용합니다. 서비스 엔드포인트를 지원하는 서비스에 나열된 Microsoft.AzureActiveDirectory 태그는 ADLS Gen 1에 서비스 엔드포인트를 지원하는 데 사용됩니다. Microsoft Entra ID는 태생적으로 서비스 엔드포인트를 지원하지 않습니다. Azure Data Lake Store Gen1 VNet 통합에 대한 자세한 내용은 Azure Data Lake Storage Gen1 네트워크 보안을 참조하세요.
• 활성 VNet 규칙이 구성된 지원되는 각 서비스에 의해 가상 네트워크를 최대 200개의 서로 다른 구독 및 지역과 연결할 수 있습니다.

• 가상 네트워크 서비스 엔드포인트는 Azure 서비스에 가상 네트워크의 ID를 제공합니다. 가상 네트워크에서 서비스 엔드포인트를 사용하면 가상 네트워크 규칙을 추가하여 가상 네트워크에 대한 Azure 서비스 리소스를 보호할 수 있습니다.
• 현재 가상 네트워크의 Azure 서비스 트래픽은 공용 IP 주소를 원본 IP 주소로 사용합니다. 서비스 엔드포인트에서 서비스 트래픽은 가상 네트워크의 Azure 서비스에 액세스할 때 가상 네트워크 프라이빗 주소를 원본 IP 주소로 사용하도록 전환됩니다. 이 스위치를 사용하면 IP 방화벽에서 사용되는 예약된 공용 IP 주소가 필요 없이 서비스에 액세스할 수 있습니다.
•  참고
• 서비스 엔드포인트를 사용하면 서비스 트래픽에 대한 서브넷의 가상 머신 원본 IP 주소가 공용 IPv4 주소에서 프라이빗 IPv4 주소로 전환됩니다. Azure 공용 IP 주소를 사용하는 기존 Azure 서비스 방화벽 규칙은 더 이상 이 스위치에 작동하지 않습니다. 서비스 엔드포인트를 설정하기 전에 Azure 서비스 방화벽 규칙에서 이 스위치를 허용해야 합니다. 서비스 엔드포인트를 구성하는 동안 이 서브넷의 서비스 트래픽이 일시적으로 중단될 수도 있습니다.

기본적으로 가상 네트워크에 대해 보호된 Azure 서비스 리소스는 온-프레미스 네트워크에서 연결할 수 없습니다. 온-프레미스의 트래픽을 허용하려는 경우 온-프레미스 또는 ExpressRoute의 공용 IP 주소(일반적으로 NAT)도 허용해야 합니다. Azure 서비스 리소스에 대한 IP 방화벽 구성을 통해 해당 IP 주소를 추가할 수 있습니다.

ExpressRoute: 사내에서 Microsoft 피어링을 위해 ExpressRoute를 사용하는 경우 사용 중인 NAT IP 주소를 식별해야 합니다. NAT IP 주소는 고객이 제공하거나 서비스 공급자가 제공합니다. 서비스 리소스에 대한 액세스를 허용하려면 리소스 IP 방화벽 설정에서 이러한 공용 IP 주소를 허용해야 합니다. ExpressRoute Microsoft 피어링용 NAT에 대한 자세한 내용은 ExpressRoute NAT 요구 사항을 참조하세요.

• 가상 네트워크의 서브넷에서 서비스 엔드포인트를 구성합니다. 엔드포인트는 해당 서브넷 내에서 실행되는 모든 컴퓨팅 인스턴스를 사용합니다.
• 서브넷에 지원되는 모든 Azure 서비스(예: Azure Storage, Azure SQL Database)에 여러 개의 서비스 엔드포인트를 구성할 수 있습니다.
• Azure SQL Database의 경우 가상 네트워크는 Azure 서비스 리소스와 동일한 지역에 있어야 합니다. 다른 모든 서비스의 경우 모든 지역의 가상 네트워크에 대한 Azure 서비스 리소스를 보호할 수 있습니다.
• 엔드포인트가 구성된 가상 네트워크는 Azure 서비스 리소스와 동일하거나 다른 구독에 구성될 수 있습니다. 엔드포인트를 설정하고 Azure 서비스를 보호하는 데 필요한 사용 권한에 대한 자세한 내용은 프로비저닝을 참조하세요.
• 지원되는 서비스의 경우 서비스 엔드포인트를 사용하여 가상 네트워크에 대한 기존 또는 새로운 리소스를 보호할 수 있습니다.

• 서비스 엔드포인트를 사용하도록 설정한 후에 원본 IP 주소는 해당 서브넷의 서비스와 통신할 때 공용 IPv4 주소가 아닌 개인 IPv4 주소를 사용하도록 전환됩니다. 이 전환 중에 서비스에 대한 기존의 모든 오픈 TCP 연결이 닫힙니다. 서브넷의 서비스에 서비스 엔드포인트를 사용하거나 사용하지 않도록 설정하는 경우 중요한 작업이 실행되지 않아야 합니다. 또한 IP 주소를 전환한 후에 애플리케이션이 Azure 서비스에 자동으로 연결될 수 있어야 합니다.
• IP 주소 전환은 가상 네트워크의 서비스 트래픽에만 영향을 줍니다. 가상 머신에 할당된 공용 IPv4 주소 간에 주소가 지정된 다른 모든 트래픽에는 영향이 없습니다. Azure 서비스의 경우 Azure 공용 IP 주소를 사용하는 기존 방화벽 규칙이 있는 경우 이러한 규칙은 가상 네트워크 프라이빗 주소로 전환하는 동시에 작동이 중지됩니다.
• 서비스 엔드포인트에서 Azure 서비스의 DNS 항목은 현재 상태로 유지되고 Azure 서비스에 할당된 공용 IP 주소로 계속 사용됩니다.
• 서비스 엔드포인트의 NSG(네트워크 보안 그룹):
  • 기본적으로 NSG는 아웃바운드 인터넷 트래픽을 허용하고 VNet에서 Azure 서비스로의 트래픽도 허용합니다. 이 트래픽은 서비스 엔드포인트와 그대로 계속 작동합니다.
  • 모든 아웃바운드 인터넷 트래픽을 거부하고 특정 Azure 서비스에 대한 트래픽만 허용하려는 경우 NSG에서 서비스 태그를 사용하여 수행할 수 있습니다. NSG 규칙에서 대상으로 지원되는 Azure 서비스를 지정할 수 있습니다. 또한 Azure에서는 각 태그의 기반이 되는 IP 주소의 유지 관리도 제공합니다. 자세한 내용은 NSG의 Azure 서비스 태그를 참조하세요.

• 피어링되거나 연결된 여러 가상 네트워크: 하나의 가상 네트워크 또는 여러 가상 네트워크의 여러 서브넷에 대한 Azure 서비스를 보호하려면 각 서브넷에서 서비스 엔드포인트를 독립적으로 활성화하고 모든 서브넷에 대한 Azure 서비스 리소스를 보호할 수 있습니다.
• 가상 네트워크에서 Azure 서비스로 아웃바운드 트래픽 필터링: 가상 네트워크에서 Azure 서비스로 전송된 트래픽을 검사하거나 필터링하려는 경우 해당 가상 네트워크 내에서 네트워크 가상 어플라이언스를 배포할 수 있습니다. 네트워크 가상 어플라이언스를 배포한 서브넷에 서비스 엔드포인트를 적용하고 이 서브넷에 대한 Azure 서비스 리소스만을 보호할 수 있습니다. 네트워크 가상 어플라이언스 필터링을 사용하여 가상 네트워크에서 특정 Azure 리소스로의 Azure 서비스 액세스만을 제한하도록 하려는 경우 이 시나리오가 유용할 수 있습니다. 자세한 내용은 네트워크 가상 어플라이언스에서 송신을 참조하세요.
• 가상 네트워크에 직접 배포된 서비스에 대한 Azure 리소스 보호: 다양한 Azure 서비스를 가상 네트워크의 특정 서브넷에 직접 배포할 수 있습니다. 관리되는 서비스 서브넷에서 서비스 엔드포인트를 설정하여 관리되는 서비스 서브넷에 대한 Azure 서비스 리소스를 보호할 수 있습니다.
• Azure 가상 머신의 디스크 트래픽: 관리 디스크 및 비관리 디스크에 대한 가상 머신 디스크 트래픽은 Azure Storage의 서비스 엔드포인트 라우팅 변경의 영향을 받지 않습니다. 이 트래픽에는 탑재 및 탑재 해제뿐만 아니라 diskIO도 포함됩니다. 서비스 엔드포인트 및 Azure Storage 네트워크 규칙을 통해 REST 액세스를 네트워크를 선택하도록 페이지 Blob으로 제한할 수 있습니다.

서비스 엔드포인트를 특정 서비스에 구성하면 서비스 엔드포인트 경로가 다음 항목에 적용되는지 유효성을 검사합니다.

• 서비스 진단에서 모든 서비스 요청의 원본 IP 주소 유효성을 검사합니다. 서비스 엔드포인트에서 모든 새로운 요청은 요청의 원본 IP 주소를 가상 네트워크 개인 IP 주소로 표시하고 가상 네트워크에서 요청한 클라이언트에 할당됩니다. 엔드포인트가 없는 경우 주소는 Azure 공용 IP 주소입니다.
• 서브넷의 모든 네트워크 인터페이스에서 유효 경로를 볼 수 있습니다. 서비스에 대한 경로:
  • 각 서비스의 주소를 지정하는 구체적인 기본 경로를 표시합니다.
  • VirtualNetworkServiceEndpoint의 nextHopType이 있습니다.
  • 강제 터널링 경로에 비해 서비스에 대한 직접 연결이 더 효과적임을 나타냅니다.

가상 네트워크에 대한 쓰기 권한이 있는 사용자는 가상 네트워크에서 독립적으로 서비스 엔드포인트를 구성할 수 있습니다. VNet에 대한 Azure 서비스 리소스를 보호하려면 추가된 서브넷에 대한 Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action 권한이 사용자에게 있어야 합니다. 기본 제공 서비스 관리자 역할은 기본적으로 이 권한을 포함합니다. 사용자 지정 역할을 만들어 권한을 수정할 수 있습니다.

기본 제공 역할에 대한 자세한 내용은 Azure 기본 제공 역할을 참조하세요. 사용자 지정 역할에 특정 권한을 할당하는 방법에 대한 자세한 내용은 Azure 사용자 지정 역할을 참조하세요.

가상 네트워크 및 Azure 서비스 리소스가 동일한 구독이나 다른 구독에 있을 수 있습니다. Azure Storage 및 Azure Key Vault와 같은 특정 Azure 서비스(일부는 아님)는 다른 AD(Active Directory) 테넌트 간에 서비스 엔드포인트도 지원합니다. 즉, 가상 네트워크 및 Azure 서비스 리소스는 다른 AD(Active Directory) 테넌트에 있을 수 있습니다. 자세한 내용은 개별 서비스 설명서를 확인하세요.

서비스 엔드포인트 사용에 따른 추가 비용은 없습니다. Azure 서비스(Azure Storage, Azure SQL Database 등)의 현재 가격 책정 모델은 현재 상태로 적용됩니다.

가상 네트워크에서 서비스 엔드포인트의 총합에 제한이 없습니다.

특정 Azure 서비스(예: Azure Storage 계정)는 리소스 보안에 사용되는 서브넷의 수에 제한을 적용할 수 있습니다. 자세한 내용은 다음 단계 섹션에서 다양한 서비스의 설명서를 참조하세요.

VNet 서비스 엔드포인트 정책을 사용하면 Azure 서비스에 대한 가상 네트워크 트래픽을 필터링할 수 있습니다. 이 필터는 서비스 엔드포인트에 대한 특정 Azure 서비스 리소스만 허용합니다. 서비스 엔드포인트 정책은 Azure 서비스의 가상 네트워크 트래픽에 대한 세부적인 액세스 제어를 제공합니다. 자세한 내용은 가상 네트워크 서비스 엔드포인트 정책을 참조하세요.

FAQ는 가상 네트워크 서비스 엔드포인트 FAQ를 참조하세요.

• 가상 네트워크 서비스 엔드포인트 구성
• 가상 네트워크에 대한 Azure Storage 계정 보호
• 가상 네트워크에 대한 Azure SQL Database 계정 보호
• 가상 네트워크에 대한 Azure Synapse Analytics 보호
• 프라이빗 엔드포인트와 서비스 엔드포인트 비교
• Virtual Network 서비스 엔드포인트 정책
• Azure Resource Manager 템플릿

다음은 Azure에 Palo Alto의 VM-Series Virtual Appliance를 배포하면서 얻은 몇 가지 반작용을 요약한 것입니다. 이것은 가이드라기보다는 내가 취한 단계를 반영한 것이지만 아래 정보를 적절하다고 생각되는 대로 사용할 수 있습니다. 개략적으로 Azure에 디바이스를 배포한 다음, Azure의 VNet(Virtual Network)에서 트래픽을 적절하게 라우팅할 수 있도록 Palo Alto의 내부 "내장"을 구성해야 합니다. 설명된 단계는 Palo Alto VM-Series 어플라이언스의 8.0 및 8.1 버전 모두에 적용되어야 합니다.

또한 이 자습서에서는 스케일 아웃 아키텍처를 배포하려고 한다고 가정합니다. 이렇게 하면 단일 인스턴스가 푸시하려는 대역폭의 양에 압도되지 않도록 할 수 있습니다. 단일 인스턴스를 찾고 있는 경우에도 계속 따라갈 수 있습니다.

Azure에서 어플라이언스 배포Deploy the appliance in Azure

Virtual Palo Altos를 배포할 때 설명서에서는 Azure Marketplace(https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=Overview 에서 찾을 수 있음)를 통해 만드는 것을 권장합니다. 개인적으로, 나는 명명 규칙에 대한 많은 통제력이 없고, 규모를 위해 둘 이상의 어플라이언스를 배포 할 수 없으며, 가용성 집합을 지정할 수 없으며, 관리 디스크를 활용할 수 없기 때문에 이러한 방식으로 어플라이언스를 배포하는 것을 좋아하지 않습니다. 또한 31자보다 큰 암호를 지정하면 Palo Alto 디바이스가 Azure에 배포되지 않는다는 정말 이상한 오류를 발견했습니다. 이 경우 관리 디스크, 가용성 집합, 일관된 명명법, 적절한 VM 크기 조정을 활용하고 가장 중요한 것은 크기 조정을 위해 배포하려는 가상 인스턴스의 수를 정의할 수 있는 사용자 지정 ARM 템플릿을 작성했습니다.

참고: 이 문서에서는 Panorama를 사용하는 개념을 다루지 않지만, "단일 창"에서 각 스케일 아웃 인스턴스를 중앙에서 관리합니다. 아래에서는 노드를 수동으로 설정하여 작동시키는 방법에 대해 설명합니다. ARM 템플릿 배포 시 노드를 부트스트랩하기 위해 배포 후 Panorama에 조인하는 기본 구성 파일을 생성할 수 있습니다. 부트 스트랩 파일은이 템플릿에 통합 한 것이 아니지만 템플릿을 쉽게 수정할 수 있습니다.

위에서 언급했듯이 이 기사에서는 Palo Alto가 공유 디자인 모델로 간주하는 것을 다룹니다. 다음은 시각적으로 표시되는 것의 예입니다(이 문서 하단의 메모 섹션에 나열된 Palo Alto의 참조 아키텍처 문서에서 발췌).

Palo Alto의 Reference Architecture에 따른 공유 설계 모델

Microsoft에는 가상 어플라이언스 배포를 설명하는 참조 아키텍처 문서도 있으며, 이 문서는 다음에서 찾을 수 있습니다 https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/nva-ha

아래는 내가 사용하는 ARM 템플릿에 대한 링크입니다.

PaloAlto-HA.json

이 템플릿의 배포는 Azure Portal(portal.azure.com)로 이동하고, 리소스 만들기를 선택하고, Azure Marketplace에서 템플릿 배포를 입력하고, 만들기를 클릭하고, 편집기에서 고유한 템플릿 빌드를 선택하고, 코드를 편집기에 붙여넣어 수행할 수 있습니다.

또는 여기에서 이 버튼을 클릭할 수 있습니다.

다음은 템플릿에서 매개 변수가 의미하는 바에 대한 몇 가지 참고 사항입니다.

VM 크기: Palo Alto에 따라 권장되는 VM 크기는 DS3, DS4 또는 DS5여야 합니다. 이에 대한 설명서는 여기에서 찾을 수 있습니다.

PASku: 여기에서 Bring-Your-Own-License 또는 종량제 사용을 선택할 수 있습니다. 계획은 여기에 요약되어 있습니다 : https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=PlansAndPrice

PAVersion: 배포할 PanOS의 버전입니다.

PACount: 부하 분산 장치 뒤에 배포하고 배치하려는 가상 인스턴스의 수를 정의합니다.

VNetName: 만든 가상 네트워크의 이름입니다.

VNetRG: 가상 네트워크가 있는 리소스 그룹의 이름입니다. 이는 Palos를 배치하는 리소스 그룹과 동일할 수 있지만, 다른 리소스 그룹의 VNet을 참조하는 오류를 방지하기 위해 구성 가능한 필수 옵션입니다.

envPrefix: 생성되는 모든 리소스(로드 밸런서, 가상 머신, 공용 IP, NIC 등)는 이 명명 명명법을 사용합니다.

manPrivateIPPrefix, trustPrivateIPPrefix, untrustPrivateIPPrefix: 해당 서브넷 주소 범위입니다. 이는 범위의 처음 3옥텟 뒤에 마침표가 와야 합니다. 예: 10.5.6. 가 유효한 값입니다.

manPrivateIPFirst, trustPrivateIPFirst, untrustPrivateIPFirst: 지정된 서브넷에서 사용 가능한 첫 번째 IP 주소입니다. 예를 들어 서브넷이 10.4.255.0/24인 경우 첫 번째 사용 가능한 주소로 4를 지정해야 합니다.

사용자 이름: PanOS 웹 포털에 ssh 및 로그인하는 데 사용해야 하는 권한 있는 계정의 이름입니다.

* 암호: PanOS 웹 포털에 ssh 및 로그인하는 데 사용되는 권한 있는 계정의 암호입니다. Pan OS 제한으로 인해 31자 이하여야 합니다.

어플라이언스 구성

가상 어플라이언스가 배포되면 Trust/Untrust 인터페이스에서 연결을 활성화하도록 Palo Alto 디바이스 자체를 구성해야 합니다.

VM-Series 방화벽에서 라이센스를 활성화합니다.

BYOL 버전을 사용하는 경우 다음 단계를 수행합니다

1. 지원 계정을 만듭니다.
2. VM-Series 방화벽
   (인증 코드 포함)을 등록합니다.
3. 방화벽 웹 인터페이스에서 Device(디바이스) 탭 -> Licenses(라이선스)
   를 선택하고 Activate feature using authentication code(인증 코드를 사용하여 기능 활성화)를 선택합니다.
4. 지원
   포털에 등록한 용량 인증 코드를 입력합니다. 방화벽이 업데이트 서버(updates.paloaltonetworks.com)에 연결되고 라이센스가 다운로드
   되고 자동으로 재부팅됩니다. 그래도 문제가 해결되지 않으면 아래에서 장치의 인터페이스 구성을 계속하십시오.
5. 재부팅 후 웹 인터페이스에 다시 로그인하고 대시보드에서 다음을 확인합니다.
   1. 유효한 일련 번호가 Serial#에 표시됩니다.
      알 수 없음이라는 용어가 표시되면 장치에 라이선스가 부여되지 않았음을 의미합니다. 방화벽에서 트래픽 로그를 보려면
      유효한 용량 라이선스를 설치해야 합니다.
   2. VM 모드가 Microsoft Azure로 표시됩니다.

PAYG(Pay as you go) 버전을 사용하는 경우 다음 단계를 수행합니다

1. 지원 계정을 만듭니다.
2. AWS 및 Azure에서 VM 시리즈 방화벽
   의 사용량 기반 모델을 등록합니다(인증 코드 없음).

Untrust/Trust 인터페이스 구성

신뢰할 수 없는 인터페이스 구성

1. Network-> Interfaces ->Ethernet->를 선택하고 ethernet1/1에 대한 링크를 선택한 후 다음과 같이 구성합니다.
   1. 인터페이스 유형: Layer3(기본값).
   2. Config 탭에서 인터페이스를 Untrust-VR 라우터에 할당합니다.
   3. Config(구성) 탭에서 Security Zone(보안 영역) 드롭다운을 확장하고 New Zone(새 영역)을 선택합니다. Untrust(신뢰할 수 없음)라는 새 영역을 정의하고 OK(확인)를 클릭합니다.
2. 인터페이스에 하나의 IP 주소만 할당하려는 경우 IPv4 탭에서 DHCP Client(DHCP 클라이언트)를 선택합니다. 둘 이상의 IP 주소를 할당하려는 경우 고정을 선택하고 Azure Portal의 인터페이스에 할당된 기본 및 보조 IP 주소를 수동으로 입력합니다. 인터페이스의 개인 IP 주소는 Virtual Machines -> YOURPALOMACHINE -> Networking으로 이동하고 각 탭에 지정된 개인 IP 주소를 사용하여 찾을 수 있습니다.
   1. 참고: 가상 머신에 공용 IP 주소를 사용하지 마십시오. Azure는 트래픽을 개인 주소로 자동으로 DNAT하므로 UnTrust 인터페이스에 개인 IP 주소를 사용해야 합니다.
3. Automatically create default route to default gateway provided by server 확인란의 선택을 취소합니다.
   1. 참고: 이 옵션을 사용하지 않도록 설정하면 이 인터페이스에서 처리되는 트래픽이 VNet의 기본 게이트웨이로 직접 흐르지 않습니다.
4. 확인을 클릭합니다.

참고: 신뢰할 수 없는 인터페이스의 경우 템플릿이 배포하지 않으므로 Azure 환경 내에서 신뢰할 수 없는 서브넷 또는 개별 방화벽 인터페이스에 연결된 NSG가 있는지 확인합니다(추가할 수 있지만 이미 NSG가 있는 경우 덮어쓰지 않으려고 합니다). Azure Load Balancer의 설명서에 따라 인터넷에서 들어오는 트래픽을 허용하려면 NIC 또는 서브넷에 연결된 NSG가 필요합니다.

트러스트 인터페이스 구성

1. Network-> Interfaces ->Ethernet->을 선택하고 ethernet1/2에 대한 링크를 선택한 후 다음과 같이 구성합니다.
   1. 인터페이스 유형: Layer3(기본값).
   2. Config 탭에서 Trust-VR 라우터에 인터페이스를 할당합니다.
   3. Config(구성) 탭에서 Security Zone(보안 영역) 드롭다운을 확장하고 New Zone(새 영역)을 선택합니다. Trust(신뢰)라는 새 영역을 정의하고 OK(확인)를 클릭합니다.
2. 인터페이스에 하나의 IP 주소만 할당하려는 경우 IPv4 탭에서 DHCP Client(DHCP 클라이언트)를 선택합니다. 둘 이상의 IP 주소를 할당하려는 경우 고정을 선택하고 Azure Portal의 인터페이스에 할당된 기본 및 보조 IP 주소를 수동으로 입력합니다. 인터페이스의 개인 IP 주소는 Virtual Machines -> YOURPALOMACHINE -> Networking으로 이동하고 각 탭에 지정된 개인 IP 주소를 사용하여 찾을 수 있습니다.
   1. Automatically create default route to default gateway provided by server 확인란의 선택을 취소합니다.
      1. 참고: 이 옵션을 사용하지 않도록 설정하면 이 인터페이스에서 처리되는 트래픽이 VNet의 기본 게이트웨이로 직접 흐르지 않습니다.
3. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다. 인터페이스의 링크 상태가 작동 중인지 확인합니다(Palo Alto 사용자 인터페이스에서 인터페이스가 녹색으로 바뀌어야 함).

Static Routes(정적 경로 정의)

Palo Alto는 트래픽을 인터넷으로 라우팅하는 방법과 서브넷으로 트래픽을 라우팅하는 방법을 이해해야 합니다. 이 섹션에서 볼 수 있듯이 각 Azure Load Balancer에서 제출된 상태 프로브의 처리를 처리하는 데 도움이 되는 두 개의 별도 가상 라우터가 필요합니다.

새 Virtual Router 및 Static Route to the Internet(인터넷에 대한 고정 경로)을 생성합니다.

1. Network(네트워크) - > Virtual Router(가상 라우터)를 선택합니다.
2. 하단에서 추가를 클릭합니다.
3. 이름을 Untrust-VR로 설정합니다.
4. 고정 경로 선택 -> IPv4 -> 추가
5. 인터넷 트래픽을 송신하기 위한 고정 경로 생성
   1. 이름: 인터넷
   2. 대상: 0.0.0.0/0
   3. 인터페이스: 이더넷 1/1
   4. 다음 홉: IP 주소
   5. IP 주소: Untrust 인터페이스가 배포된 서브넷의 기본 게이트웨이 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰할 수 없는 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
6. 정적 경로를 생성하여 인터넷에서 신뢰할 수 있는 VR로 트래픽 이동
   1. 이름: 내부 경로
   2. 대상: vnet 주소 공간
   3. 인터페이스: 없음
   4. 다음 홉: 다음 VR
      1. 트러스트-VR
7. 확인을 클릭합니다.

Azure 서브넷에 대한 새 가상 라우터 및 고정 경로 만들기Create a new Virtual Router and Static Route to your Azure Subnets

1. Network(네트워크) - > Virtual Router(가상 라우터)를 선택합니다.
2. 하단에서 추가를 클릭합니다.
3. 이름을 Trust-VR로 설정합니다.
4. 고정 경로 선택 -> IPv4 -> 추가
5. 신뢰할 수 있는 인터페이스에서 Azure로 트래픽을 보내는 고정 경로 만들기Create a Static Route to send traffic to Azure from your trusted interface
   1. 이름: AzureVNet
   2. 대상: vnet 주소 공간
   3. 인터페이스: 이더넷 1/2
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 트러스트 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
6. Trust에서 수신된 인터넷 트래픽을 Untrust Virtual Router로 이동하기 위한 고정 경로 생성
   1. 이름: 인터넷
   2. 대상: 0.0.0.0/0
   3. 인터페이스: 없음
   4. 다음 홉: 다음 VR
      1. 언트러스트 VR
7. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

Azure Load Balancer에 대한 상태 프로브 구성Configure Health Probes for Azure Load Balancer

스케일 아웃 시나리오를 배포하는 경우 Azure Load Balancer의 IP 주소인 168.63.129.16에서 TCP 프로브를 승인해야 합니다. Azure 상태 프로브는 특정 IP 주소(168.63.129.16)에서 제공됩니다. 이 경우 로드 밸런서에 대한 응답을 다시 허용하기 위해 정적 경로가 필요합니다. 이 문서에서는 Azure Load Balancer가 Palo Alto 인스턴스가 정상인지 확인하기 위해 연결할 수 있도록 Trust 인터페이스에서 SSH를 엄격하게 구성합니다.

인터페이스에 대한 Palo Alto SSH 서비스 구성

먼저 인터페이스 관리 프로필을 생성해야 합니다

1. 네트워크 -> 네트워크 프로파일 -> Interface Mgmt를 선택합니다.
2. 버튼 왼쪽에서 추가를 클릭합니다.
3. 다음 구성을 사용합니다
   1. 이름: SSH-MP
   2. 관리 서비스: SSH
   3. 허용된 IP 주소: 168.63.129.16/32
4. 확인을 클릭합니다.

다음으로 Trust 인터페이스에 프로필을 할당해야 합니다

1. 네트워크 선택 -> 인터페이스 ->ethernet1/2에 대한 링크 선택
2. 고급 탭을 선택합니다.
3. 관리 프로필을 SSH-MP로 설정합니다.
4. 확인을 클릭합니다.

다음으로 Untrust 인터페이스에 프로필을 할당해야 합니다

1. 네트워크 선택 -> 인터페이스 ->ethernet1/1에 대한 링크 선택
2. 고급 탭을 선택합니다.
3. 관리 프로필을 SSH-MP로 설정합니다.
4. 확인을 클릭합니다.

신뢰할 수 없는 인터페이스에서 Azure Load Balancer 상태 프로브에 대한 정적 경로 만들기Create a static route for the Azure Load Balancer Health Probes on the Untrust Interface

다음으로, 0.0.0.0/0 규칙으로 인해 상태 프로브가 Untrust 인터페이스에서 빠져나가도록 지시해야 합니다.

1. 네트워크 -> 가상 라우터 -> Untrust-VR을 선택합니다.
2. 고정 경로 선택 -> IPv4 -> 추가
3. 다음 구성을 사용합니다
   1. 이름: AzureLBHealthProbe
   2. 대상: 168.63.129.16/32
   3. 인터페이스: 이더넷 1/1
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
4. 확인을 클릭합니다.

트러스트 인터페이스에서 Azure Load Balancer 상태 프로브에 대한 고정 경로 만들기Create a static route for the Azure Load Balancer Health Probes on the trust interface

다음으로, 0.0.0.0/0 규칙으로 인해 상태 프로브가 Trust 인터페이스에서 벗어나도록 지시해야 합니다.

1. Network(네트워크) -> Virtual Router(가상 라우터) - Trust(신뢰)> VR을 선택합니다.
2. 고정 경로 선택 -> IPv4 -> 추가
3. 다음 구성을 사용합니다
   1. 이름: AzureLBHealthProbe
   2. 대상: 168.63.129.16/32
   3. 인터페이스: 이더넷 1/2
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
4. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

인터넷으로 향하는 내부 트래픽에 대한 NAT 규칙 만들기

Untrust 인터페이스의 주소를 통해 인터넷으로 향하는 모든 이그레스 트래픽을 NAT해야 하므로 인터넷의 반환 트래픽은 디바이스의 Untrust 인터페이스를 통해 다시 들어옵니다.

1. Policies(정책) - > NAT로 이동합니다.
2. Add(추가)를 클릭합니다.
3. 일반 탭에서 다음 구성을 사용합니다
   1. 이름: UntrustToInternet
   2. 설명: 인터넷으로 향하는 모든 신뢰할 수 있는 트래픽을 신뢰할 수 없는 인터페이스로 NAT하는 규칙
4. Original Packet(원본 패킷) 탭에서 다음 구성을 사용합니다
   1. Source Zone(소스 영역): Add(추가)를 클릭하고 Trust(신뢰)를 선택합니다.
   2. 대상 영역: 신뢰할 수 없음
   3. 대상 인터페이스: 이더넷 1/1
   4. 서비스: 모두 확인
   5. Source Address(소스 주소): Add(추가)를 클릭하고 Trust zone의 Internal Address(내부 주소) 공간을 사용합니다.
   6. 대상 주소: 모두 선택
5. Translated Packet(변환된 패킷) 탭에서 다음 구성을 사용합니다
   1. 변환 유형: 동적 IP 및 포트
   2. 주소 유형: 인터페이스 주소
   3. 인터페이스: 이더넷 1/1
   4. IP 주소: 없음
   5. 대상 주소 변환 변환 유형: 없음
6. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

Palo Alto 어플라이언스 업데이트

기본적으로 Palo Alto는 8.0.X 시리즈에 8.0.0을 배포하고 8.1.X 시리즈에 8.1.0을 배포합니다. 이 경우 Palo Alto는 지원 사례를 지원하기 전에 어플라이언스를 해당 시리즈의 최신 버전으로 업그레이드할 것을 강력히 권장합니다.

이렇게 하려면 Device -> Dynamic Updates로 이동하여 왼쪽 하단의 Check Now를 클릭하고 사용 가능한 업데이트 목록에서 최신 빌드를 다운로드>.

참고: 업데이트 프로세스를 수행하려면 장치를 재부팅해야 하며 20분 정도 걸릴 수 있습니다.

요약

이 시점에서 작동하는 스케일 아웃 Palo Alto 배포가 있어야 합니다. 모든 것이 순조롭게 진행되었다면 관리 인터페이스에서 공용 IP를 제거하거나 최소한 원래 있는 단일 공용 IP 주소로 범위를 지정하는 것이 좋습니다. 여기로 이동하여 공용 IP 주소를 찾을 수 있습니다 https://jackstromberg.com/whats-my-ip-address/

참조

Azure에 VM-Series 배포에 대한 Palo Alto의 공식 문서 (이것을 찾는 데 시간이 오래 걸렸으며 정적 경로 설정 또는 어플라이언스 업데이트는 다루지 않음) : https://docs.paloaltonetworks.com/vm-series/8-1/vm-series-deployment/set-up-the-vm-series-firewall-on-azure/deploy-the-vm-series-firewall-on-azure-solution-template.html

Azure VM 크기 조정에 대한 Palo Alto의 공식 설명서: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClD7CAK

Azure의 VM-Series 아키텍처에 대한 설명서(PDF 복사본을 얻으려면 페이지 맨 위에 있는 작은 다운로드 단추를 클릭): https://www.paloaltonetworks.com/resources/guides/azure-architecture-guide

팔로알토 네트웍스 Visio & OmniGraffle 스텐실: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmAJCA0

Palo Alto에서 스케일 아웃 VM 시리즈 배포의 아키텍처를 간략하게 설명하는 깔끔한 비디오: https://www.paloaltonetworks.com/resources/videos/vm-series-in-azure

Palo Alto 배포의 예정된 VMSS 버전: PaloAltoNetworks/azure-autoscaling: VMSS를 사용하는 Azure 자동 크기 조정 솔루션(github.com)