Azure에서 IPv4 고갈 방지

회사 네트워크는 일반적으로 RFC(Request for Comments) 1918에서 정의한 개인 IPv4 주소 범위의 주소 공간(예: 10.0.0.0/8, 172.16.0.0/12및 192.168.0.0/16)을 사용합니다. 온-프레미스 환경에서 이러한 범위는 최대 네트워크의 요구 사항을 충족하기에 충분한 IP 주소를 제공합니다. 따라서 많은 조직에서 IP 주소 할당을 위해 간단한 라우팅 구성 및 민첩한 프로세스의 우선 순위를 지정하는 주소 관리 사례를 개발합니다. IPv4 주소 공간의 효율적인 사용에 우선 순위를 두지 않는 경우가 많습니다.

클라우드에서는 대규모 네트워크를 쉽게 빌드할 수 있습니다. 마이크로 서비스 또는 컨테이너화와 같은 몇 가지 일반적인 아키텍처 패턴으로 인해 IPv4 주소 사용량이 증가할 수 있습니다. 따라서 보다 보수적인 주소 관리 사례를 채택하고 IPv4 주소를 제한된 리소스로 처리하는 것이 중요합니다.

이 문서에서는 Azure에서 대규모 네트워크를 빌드할 때 IPv4 주소 공간 소비를 최소화하는 두 가지 방법을 설명합니다. 이 메서드는 여러 가상 네트워크 또는 랜딩 존에서 동일한 IPv4 주소 블록을 다시 사용하는 네트워크 토폴로지에서 사용합니다.

• 메서드 1:IPv4 서브넷 피어링을 사용하여 랜딩 존의 스포크 가상 네트워크와 허브 가상 네트워크 간의 피어링에서 하나 이상의 서브넷을 제외합니다. 모든 랜딩 존의 피어링 관계에서 제외된 서브넷에 동일한 라우팅할 수 없는 IP 주소 범위를 할당할 수 있습니다. 이러한 IP 주소 범위는 다른 라우팅 가능한 IP 주소 범위와 겹칠 수 없습니다.

• 메서드 2: 랜딩 존의 가상 네트워크에 연결되지 않은 격리된 가상 네트워크에 애플리케이션을 배포합니다. 해당 엔드포인트를 Azure Private Link 서비스와 연결합니다. 랜딩 존의 스포크 가상 네트워크에서 Private Link 서비스와 연결된 프라이빗 엔드포인트를 만듭니다. 격리된 가상 네트워크는 회사 네트워크의 라우팅 가능한 주소 공간과 겹치는 경우에도 모든 IPv4 주소 공간을 사용할 수 있습니다.

방법 1은 여러 시스템과 애플리케이션이 서로 의존하는 기존 엔터프라이즈 환경에서 가장 적합합니다. 메서드 2는 애플리케이션이 독립적으로 작동하는 느슨하게 결합된 환경에서 가장 적합합니다.

Azure 랜딩 존 맞춤

이 문서의 권장 사항은 Azure 랜딩 존 아키텍처를 기반으로 하는 네트워크 토폴로지에 적용됩니다.

• Azure 리소스를 호스트하는 각 지역에는 허브 및 스포크 네트워크가 있습니다.

• 다른 지역의 허브 및 스포크 네트워크는 글로벌 가상 네트워크 피어링을 통해 연결됩니다.

• 허브 및 스포크 네트워크는 Azure ExpressRoute 회로 또는 사이트간 VPN을 통해 온-프레미스 사이트에 연결합니다.

Azure 랜딩 존 아키텍처에서 각 애플리케이션은 자체 스포크 가상 네트워크에서 실행됩니다. 각 스포크 가상 네트워크는 회사 네트워크에서 고유한 IPv4 주소 공간을 사용합니다.

랜딩 존의 모든 리소스는 다음과 같은 방법으로 연결할 수 있습니다.

• IP 주소를 사용하여 회사 네트워크의 다른 리소스에 대한 연결 시작

• IP 주소를 통해 전체 회사 네트워크에서 직접 연결 받기

그러나 리소스가 항상 전체 회사 네트워크의 연결 가능성을 필요로 하는 것은 아닙니다. 예를 들어 HTTP 프런트 엔드, 비즈니스 논리 및 데이터 계층과 같은 3계층 웹 애플리케이션이 포함된 랜딩 존에서는 방문 영역 외부에서만 HTTP 프런트 엔드에 연결할 수 있어야 합니다. 다른 계층은 서로 연결해야 하며 프런트 엔드는 클라이언트의 연결을 수락할 필요가 없습니다. 이 예제에서는 각 랜딩 존에 다음 구성 요소를 할당하여 IPv4 주소 사용량을 최소화할 수 있음을 시사합니다.

• 전체 회사 네트워크에서 고유한 주소 공간입니다. 랜딩 존 외부에서 연결할 수 있어야 하는 리소스만 이 주소 공간을 사용합니다. 이 문서에서는 이 주소 공간을 랜딩 존의 라우팅 가능한 주소 공간이라고 합니다.

• 자체 랜딩 존 내의 다른 리소스와만 통신해야 하는 리소스의 내부 주소 공간입니다. 이 주소 공간에는 회사 네트워크의 직접 연결 가능성이 필요하지 않습니다. 이 문서에서는 이 주소 공간을 랜딩 존의 비주선 주소 공간이라고 합니다.

다음 섹션에서 프런트 엔드 구성 요소는 전체 회사 네트워크에서 연결할 수 있어야 하는 애플리케이션 구성 요소를 참조합니다. 백 엔드 구성 요소는 회사 네트워크에서 엔드포인트를 노출하지 않고 자체 랜딩 존 내에서만 연결할 수 있어야 하는 애플리케이션 구성 요소를 나타냅니다.

방법 1: 스포크 가상 네트워크의 라우팅 불가 서브넷

IPv4 서브넷 피어링을 사용하여 두 가상 네트워크 간의 피어링 관계를 특정 서브넷으로 제한할 수 있습니다. 피어링 구성에 포함된 서브넷만 트래픽을 서로 라우팅할 수 있습니다. 피어링 구성에서 제외된 서브넷은 피어 가상 네트워크에서 보이지 않고 연결할 수 없는 상태로 유지됩니다.

허브 및 스포크 토폴로지에서 피어링 구성에서 각 스포크에서 하나 이상의 서브넷을 제외하는 경우 해당 서브넷은 다른 피어링, ExpressRoute 연결 또는 VPN 연결을 통해 허브 및 허브에 연결된 모든 원격 네트워크에서 보이지 않고 연결할 수 없는 상태로 유지됩니다. 따라서 모든 스포크 가상 네트워크에서 피어링 구성에서 제외된 모든 서브넷에 동일한 주소 범위를 할당할 수 있습니다. 해당 범위는 비라우팅 가능 범위로 정의해야 하며 회사 네트워크의 다른 곳에서는 사용할 수 없습니다.

다음 다이어그램에는 이러한 구성 요소가 포함되어 있습니다.

• 범위 10.57.0.0/16 는 라우팅할 수 없는 주소 공간으로 사용됩니다.

• 허브 가상 네트워크와 각 랜딩 존 스포크 가상 네트워크는 고유한 라우팅 가능한 IP 주소 범위(10.0.0.0/2410.1.0.0/24및10.2.0.0/24)를 사용합니다.

• 각 랜딩 존 스포크 가상 네트워크에는 라우팅할 수 없는 범위 10.57.0.0/16 내에 있는 하나 이상의 비라우팅 가능 서브넷도 포함됩니다. Azure 가상 네트워크의 주소 공간에는 여러 IP 주소 범위가 포함될 수 있습니다.

• 이러한 서브넷은 허브와의 피어링 관계에서 제외됩니다. 따라서 다른 랜딩 존 스포크에 있는 라우팅 불가능한 서브넷은 동일하거나 겹치는 주소 범위를 가질 수 있습니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

이 방법은 랜딩 존의 스포크 가상 네트워크 내에서 전체 연결을 유지합니다. 동일한 스포크 가상 네트워크의 모든 리소스는 라우팅 가능한 서브넷 또는 라우팅할 수 없는 서브넷에 상주하는지 여부에 관계없이 서로 연결할 수 있습니다. 그러나 라우팅 가능한 서브넷의 리소스만 자체 랜딩 존 외부의 리소스에 연결할 수 있습니다.

랜딩 존에 애플리케이션 배포

서브넷 피어링을 사용하여 라우팅할 수 없는 서브넷을 사용하여 랜딩 존을 빌드하는 경우 다른 패턴을 적용하여 라우팅 가능 및 라우팅할 수 없는 서브넷에 애플리케이션의 프런트 엔드 및 백 엔드 구성 요소를 배포할 수 있습니다. 다음 고려 사항은 완전히 라우팅 가능한 단일 주소 공간을 사용하는 기존 랜딩 존에서 마이그레이션된 새로 빌드된 애플리케이션과 애플리케이션 모두에 적용됩니다.

• Layer-7 애플리케이션 배달 컨트롤러를 통해 노출되는 애플리케이션: 이러한 애플리케이션 배달 컨트롤러에는 Azure Application Gateway 또는 타사 NVA(네트워크 가상 어플라이언스)가 포함됩니다. 애플리케이션 배달 컨트롤러의 엔드포인트만 랜딩 존 외부의 클라이언트에서 연결할 수 있어야 합니다. 따라서 애플리케이션 배달 컨트롤러는 라우팅 가능한 서브넷에 상주해야 하는 유일한 프런트 엔드 구성 요소입니다.

• Azure 부하 분산 장치를 통해 노출되는 애플리케이션: 애플리케이션이 내부 Azure 부하 분산 장치를 사용하는 경우 부하 분산 장치의 백 엔드 풀에 있는 가상 머신은 라우팅 가능한 서브넷에 있어야 합니다. 다른 모든 구성 요소를 라우팅되지 않는 서브넷에 배포할 수 있습니다.

다음 다이어그램에서는 이러한 패턴을 보여 줍니다.

• 랜딩 존 A는 라우팅 가능한 서브넷에서 유일한 구성 요소인 애플리케이션 배달 컨트롤러를 통해 노출되는 3계층 웹 애플리케이션을 호스트합니다.

• 랜딩 존 B는 내부 Azure 부하 분산 장치를 통해 노출되는 3계층 애플리케이션을 호스트합니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

아웃바운드 종속성

애플리케이션의 백 엔드 구성 요소는 회사 네트워크에서 인바운드 연결을 받을 필요가 없습니다. 그러나 랜딩 존 외부의 엔드포인트에 대한 연결을 시작해야 할 수도 있습니다. 일반적인 예로는 DNS(도메인 이름 시스템) 확인, AD DS(Active Directory Domain Services) 도메인 컨트롤러와의 상호 작용, 로그 관리 또는 백업 시스템과 같은 다른 랜딩 존 또는 공유 서비스의 애플리케이션에 대한 액세스가 포함됩니다.

라우팅할 수 없는 서브넷의 리소스가 랜딩 존 외부의 엔드포인트에 대한 연결을 시작해야 하는 경우 해당 연결은 라우팅 가능한 IP 주소 뒤에 SNAT(원본 NAT)를 사용해야 합니다. 따라서 각 랜딩 존의 라우팅 가능한 서브넷에 NAT 지원 NVA를 배포해야 합니다. 다음 다이어그램에서는 이 구성을 보여 줍니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

라우팅할 수 없는 서브넷은 랜딩 존 외부로 향하는 모든 트래픽을 NAT 지원 NVA로 전달하는 사용자 지정 경로 테이블을 사용해야 합니다. 이전 다이어그램에서, 10.57.0.0/16 범위는 라우팅할 수 없으며, 10.0.0.0/8 내의 다른 범위는 라우팅할 수 있습니다. 라우팅할 수 없는 각 서브넷에 대한 사용자 지정 경로 테이블에는 다음 UDR(사용자 정의 경로)이 포함되어야 합니다.

가상 네트워크의 시스템 경로 테이블에는 라우팅할 수 없는 범위의 대상에 대한 시스템 경로가 이미 포함되어 있습니다 10.57.0.0/16 . 해당 범위 내의 트래픽에 대한 UDR을 정의할 필요가 없습니다.

NAT 지원 NVA를 호스트하는 서브넷을 비롯한 라우팅 가능한 서브넷은 일반적으로 허브 가상 네트워크의 NVA로 랜딩 존 외부의 트래픽을 전달하는 사용자 지정 경로 테이블을 사용해야 합니다. 이러한 NVA는 스포크 간에 트래픽을 라우팅합니다. 이러한 허브 NVA는 NAT 작업을 수행하지 않습니다. 이전 다이어그램에서 라우팅 가능한 각 서브넷에 대한 사용자 지정 경로 테이블에는 다음 UDR이 포함되어야 합니다.

대상이 10.0.0.0/24 있는 두 번째 UDR은 허브 가상 네트워크 경로의 리소스에 대한 연결이 허브 방화벽을 통해 라우팅되도록 합니다. 일부 애플리케이션에는 더 많은 UDR이 필요할 수 있습니다. 랜딩 존의 가상 머신이 일반적으로 허브에서 호스트되는 NVA를 통해 인터넷에 액세스해야 하는 경우 기본 경로 0.0.0.0/0도 정의해야 합니다.

Azure Firewall 또는 타사 NVA를 NAT 지원 디바이스로 사용할 수 있습니다. 다음 섹션에서는 두 옵션을 모두 다룹니다. 인터넷 바인딩된 트래픽에 대해서만 SNAT를 지원하므로 Azure NAT Gateway를 사용할 수 없습니다.

Azure Firewall을 통해 SNAT 구현

낮은 복잡성과 최소한의 관리 우선 순위를 지정해야 하는 경우 Azure Firewall은 배포할 수 없는 서브넷에서 발생하는 연결에 대해 SNAT를 구현하는 최상의 솔루션을 제공합니다. Azure Firewall은 다음과 같은 이점을 제공합니다.

• 완전 관리되는 수명 주기
• 기본 제공되는 고가용성
• 트래픽 볼륨에 따라 자동 크기 조정

Azure Firewall을 사용하는 경우 다음 요소를 고려합니다.

• 라우팅 가능한 주소 공간을 사용해야 하는 AzureFirewallSubnet이라는 자체 예약 서브넷에 Azure Firewall을 배포합니다.

• 일부 Azure Firewall SKU 또는 구성에는 방화벽 관리를 위해 두 번째 예약된 서브넷이 필요할 수 있습니다. 관리 서브넷에는 라우팅 가능한 주소 공간이 필요하지 않습니다.

• Azure Firewall에는 세 가지 SKU가 있습니다. SNAT는 리소스를 많이 사용하는 것이 아니므로 기본 SKU로 시작합니다. 라우팅할 수 없는 서브넷에서 대량의 아웃바운드 트래픽을 생성하는 랜딩 존의 경우 표준 SKU를 고려합니다.

• SNAT 수행 옵션을 Always로 설정하여 Azure Firewall을 구성합니다. 각 인스턴스는 SNAT에 대해 권한이 없는 포트를 사용합니다. 수신된 모든 연결에서 SNAT를 구현하도록 Azure Firewall을 구성하려면 SNAT 구성 단계를 따릅니다.

• 모든 라우팅할 수 없는 서브넷을 랜딩 존 외부로 향하는 모든 트래픽을 방화벽의 개인 IP 주소로 전달하는 사용자 지정 경로 테이블과 연결합니다.

다음 다이어그램은 각 스포크에서 Azure Firewall을 사용하여 라우팅할 수 없는 서브넷의 연결에 대해 SNAT를 제공하는 허브 및 스포크 네트워크를 보여 줍니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

타사 NVA를 통해 SNAT 구현

Azure Marketplace에서 NAT 기능이 있는 타사 NVA를 찾을 수 있습니다. 요구 사항이 Azure Firewall에서 지원할 수 있는 것을 초과하는 경우 비 Microsoft NVA를 사용하는 것이 좋습니다. 예를 들어 다음 기능이 필요할 수 있습니다.

• NAT 풀에 대한 세분화된 제어

• 사용자 지정 NAT 정책(예: 다른 연결에 다른 NAT 주소를 사용해야 할 수 있습니다).

• 규모 감축 및 스케일 아웃에 대한 세분화된 제어

타사 NVA를 사용하는 경우 다음 요소를 고려합니다.

• 고가용성을 보장하기 위해 NVA가 두 개 이상 있는 클러스터를 배포합니다.

• 표준 SKU Azure 부하 분산 장치를 사용하여 비주류 스포크 가상 네트워크에서 NVA로 연결을 분산합니다. 모든 연결은 대상 포트에 관계없이 SNAT를 사용해야 하므로 모든 포트 부하 분산 규칙이라고도 하는 고가용성 부하 분산 규칙을 사용해야 합니다.

• NAT 지원 NVA에 대한 단일 암 및 이중 암 구성 중에서 선택합니다. 단일 암 구성은 더 간단하며 일반적으로 권장됩니다.

다음 다이어그램에서는 이제 타사 NVA를 사용하여 허브 및 스포크 네트워크 토폴로지에서 SNAT를 구현하는 방법을 보여 줍니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

Azure Virtual WAN에서 메서드 1 사용

Azure Virtual WAN은 서브넷 피어링을 지원하지 않습니다. 따라서 Virtual WAN 기반 허브 및 스포크 네트워크에 분산할 수 없는 서브넷이 있는 랜딩 존 가상 네트워크를 만들 수 없습니다. 그러나 각 랜딩 존에 대해 두 개의 피어된 가상 네트워크를 사용하여 메서드 1의 기본 원칙을 적용할 수 있습니다.

• 첫 번째 가상 네트워크에 라우팅 가능한 주소 공간을 할당하고 Virtual WAN 허브에 연결합니다.

• 라우팅할 수 없는 주소 공간을 두 번째 가상 네트워크에 할당하고 라우팅 가능한 가상 네트워크와 피어합니다.

다음 다이어그램은 결과 토폴로지입니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

이 방법은 랜딩 존 내의 연결을 제한하지 않습니다. 랜딩 존의 두 가상 네트워크는 직접 피어화되므로 라우팅 가능한 가상 네트워크 또는 라우팅할 수 없는 가상 네트워크에 상주하는지 여부에 관계없이 모든 리소스가 서로 연결할 수 있습니다. 그러나 라우팅 가능한 가상 네트워크의 리소스만 랜딩 존 외부의 리소스에 연결할 수 있습니다.

라우팅 관점에서 볼 때 다음 구성 간에는 차이가 없습니다.

• 동일한 가상 네트워크의 라우팅 가능 및 라우팅할 수 없는 서브넷(기존 허브 및 스포크 네트워크에 대한 이전 섹션에서 설명)

• 직접 피어된 가상 네트워크(Virtual WAN 기반 허브 및 스포크 네트워크에 대한 이 섹션에 설명됨)

따라서 Virtual WAN 기반 네트워크에서 다음 지침이 적용됩니다.

• 이전 섹션에서 설명한 것과 동일한 고려 사항을 사용하여 라우팅 가능 및 라우팅할 수 없는 서브넷에 애플리케이션 구성 요소를 배포할 수 있습니다.

• 라우팅 가능한 서브넷에서 NAT 지원 NVA를 사용하여 아웃바운드 종속성을 관리할 수 있습니다.

방법 2: Private Link 서비스

Private Link 를 사용하면 가상 네트워크의 클라이언트가 가상 네트워크 피어링 또는 가상 네트워크 간 네트워크 VPN과 같은 계층 3 연결을 구성하지 않고도 다른 가상 네트워크의 애플리케이션을 사용할 수 있습니다. 두 가상 네트워크는 겹치는 IP 주소 범위를 사용할 수 있습니다. Azure는 필요한 NAT 논리를 투명하게 처리합니다. 이 방법은 기존 허브 및 스포크 네트워크와 Virtual WAN 기반 네트워크에 모두 적용됩니다.

Private Link를 통해 애플리케이션을 노출하려면 다음 단계를 수행합니다.

1. 표준 SKU를 사용하여 내부 Azure 부하 분산 장치의 백 엔드 풀에 애플리케이션의 엔드포인트를 추가합니다.

2. 부하 분산 장치의 프런트 엔드 IP 주소를 Private Link 서비스 리소스와 연결합니다.

3. 클라이언트 쪽에서 프라이빗 엔드포인트 리소스 를 만들고 서버 쪽 Private Link 서비스와 연결합니다.

애플리케이션을 사용하려면 클라이언트가 프라이빗 엔드포인트에 연결합니다. Azure는 해당 Private Link 서비스와 연결된 부하 분산 장치 프런트 엔드 IP 주소로 연결을 투명하게 라우팅합니다.

Private Link를 사용하여 각 랜딩 존에 두 개의 가상 네트워크를 할당하여 IPv4 고갈을 완화할 수 있습니다.

• 회사 네트워크에 연결된 라우팅 가능한 주소 공간이 있는 가상 네트워크

• 임의로 선택한 주소 공간이 있는 격리된 가상 네트워크로, 회사 네트워크의 주소 공간과 겹칠 수도 있습니다.

격리된 가상 네트워크에 엔드포인트를 노출하는 애플리케이션 및 Private Link 서비스를 배포합니다. 라우팅 가능한 가상 네트워크에서 해당 서비스에 연결하는 프라이빗 엔드포인트를 배포합니다.

다음 다이어그램에서는 회사 네트워크의 주소 공간과 겹치는 큰 주소 공간을 10.0.0.0/16사용하는 두 개의 랜딩 존을 보여 줍니다. 각 랜딩 존은 이 공간을 격리된 가상 네트워크에 할당합니다. 애플리케이션은 격리된 스포크 가상 네트워크에 배포되고 Private Link 서비스와 연결됩니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

다른 랜딩 존의 클라이언트를 포함하여 회사 네트워크의 클라이언트는 Private Link 서비스와 연결된 프라이빗 엔드포인트를 통해 애플리케이션을 사용합니다. 다음 다이어그램에서는 이러한 연결이 설정되는 방법을 보여 줍니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

아웃바운드 종속성에 Private Link 서비스 사용

격리된 가상 네트워크의 애플리케이션은 회사 네트워크의 엔드포인트에 대한 연결을 시작할 수 없습니다. 따라서 메서드 2는 여러 랜딩 존의 애플리케이션이 독립적으로 작동하고 회사 네트워크의 시스템에 의존하지 않는 시나리오에 가장 적합합니다. 그러나 격리된 가상 네트워크의 애플리케이션이 랜딩 존 외부의 특정 엔드포인트에 액세스해야 하는 경우에도 이 방법을 적용할 수 있습니다.

다음 다이어그램에서는 Private Link 서비스를 통해 랜딩 존 A의 격리된 가상 네트워크에 있는 애플리케이션이 허브 가상 네트워크의 공유 서비스와 랜딩 존 B의 애플리케이션 엔드포인트를 모두 사용할 수 있도록 하는 방법을 보여 줍니다.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

기여자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

주요 작성자:

• 페데리코 게리니 | 선임 클라우드 솔루션 설계자, EMEA 기술 리더 Azure 네트워킹
• 쿠쉬 카비라즈 | 클라우드 솔루션 설계자
• Jack Tracey | 선임 클라우드 솔루션 설계자

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

• 서브넷 피어링 구성
• 가상 네트워크에 Azure Firewall 배포
• Azure Firewall에서 SNAT 구성
• Azure Virtual Network에서 지원되는 IP 주소
• Private Link
• Azure Load Balancer
• 가상 네트워크 피어링
• 허브 및 스포크 네트워크 토폴로지

관련 리소스

• 네트워킹 아키텍처 디자인
• 다중 테넌트 솔루션의 네트워킹을 위한 아키텍처 접근 방식