이런 애저

Azure Resource Manager 배포 모드 (Deployment mode)

megapain — Sat, 25 Jun 2022 17:13:42 +0900

참고 자료

https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/deployment-modes

증분(Incremental) 모드 (기본 값)

- Template에 지정되지 않은 기존 리소스 : 변경없이 유지

- Template에 지정된 기존 리소스 : 새 속성값으로 업데이트

전체(Complete) 모드

- Template에 지정되지 않은 기존 리소스 : 삭제

- Template에 지정된 기존 리소스 : 새 속성값으로 업데이트

예제

Resource Group contains:

Resource A
Resource B
Resource C

Template contains:

Resource A
Resource B
Resource D

When deployed in incremental mode, the resource group has:

Resource A
Resource B
Resource C
Resource D

When deployed in complete mode, Resource C is deleted. The resource group has:

Resource A
Resource B
Resource D

Important
When redeploying an existing resource in incremental mode, all properties are reapplied.
The properties aren't incrementally added.
A common misunderstanding is to think properties that aren't specified in the template are left unchanged.
If you don't specify certain properties, Resource Manager interprets the deployment as overwriting those values.
Properties that aren't included in the template are reset to the default values.
Specify all non-default values for the resource, not just the ones you're updating.
The resource definition in the template always contains the final state of the resource.
It can't represent a partial update to an existing resource.

Azure Windows VM Serial Console 접속 문제 해결 방법

megapain — Wed, 22 Jun 2022 21:59:25 +0900

온프레미스에서 Azure로 마이그레이션한 Windows VM에 Serial console로 접속하려고 시도해보면 아래와 같은 증상이 발생할 수도 있습니다.

Case 1. Microsoft Azure VM Health Report가 표시됨

Case 2. "Connected to the serial port of the VM. If no login prompt is displayed, press ENTER."라고 나오지만, 엔터를 쳐도 login prompt가 표시되지 않음.

원인

2018년 2월 이전에 생성된 Windows Server 이미지는 수동으로 Serial console을 활성화해야 합니다.

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-windows#enable-the-serial-console-in-custom-or-older-images

해결 방법

아래 doc에 해결 방법이 나옵니다.

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-windows#enable-the-serial-console-in-custom-or-older-images

1. Run command 에서 EnableEMS를 실행합니다.

2. EnableEMS 실행이 완료되면 VM을 재시작합니다.

VM이 재시작된 후 Serial Console로 연결해보면 아래와 같이 정상적으로 연결됩니다.

참고로, SAC(Special Administration Console)에서 사용할 수 있는 예제 명령어들을 아래 doc에서 확인하실 수 있습니다.

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-cmd-ps-commands

Azure VPN Gateway를 통한 Spoke Network 간의 연결

megapain — Wed, 8 Jun 2022 23:26:33 +0900

지난 글에서 Windows RRAS를 사용한 VPN 연결 방법에 대해서 설명했었습니다.

https://mpain.tistory.com/238

지난 번의 구성을 확장해서 Hub & Spoke 구조를 만들어 보겠습니다.

구성도는 아래와 같습니다.

Hub & Spoke

Hub-VNET을 중심으로 온프레미스, Prd-VNET, Dev-VNET이 연결되어 있으며, 각 네트워크 간의 통신은 Hub-VNET을 통해 연결됩니다. 일반적인 Hub & Spoke 네트워크 구조입니다.

Hub-VNET과 온프레미스 네트워크는 S2S VPN으로 연결되며, Hub-VNET과 Prd-VNET, Dev-VNET은 Peering으로 연결됩니다.

Peering 구성 옵션에서 VPN Gateway transit을 사용하여 온프레미스와 Azure Virtual Network 간의 통신이 가능해집니다.

* 참고
Configure VPN gateway transit for virtual network peering - https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit

Peering의 VPN Gateway transit 옵션

Peering의 VPN Gateway transit 옵션때문에 온프레미스 네트워크와 Azure Virtual Network 가 아래와 같이 서로 통신할 수 있습니다.

VPN Gateway transit을 통한 온프레미스 네트워크와 Azure Virtual Network 연결

Azure를 경험해보신 분들은 위의 네트워크 연결에 대해서는 대부분 잘 알고 계십니다.

그렇다면, Azure Virtual Network 간의 통신도 VPN Gateway transit을 사용해서 서로 연결될까요?

예를 들어, Prd-VNET의 Prd-web01과 Dev-VNET의 dev-web01이 Hub Network의 VPN Gateway transit을 사용해서 서로 연결될 수 있을까요? 이 질문에 대한 답이 이번 글의 핵심입니다.

기본적으로는 연결이 안됩니다.

(의외로 연결이 될거라고 생각하시는 분들이 많습니다.)

위와 같은 구성에서 prd-web01과 dev-web01간에 통신을 시도해보면 아래와 같이 연결이 안됩니다.

(테스트의 편의를 위해 Windows Firewall은 중지하십시오.)

기본적으로 VPN Gateway transit은, Hub 네트워크에 Peering된 Azure Virtual Network(Spoke 네트워크)와 온프레미스 네트워크 간의 통신에서만 동작합니다.

Azure Virtual Network 간에도 VPN Gateway transit을 사용해서 통신하기 위해서는 UDR(User Define Route)을 사용해서 명시적으로 라우팅을 구성해 주어야 합니다.

예를 들어, 테스트 구성에서는 아래와 같이 UDR을 구성해야 합니다.

VPN Gateway transit을 위한 UDR

UDR을 구성할 때,

Address prefix destination에는 상대방 Virtual network의 IP 주소 대역을 입력하고,

Next hop type은 Virtual network gateway를 선택합니다.

UDR - Route 예제

이렇게 만들어진 UDR을 서브넷에 연결해야 합니다.

예제에서는 아래와 같이 두개의 UDR을 만들고 각각의 서브넷에 연결했습니다.

테스트에서 사용된 UDR

위와 같이 UDR을 적용하고 난 후 다시 Azure Spoke 네트워크 VM 간의 통신을 테스트해보면,

아래와 같이 정상적으로 통신이 되는 것을 확인할 수 있습니다.

UDR 적용 전 후 비교

추가로, Azure Spoke 네트워크 간의 통신은 Azure Firewall이나 3rd party NVA(Network Virtual Appliance)를 사용하여 라우팅을 처리할 수도 있습니다.

Azure Firewall 또는 NVA를 통한 Spoke 네트워크 간 라우팅

위 구성에 대한 내용은 아래 글에서 설명하고 있습니다.

https://mpain.tistory.com/216

Azure Firewall - 라우팅, DNAT, 네트워크 규칙(Network rule)

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

mpain.tistory.com

-끝-

Windows RRAS를 사용하여 Azure VPN Gateway와 S2S VPN 연결

megapain — Sat, 4 Jun 2022 23:24:40 +0900

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

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

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

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

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

RRAS 테스트 구성도

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

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

*중요
Microsoft는 Azure 의 Windows Server 가상 머신에서의 RRAS 사용을 공식적으로는 지원하지 않습니다.

https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

따라서, Azure에서는 테스트 용도로만 RRAS를 사용해야 합니다.
Azure에서 RRAS를 사용하다가 문제가 생기더라도 Microsoft로부터 지원을 받을 수 없습니다.

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

1. 가상 네트워크 구성

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

Onprem-NW	Hub-VNET
Address spaces : 192.168.0.0/16 - RRAS-Subnet : 192.168.100.0/24 - DMZ-Subnet : 192.168.200.0/24	Address spaces : 172.16.0.0/16 - GatewaySubnet : 172.16.0.0/26 - Mgmt-Subnet : 172.16.1.0/24

2. VPN Gateway 생성

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

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

VPN Gateway 생성

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

3. RRAS용 Windows VM 생성

Windows Server 2019 VM을 생성합니다.

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

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

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

Virtual network : OnPrem-NW
Subnet : RRAS-Subnet

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

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

RRAS VM

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

RRAS 첫 번째 NIC

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

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

RRAS 두 번째 NIC

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

RRAS 두 번째 NIC - IP forwarding Enabled

RRAS VM을 시작합니다.

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

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

Windows Firewall Turn off

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

RRAS-Subnet의 NSG

5. VPN Gateway 설정

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

Local Network Gateway를 생성할 때,

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

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

Local network gateway

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

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

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

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

6. RRAS 역할 설치

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

Server Manager - Add Roles and Features

Server Manager

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

Server Roles - Remote Access

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

Role Services - DirectAccess and VPN (RAS), Routing

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

7. RRAS 구성

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

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

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

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

Configure and Enable Routing and Remote Access

Routing and Remote Access Server Setup Wizard

[Next]

Configuration

'Secure connection between two private networks'
[Next]

Demand-Dial Connections

'No'
[Next]

Completing the Routing and Remote Access Server Setup Wizard

[Finish]

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

Demand-Dial Interface Wizard

[Next]

Interface Name

Interface name : AzureVPNGW
[Next]

Interface name

Connection Type

Connect using virtual private networking(VPN)
[Next]

Connection Type - Connect using virtual private networking (VPN)

VPN Type

IKEv2
[Next]

VPN Type - IKEv2

Destination Address

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

Protocols and Security

Route IP packets on this interface
[Next]

Static Routes for Remote Networks

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

Azure IP 대역 등록

Dial-Out Credentials

[Next]

Completing the Demand-Dial Interface Wizard

[Finish]

*Preshared key를 지정합니다.

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

[Security] 탭

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

Preshared key 등록

*Azure VPN Gateway와 연결합니다.

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

Connect

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

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

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

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

8. 테스트용 VM 생성

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

(dmz-svr01, mgmt-vm)

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

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

*이 부분도 중요합니다.

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

Routes에서

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

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

UDR

10. 네트워크 통신 테스트

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

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

Application Gateway - 502 Bad Gateway

megapain — Thu, 20 Jan 2022 23:34:05 +0900

[증상]

Application Gateway 구성 후 브라우저에서 접근하면 아래와 같이 502 Bad Gateway 오류가 발생하는 경우가 있습니다.

또, Application Gateway의 Overview에

"All the instances in one or more of your backend pools are unhealthy. This will result in a 502 error when you try to access your application hosted behind the Application Gateway. Please check the backend health and resolve the issue." 라고 표시되고,

Backend health의 Status가 Unhealthy로 표시되고, Details에

"Time taken by the backend to respond to application gateway's health probe is more than the time-out threshold in the probe configuration. Either increase the time-out threshold in the probe configuration or resolve the backend issues. Note: for default probe, the http timeout is 30s. To learn more visit - https://aka.ms/ProbeTimeOut." 라고 표시됩니다.

[원인]

이 문제는 Application Gateway에서 Backend server로 Health probe 요청을 보낸 후 지정된 시간 안에 응답을 받지 못한 경우 발생합니다. (Application Gateway에서 Backend server로 Health probe 상태 체크가 안되는 경우라고 볼 수 있습니다.)

https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-backend-health-troubleshooting#backend-server-timeout

보통 Backend Server의 NSG Inbound 규칙에 All deny 규칙이 적용되어 있는 경우에 이와 같은 증상이 발생합니다.

[해결 방법]

NSG Inbound 규칙에 Application Gateway의 Subnet 대역에서 Backend Server의 IP 주소 (또는 Subnet 대역)로 허용하는 규칙을 설정합니다.

예를 들어 Backend Server에서 HTTP (TCP 80)을 서비스한다면, 아래와 같이 NSG Inbound 규칙을 설정합니다.

Source	Destination	Protocol	Port
ApplicationGateway Subnet CIDR range	Backend Server IP Addresses	TCP	80

위와 같이 NSG 규칙을 설정했는데도 여전히 동일한 문제가 발생한다면 Custom Health probe를 설정해야 할 수도 있습니다.

Backend Server의 Web Server 설정에서 host name을 지정했는지 확인해봅니다.

예를 들어, Backend Server가 Windows IIS라면 아래와 같이 Host Name을 지정했을 수도 있습니다.

Backend Server에서 host name이 지정되었다면 Custom Health probe를 추가해 주어야 합니다.

Custom Health probe를 추가할 때, Host에 Backend Server에서 지정한 host name을 입력하고, Http Settings에서 대상 HTTP settings를 선택합니다. Health probe가 체크할 Path도 올바르게 지정합니다.

[Test]를 클릭하여 Health probe가 정상적으로 동작하는지 확인해 볼 수 있습니다.

Health probe가 정상적으로 동작한다면 Backend health에서 Status가 Healthy로 표시되고,

Application Gateway를 통해 Backend Server로 정상적으로 접속됩니다.

-끝-

Azure Firewall 삭제 오류 해결 방법

megapain — Mon, 27 Dec 2021 19:49:49 +0900

Azure Firewall을 삭제할 때 아래와 같은 오류가 발생할 수 있습니다.

Azure Firewall 'firewall_name' failed to dereference Firewall Policy

Azure Firewall Policy를 삭제하려고 하면 아래와 같은 오류가 발생할 수 있습니다.

Firewall Policy 'policy_name' can not be deleted since there are Azure Firewalls using this policy.

위와 같은 오류가 발생한다면,

Set-AzFirewall 명령을 한번 실행해 준 후 다시 Azure Firewall을 삭제해 보십시오.

Set-AzFirewall -ResourceGroupName resourceGroupName -Name firewallName

Azure Firewall - Azure Site Recovery 용 허용 URL 정보

megapain — Wed, 15 Dec 2021 21:51:16 +0900

Azure Site Recovery를 사용하여 Azure VM을 다른 지역으로 복제를 구성해서 사용하던 중에 Azure Firewall을 도입하게 되면, Recovery Service Vault의 Site Recovery events에 아래의 오류 로그들이 기록됩니다.

Event Name	Event Type	Error ID	Error Message
No Mobility Service heartbeat	VmHealth	153000	Site recovery mobility service heartbeat not updated in last 15 minutes.
Recent crash consistent recovery point not available	VmHealth	153007	No crach consistent recovery point available for the VM in the last 60 miniutes.
Recent app-consistent recovery point not available	VmHealth	153006	No app-consistent recovery point available for the VM in the last xx miniutes.

제 경우, 위 오류들은 VM과 Azure Site Recovery 간 통신이 Azure Firewall에 의해 차단되었기 때문에 발생했습니다.

해결 방법은 Azure Firewall의 Application Rule에 아래 URL들을 Destination으로 등록하고 Https:443을 허용해주면 됩니다.

login.microsoftonline.com
*.blob.core.windows.net
*.hypervrecoverymanager.windowsazure.com
*.servicebus.windows.net
*.vault.azure.net
*.automation.ext.azure.com

보다 상세한 내용은 아래 doc를 참고하시기 바랍니다.

https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-about-networking#outbound-connectivity-for-urls

만약 Azure Firewall 때문에 VM과 Azure Site Recovery 간 통신이 오래동안 차단되어 있었다면, VM의 Azure Site Recovery Agent(Mobility service)의 버전을 업데이트 해 주어야 할 수도 있습니다.

Recovery Service Vault의 Site Recovery jobs에서 Filter를 클릭하고 검색 기간을 최대 90일 전으로 지정한 후 검색하여

가장 최근의 Update Mobility Service가 Failed인 job을 선택합니다.

Restart를 클릭합니다.

Azure Site Recovery Agent의 업데이트가 정상적으로 완료되는지 확인합니다.

VM과 Azure Site Recovery 간 통신이 정상이라면 복제가 자동으로 시작됩니다.

만약 Replication policy에서 App-consistent snapshot 이 설정되어 있다면, 복제가 완료된 후 App-consistent Recovery point가 생성되기까지 몇 시간이 소요될 수 있습니다. Crash consistent recovery point는 5분마다 생성되지만, App-consistent recovery point가 생성되지 않아서 복제 상태(Replication health)가 Critical로 표시될 수도 있습니다.

이 경우는 시간이 지나면 해결 될 수도 있으니 최대 하루 정도는 기다려 보시는 것이 좋을 것 같습니다.

*참고

NSG의 Outbound Rule에서 Azure Site Recovery에 대해 허용해 주어야 할 Service Tag에 대한 정보는 아래 doc에 나와 있습니다.

https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-about-networking#outbound-connectivity-using-service-tags

특정 Container의 모든 blob의 Access Tier (Archive)를 변경하는 PowerShell

megapain — Wed, 18 Aug 2021 14:07:51 +0900

참고 자료

Manage the access tier of a blob in an Azure Storage account - https://docs.microsoft.com/en-us/azure/storage/blobs/manage-access-tier?tabs=powershell

Azure Storage account에 Blob을 저장하는 경우, Hot, Cool, Archive라는 Access Tier에 저장됩니다.

Strorage account를 생성 할 때에는 기본 Tier로 Hot 또는 Cool 만 지정할 수 있으며 Archive Tier는 지정할 수 없습니다.

Storage account Access tier

Blob을 Archive Tier로 옮기기 위해서는 아래의 방법들을 사용할 수 있습니다.

Azure Storage account의 Lifecycle management를 사용하여 일정 기간이 지난 blob들을 자동으로 Archive Tier로 이동
Azure 포털에서 개별 blob을 선택하여 Archive Tier로 이동
Azure Powershell을 사용하여 개별 blob을 Archive Tier로 이동

아래는 Storage의 특정 Container의 모든 blob의 Tier를 Archive Tier로 변경하는 PowerShell Script 입니다.

# Define storage account information 
$StorageAccount = 'storageaccountname' 
$StorageAccountKey = 'storageAccountAccessKey' 
$containername = 'containername' 

# Create a storage context 
$context = New-AzStorageContext -StorageAccountName $StorageAccount -StorageAccountKey $StorageAccountKey 

# Get the blobs 
$blobs = Get-AzStorageBlob -Container $containername -Context $context 

Foreach ($blob in $blobs) { 
	$blob.ICloudBlob.SetStandardBlobTier("Archive") 
}

실행 결과

Access tier가 Archive로 변경되었습니다.

Application Gateway Stop/Start PowerShell

megapain — Wed, 18 Aug 2021 13:44:55 +0900

참고 자료

Stop-AzApplicationGateway - https://docs.microsoft.com/ko-kr/powershell/module/az.network/stop-azapplicationgateway?view=azps-6.3.0&viewFallbackFrom=azps-3.8.0

Azure Application Gateway를 중지/시작하는 PowerShell입니다.

Application Gateway를 테스트하는 동안 비용을 줄이기 위해 Application Gateway를 중지할 수 있습니다.

$rgName = 'ResourceGroupName' 
$appgwName = 'ApplicationGatewayName' 
$AppGW = Get-AzApplicationGateway -ResourceGroupName $rgName -Name $appgwName 

# Stop Application Gateway
Stop-AzApplicationGateway -ApplicationGateway $AppGw

# Start Application Gateway
Start-AzApplicationGateway -ApplicationGateway $AppGw

Application Gateway 중지(Stop) 예제

Application Gateway - X-Forwarded-For 헤더에서 Port 정보 제거

megapain — Sat, 7 Aug 2021 17:47:58 +0900

참고 자료

Remove port information from X-Forwarded-For header - https://docs.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url#remove-port-information-from-the-x-forwarded-for-header

개요
Azure Application Gateway는 클라이언트 요청을 백엔드로 전달하기 전에 모든 요청에 X-Forwarded-For 헤더를 삽입합니다. 이 헤더는 쉼표로 구분된 IP:port 목록입니다.
경우에 따라서는 백엔드 서버에 IP 주소만 필요한 시나리오가 있을 수 있습니다. 헤더 재작성(rewrite header)을 사용하여 X-Forwarded-For 헤더에서 Port 정보를 제거할 수 있습니다.

Azure Application Gateway의 Rewrite 기능을 사용하여 X-Forwarded-For 헤더에서 Port를 제거하는 방법을 설명합니다.

테스트 구성도
Application Gateway의 Backend에 Windows Server 2019 VM이 연결되어 있습니다.
Windows Server 2019에는 IIS 역할이 설치되어 있습니다.

사전 준비
Windows VM에 IIS 역할이 설치되어 있어야 합니다. (테스트에서는 기본값으로 설치했습니다.)
Application Gateway의 Frontend, Backend, Rule이 구성되어 있어야 합니다.

Step 1. Windows VM에서 X-Forwared-For 로깅 설정

Windows Server 2019에 IIS를 설치하는 경우, 기본적으로 IIS 로깅에서 X-Forwarded-For 는 기록되지 않습니다.
IIS 로깅 설정에서 X-Forwarded-For가 기록되도록 설정합니다.

대상 웹사이트 - 로깅 (Logging)

Select Fields

Field Name : X-Forwarded-For
Source Type : Request Header
Source : X-Forwarded-For
[OK]

[OK]

결과 확인
IIS 로그 파일 이름에 _x 라는 접미사가 붙은 파일이 새로 생성됩니다.

로그의 X-Forwarded-For 필드에 IP 주소와 Port 가 기록됩니다.

Step 2. Application Gateway - Rewrite HTTP Header

Application Gateway의 Rewrtie 메뉴에서 Rewrite set을 만듭니다.

Application Gateway - Rewrites - Rewrite set

Name : X-Fowarded-For
Routing rule 선택
[Next]

Add rewrite rule - Click to configure this action

Rewrite rule name과 Rule sequence 입력 (X-Forwarded-For, 100)
Common header : X-Forwarded-For 선택
Header value : {var_add_x_forwarded_for_proxy}
[OK]
[Create]

설정 완료

결과 확인
IIS 로그에서 IP 주소만 기록됨

-끝-