1부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성

안녕하세요. 

새로운 포스팅으로 돌아온 TAK 입니다.

 

이번 주제는 "AWS-Azure VPN S2S 연결 및 DNS 서버 구성" 입니다.

 

이는 VPN S2S 연결을 통해 Multi Cloud 간 통신 그리고 Azure PaaS 리소스인 Azure Storage Account(Blob) 액세스를 위한 DNS 서버 구성입니다.

 

최근 기업 간 여러 CSP의 인프라와 서비스를 사용하며 운영하는 Multi Cloud 수요가 증가함에 따라 주제를 선정하여 준비하게 되었습니다.

이번 포스팅의 내용에서는 일부 일반적인 리소스 배포에 대한 내용은 생략되어 있습니다.
다만, 필요한 구성에 대한 정보는 포함되어 있음을 알려드립니다.

 

**Multi Cloud 란?

정의의 개념은 비슷하지만, 세부적인 사항은 각 CSP 별로 다를 수 있습니다.

 

 

본격적인 내용에 앞서, 3가지 배경지식이 될 내용을 살펴보겠습니다.

 

첫째, AWS와 Azure의 리소스 용어

General	AWS	Azure	비고
Virtual Network	VPC (Virtaul Private  Cloud)	VNET (Virtual Network)
Virtual Machine	EC2 (Elastic Compute Cloud)	VM (Virtual Machine)
Endpoint (In Cloud)	Virtual Private Gateway	Virtual Network Gateway	For VPN Connection
Gateway (On the other side)	Customer Gateway	Local Network Gateway	For VPN Connection
Storage	S3 (Simple Storage Services)	Blob of Storage Account

 

둘째, VPN S2S 연결

AWS와 Azure에서는 VPN S2S(Site to Site) 연결을 아래 그림과 같이 표현하고 있습니다.

 

- AWS

이미지 출처 : https://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/images/vpn-how-it-works-vgw.png

 

- Azure

 

이미지 출처 : https://learn.microsoft.com/ko-kr/azure/vpn-gateway/media/tutorial-site-to-site-portal/diagram.png

 

표현의 방식이 다를 뿐, 서로 동일한 역할과 기능을 하는 것을 알 수 있습니다.

해당 구성에서는 일반적으로 S2S(Site to Site) 연결에서 사용되는 IPSec 방식을 사용하였습니다.

 

쉽게 표현하면, Network to Network의 개념으로 사설망과 사설망을 연결하고자 할 때 IPSec 방식이 사용됩니다.

 

위 용어를 빌려 표현하자면,

이는 Multi 클라우드 간 보안 연결이며, 데이터가 Gateway 리소스로부터 전달되어 AWS - Azure 간 주고 받는 암화된 링크 입니다.

 

실제 아래 리소스들은 위 이미지와 같이 온-프레미스 즉, 각 클라우드 입장에서 반대편에서 S2S(Site to Site) 연결을 위해 설치된 물리적 디바이스 혹은 SW 애플리케이션의 정보를 담고,

Gateway (On the other side)

Customer Gateway

Local Network Gateway

For VPN Connection

 

암호화된 터널링을 통해, 각 Virtual Network의 Endpoint를 통해 연결 및 통신 가능함을 나타냅니다.

 

관련하여 VPN 학습에서 큰 도움이 된 블로그를 공유합니다.

VPN 쉽게 이해하기

 

셋째, DNS 통신 방식

 

이미지 출처 : https://www.wisewiredbooks.com/csbooks/ch3-network-internet/img/dns-recursive.jpg

 

일반적으로 DNS의 기본 동작은 다음과 같다.

 

위 그림과 관련된 설명은 아래 2가지를 가정한다.

- Cache가 남아 있지 않다는 가정

- Local, Root, TLD DNS 에서 최초 질의한 FQDN을 알지 못한다는 가정

 

 

1.웹 브라우저(클라이언트)에서 www.google.com 질의 

2. Computer는 우선 Local DNS 해당 Hostname에 대한 IP 주소를 질의

  - Iterated query (반복적)

  - Recursive query (재귀적)

3. Local DNS에 해당 정보가 없다면, Root DNS 질의

  - 정보가 없다면, com DNS(TLD 네임 서버)의 IP 주소를 Local DNS에게 전달

4. TLD DNS에 질의

  - 정보가 없다면, google.com DNS(google.com 네임 서버)의 IP주소를 Local DNS에게 전달

5. google.com의 네임 서버에 질의

  - 해당 네임 서버에 등록된 ns에 따라서 질의한 FQDN의 주소를 응답

6. 획득한 IP 주소를 Local DNS가 브라우저에게 전달

 

 

하지만, 현재 AWS - Azure 클라우드 간 DNS 전달자를 사용하여 통신하는 구성은 Azure 클라우드의 리소스를 사용함으로써 보다 자세한 설명이 필요하기에 2부에서 자세히 다룰 예정입니다.

(많관부~)

 

 

이로써 간략한 설명을 마치고, 본격적으로 실제 구성을 진행하겠습니다.

 

 

---

Contents

Architecture

Network

Azure

• VNet : 10.100.0.0/16
  • subnet01 : 10.000.0.0/24
  • subnet02 : 10.100.1.0/24
  • subnet-pe : 10.100.30.0/24
  • GatewaySubnet : 10.100.255.0/24

 

AWS

• VPC : 10.200.0.0/16
  • tak-aws-subnet-public1-2a : 10.200.0.0/20
  • tak-aws-subnet-private1-2a : 10.200.128.0/20
  • tak-aws-subnet-public2-2b : 10.200.16.0/20
  • tak-aws-subnet-private2-2b : 10.200.144.0/20

 

1. Azure 인프라 - 네트워크

1-1. 구성 목록

• Azure Virtual Network(VNet)
  • 상기 정보 기준으로 구성

 

• Azure VM
  • Windows (Windows Server 2019 Datacenter)
  • Standard B2s(2개 vcpu, 4GiB 메모리)

 

• Azure Virtual Network Gateway
  • Azure의 VPN은 VNet 내 전용 Gateway Subnet 배포
    → 구독 및 VNet Region(Korea Central)으로 한정
  • 사용량을 고려하여 적절한 SKU 선택하여 배포
    → 현재 구성의 SKU : VpnGw2AZ

 

• Azure Storage Account
  • PaaS 리소스로 그 중 Blob을 하위 리소스로 선택하여 Private Endpoint 연결.
  • 이를 통해, 외부에 접근을 차단하고, 가상 네트워크 내에서만 액세스 가능

               → Private Endpoint 할당되고, 배포된 서브넷 대역 기준으로 사설 IP 할당

 

2. AWS 인프라 - 네트워크

2-1. VPC & EC2 생성

VPC

• Auzre 대역과 중첩되지 않게 네트워크 구성
• Client 서버 | DNS 서버 별도의 보안 그룹 적용

 

EC2

• Client 서버
  • Amazon Linux 3 (t2.medium)

 

• DNS 서버
  • Windows Server 2019 Base (t3.medium)

 

2-2. VPN 연결을 위한 구성

2-2-1. Custom GW 생성

• IP 주소 : 디바이스의 외부 인터페이스에 대한 인터넷 라우팅 가능 IP 주소
  • 즉, 연결할 대상(Azure VPN)의 공용 IP

2-2-2. Virtual Private GW 생성

2-2-3. VP GW - VPC 연결

• VP GW를 통해 연결할 대상 네트워크인 VPC 선택

 

• 사용 가능한(대상) VPC 선택하여 연결

2-2-4. 라우팅 테이블

 

• 라우팅 전파 편집

 

 

** EC2 배포된 서브넷과 연결된 라우팅 테이블 설정 필요

 

3. AWS - Azure VPN 연결

3-1. (AWS) Site-to-Site VPN Connections

• CGW 이름 변경(tak-custom-gw-01 → tak-cgw-01)

 

Config

• 대상 게이트웨이 유형 : 가상 프라이빗 게이트웨이
• 가상 프라이빗 게이트웨이 : 기존 생성한 VPGW
• 고객 게이트웨이 ID : 기존 생성한 CGW
• 라우팅 옵션 : 정적
  • 연결할 대상(Azure Virtural Network)의 Private CIDR 형식 기입

 

• 로컬 IPv4 네트워크 CIDR : 기본값(0.0.0.0/0)
  • PN 터널을 통해 통신할 수 있는 고객 게이트웨이(온프레미스) 측의 IPv4 CIDR 범위 

 

• 원격 IPv4 네트워크 CIDR : 기본값(0.0.0.0/0)
  • VPN 터널을 통해 통신할 수 있는 AWS 측의 IPv4 CIDR 범위

 

**Pre-Shared Key for Tunnel 1

• AWS의 VPN 연결 생성 시, 기본적으로 2개의 터널이 생성됨.
  • 2개 중 1개를 선택하여, 연결할 대상(Azure Local Network Gateway)의 [IP 구성] 설정에 기입
  • 이는 VPN S2S 통신에서 사용되는 공용 IP 임

 

• 이때, 사전 공유 키의 별도 값을 입력하지 않는다면, Amazon에서 자동으로 생성됨.
• 이는 기본 인증 옵션이며, 연결할 대상(Azure Local Network Gateway)에서 입력하여 디바이스 간 보안 연결을 설정
• 대상 VPN 연결을 선택 후, [작업] - [VPN 터널 옵션 수정]

 

• Tunnel 1 의 공용 IP주소를 선택하여, 사전 공유 키를 확인

 

3-2. (Azure) Site-to-Site VPN Connections

생성된 Azure Local Network Gateway의 [구성] 설정

• AWS의 Tunnel 1의 공용 IP
• AWS VPC의 네트워크 대역

 

• Azure의 VPN 연결
  • 연결 형식, GW 리소스 선택 등 연결을 추가

 

• 생성한 해당 연결을 선택하여 [인증 유형]의 공유 키(PSK) 값에 앞서 확인한 AWS의 Tunnel 1의 Pre-Shared Key 값을 입력

 

3-3. AWS - Azure 연결 확인

• AWS Tunnel 1 : UP

• Azure 연결 상태 : 연결됨

 

 

• AWS의 라우팅 테이블 설정 확인
  • AWS EC2 가 위치한 서브넷에 연결된 라우팅 테이블에
    → Azure의 네트워크 대역을 대상(Destination)
    → 트래픽이 생성한 VPN을 통해서 라우팅될 수 있도록 대상(Target) 설정

3-4. AWS - Azure 연결 테스트

AWS

• 공용 IP
  • 실패, 이유는 Azure VM의 인바운드 설정에서 공용 IP 접근 시, ICMP 허용하지 않았기 때문

• 사설 IP
  • 성공, Azure의 기본 네트워크 보안 그룹 규칙에서는 가상 네트워크 내 모든 프로토콜을 허용

 

Azure

• 공용 IP
  • 실패, 소스 IP로 Azure의 사설 네트워크 대역으로 설정

• 사설 IP
  • 성공

 

 

 

이번 포스팅에서는 VPN S2S(Site to Site) 구성하는 과정까지를 담았습니다.

 

이어지는 2부에서는 DNS 구성 관련한 포스팅으로 찾아오겠습니다!!!

 

 

제가 놓친 부분이 있다면, 자유롭게 댓글로 의견 남겨주세요:)