IP 주소 지정 계획

  • 아티클

조직이 Azure에서 IP 주소 지정을 계획하는 것이 중요합니다. 계획은 IP 주소 공간이 온-프레미스 위치와 Azure 지역에서 겹치지 않도록 합니다.

설계 고려 사항:

  • 온-프레미스 및 Azure 지역에서 IP 주소 공간이 겹치면 주요 경합 문제가 발생합니다.

  • Azure VPN Gateway는 NAT(네트워크 주소 변환) 기능을 통해 겹치는 IP 주소 공간이 있는 겹치는 온-프레미스 사이트를 연결할 수 있습니다. 이 기능은 일반적으로 Azure Virtual WAN 및 독립 실행형 Azure VPN Gateway에서 사용할 수 있습니다.

    {Diagram that shows how NAT works with VPN Gateway.}

  • 가상 네트워크를 만든 후 주소 공간을 추가할 수 있습니다. 가상 네트워크가 이미 가상 네트워크 피어링을 통해 다른 가상 네트워크에 연결된 경우 이 프로세스를 중단할 필요가 없습니다. 대신 각 원격 피어링에는 네트워크 공간이 변경된 후 수행되는 재동기화 작업이 필요합니다.

  • Azure는 각 서브넷 내에 5개의 IP 주소를 예약합니다. 가상 네트워크 및 포함된 서브넷의 크기를 조정할 때 이러한 주소를 고려합니다.

  • 일부 Azure 서비스에는 전용 서브넷이 필요합니다. 이러한 서비스에는 Azure Firewall 및 Azure VPN Gateway가 포함됩니다.

  • 서브넷을 특정 서비스에 위임하여 서브넷 내에 서비스 인스턴스를 만들 수 있습니다.

디자인 권장 사항:

  • Azure 지역 및 온-프레미스 위치에서 겹치지 않는 IP 주소 공간을 미리 계획합니다.

  • RFC 1918 주소로 알려진 프라이빗 인터넷 주소 할당의 IP 주소를 사용합니다.

  • 다음 주소 범위는 사용하지 마세요.

    • 224.0.0.0/4(멀티캐스트)
    • 255.255.255.255/32(브로드캐스트)
    • 127.0.0.0/8(루프백)
    • 169.254.0.0/16(링크-로컬)
    • 168.63.129.16/32(내부 DNS)

  • 개인 IP 주소의 가용성이 제한된 환경의 경우 IPv6 사용을 고려합니다. 가상 네트워크는 IPv4 전용 또는 이중 스택 IPv4+IPv6일 수 있습니다.

    Diagram that shows IPv4 and IPv6 dual stack.

  • /16과 같은 대규모 가상 네트워크를 만들지 마세요. 이는 IP 주소 공간이 낭비되지 않도록 하는 것입니다. 지원되는 가장 작은 IPv4 서브넷은 /29이고 가장 큰 것은 CIDR(Classless Inter-Domain Routing) 서브넷 정의를 사용할 때 /2입니다. IPv6 서브넷의 크기는 정확히 /64여야 합니다.

  • 필요한 주소 공간을 미리 계획하지 않은 상태에서 가상 네트워크를 만들지 마세요.

  • 특히 공용 IP 주소가 조직에 속하지 않는 경우 가상 네트워크에 공용 IP 주소를 사용하지 마세요.

  • 사용할 서비스를 고려합니다. CNI 네트워킹이 있는 AKS와 같이 IP 주소(예약된 IP)가 있는 일부 서비스가 있습니다.

  • IPv4 고갈을 방지하려면 비주기 랜딩 존 스포크 가상 네트워크 및 Azure Private Link 서비스를 사용합니다.

IPv6 고려 사항

점점 더 많은 조직이 해당 환경에서 IPv6을 채택하고 있습니다. 이러한 채택은 공용 IPv4 공간 고갈, 특히 대규모 네트워크 내에서 개인 IPv4 부족, IPv6 전용 클라이언트에 대한 연결을 제공해야 하는 필요성에 의해 좌우됩니다. IPv6을 채택하는 보편적인 접근 방식은 없습니다. 그러나 IPv6을 계획하고 기존 Azure 네트워크에서 구현할 때 따를 수 있는 모범 사례가 있습니다.

Azure용 Microsoft 클라우드 채택 프레임워크 클라우드에서 시스템을 만들 때 고려해야 할 고려 사항을 이해하는 데 도움이 됩니다. 지속 가능한 시스템을 설계하기 위한 아키텍처 모범 사례에 대해 알아보려면 Azure 랜딩 존 디자인 원칙을 참조 하세요. 참조 아키텍처 배포, 다이어그램 및 가이드를 포함하여 클라우드 아키텍처에 대한 심층적인 권장 사항 및 모범 사례는 IPv6에 대한 아키텍처 센터 가이드를 참조하세요.

설계 고려 사항:

  • IPv6 채택을 단계적으로 진행합니다. 비즈니스 요구 사항에 따라 필요한 경우 IPv6을 구현합니다. IPv4와 IPv6은 필요한 한 공존할 수 있습니다.

  • 애플리케이션이 VM(가상 머신)과 같이 완전한 IPv6 지원을 제공하는 IaaS(Infrastructure as a Service) 서비스를 사용하는 시나리오에서는 IPv4 및 IPv6의 네이티브 엔드투엔드 사용이 가능합니다. 이 구성은 번역 복잡성을 방지하고 서버 및 애플리케이션에 가장 많은 정보를 제공합니다.

    IPv6 주소를 사용하여 Basic-SKU 인터넷 연결 Azure 부하 분산 장치를 배포할 수 있습니다. 이 구성을 사용하면 부하 분산 장치를 통해 공용 인터넷과 Azure VM 간에 네이티브 엔드투엔드 IPv6 연결을 사용할 수 있습니다. 또한 이 방법은 공용 인터넷에서 VM과 IPv6 지원 클라이언트 간의 네이티브 엔드투엔드 아웃바운드 연결을 용이하게 합니다. 이 방법을 사용하려면 경로의 모든 디바이스가 IPv6 트래픽을 처리해야 합니다.

    네이티브 엔드 투 엔드 접근 방식은 직접 서버 간 또는 클라이언트 간 통신에 가장 유용합니다. 일반적으로 방화벽, 웹 애플리케이션 방화벽 또는 역방향 프록시로 보호되는 대부분의 웹 서비스 및 애플리케이션에는 유용하지 않습니다.

  • 타사 서비스, PaaS(Platform as a Service) 서비스 및 백 엔드 솔루션의 조합을 사용하는 일부 복잡한 배포 및 애플리케이션은 네이티브 IPv6을 지원하지 않을 수 있습니다. 이러한 경우 NAT/NAT64 또는 IPv6 프록시 솔루션을 사용하여 IPv6과 IPv4 간의 통신을 사용하도록 설정해야 합니다.

  • 애플리케이션 아키텍처의 복잡성 또는 학습 비용과 같은 기타 요소가 중요한 것으로 간주되는 경우 백 엔드에서 IPv4 전용 인프라를 계속 사용하고 서비스 제공을 위해 타사 NVA(네트워크 가상 어플라이언스) 이중 스택 IPv4/IPv6 게이트웨이를 배포할 수 있습니다.

    NVA를 사용하는 일반적인 배포는 다음과 같습니다.

    Diagram that shows a dual-stack IPv4/IPv6 gateway providing access to an IPv4-only back end.

디자인 권장 사항:

일반적인 아키텍처의 모양을 자세히 살펴보겠습니다.

Diagram that shows an IPv4/IPv6 load balancer providing access to an IPv4-only back end.

  • 복원력을 위해 VMSS Flex(유연한 오케스트레이션)를 사용하여 Virtual Machine Scale Sets에 NVA를 배포하고 공용 IP 주소 프런트 엔드가 있는 Azure Load-Balancer를 통해 인터넷에 노출합니다.

    NVA는 IPv4 및 IPv6 트래픽을 수락하고 IPv4 전용 트래픽으로 변환하여 애플리케이션 서브넷의 애플리케이션에 액세스합니다. 이 접근 방식은 애플리케이션 팀의 복잡성을 줄이고 공격 노출 영역을 줄입니다.

  • Azure Front Door를 배포하여 웹 트래픽에 대한 글로벌 라우팅을 제공합니다.

    Azure Front Door 기능에는 다음과 같이 IPv6 클라이언트 요청 및 IPv4 전용 백 엔드로의 트래픽 프록시가 포함됩니다.

    Diagram that shows Azure Front Door providing access to an IPv4-only back end.

NVA 접근 방식과 Azure Front Door 접근 방식 간의 기본 차이점은 다음과 같습니다.

  • NVA는 고객 관리형이며 OSI 모델의 계층 4에서 작동하며 프라이빗 및 공용 인터페이스를 사용하여 애플리케이션과 동일한 Azure 가상 네트워크에 배포할 수 있습니다.
  • Azure Front Door는 글로벌 Azure PaaS 서비스이며 계층 7(HTTP/HTTPS)에서 작동합니다. 애플리케이션 백 엔드는 Azure Front Door의 트래픽만 허용하도록 잠글 수 있는 인터넷 연결 서비스입니다.

복잡한 환경에서는 둘 다의 조합을 사용할 수 있습니다. NVA는 지역 배포 내에서 사용됩니다. Azure Front Door는 다른 Azure 지역 또는 다른 인터넷 연결 위치에서 하나 이상의 지역 배포로 트래픽을 라우팅하는 데 사용됩니다. 최상의 솔루션을 확인하려면 Azure Front Door의 기능과 제품 설명서를 검토하는 것이 좋습니다.

IPv6 가상 네트워크 CIDR 블록:

  • 구독의 기존 Azure 배포에서 새 가상 네트워크를 만들 때 단일 IPv6 CIDR(클래스리스 Inter-Do기본 라우팅) 블록을 연결할 수 있습니다. IPv6의 서브넷 크기는 /64여야 합니다. 이 크기를 사용하면 서브넷을 온-프레미스 네트워크로 라우팅하도록 설정하려는 경우 향후 호환성이 보장됩니다. 일부 라우터는 /64 IPv6 경로만 허용할 수 있습니다.
  • IPv4만 지원하는 기존 가상 네트워크와 IPv4만 사용하도록 구성된 서브넷의 리소스가 있는 경우 가상 네트워크 및 리소스에 대해 IPv6 지원을 사용하도록 설정할 수 있습니다. 가상 네트워크는 이중 스택 모드에서 작동할 수 있으므로 리소스가 IPv4, IPv6 또는 둘 다를 통해 통신할 수 있습니다. IPv4 및 IPv6 통신은 서로 독립적입니다.
  • 가상 네트워크 및 서브넷에 대한 IPv4 지원을 사용하지 않도록 설정할 수 없습니다. IPv4는 Azure 가상 네트워크의 기본 IP 주소 지정 시스템입니다.
  • IPv6 CIDR 블록을 가상 네트워크 및 서브넷 또는 BYOIP IPv6에 연결합니다. CIDR 표기법은 IP 주소와 네트워크 마스크를 나타내는 방법입니다. 이러한 주소의 형식은 다음과 같습니다.
    • 개별 IPv4 주소는 32비트이며, 4개의 그룹은 소수 자릿수 3개입니다. 예들 들어 10.0.1.0입니다.
    • IPv4 CIDR 블록에는 0에서 255까지의 소수 자릿수로 구성된 4개의 그룹이 마침표로 구분되고 슬래시와 0에서 32까지의 숫자가 있습니다. 예들 들어 10.0.0.0/16입니다.
    • 개별 IPv6 주소는 128비트입니다. 4개의 16진수로 구성된 8개의 그룹이 있습니다. 예들 들어 2001:0db8:85a3:0000:0000:8a2e:0370:7334입니다.
    • IPv6 CIDR 블록에는 콜론으로 구분된 4개의 16진수 숫자로 구성된 4개의 그룹과 이중 콜론, 1에서 128까지의 슬래시 및 숫자가 뒤따릅니다. 예들 들어 2001:db8:1234:1a00::/64입니다.
  • 경로 테이블을 업데이트하여 IPv6 트래픽을 라우팅합니다. 공용 트래픽의 경우 서브넷에서 VPN Gateway 또는 Azure ExpressRoute 게이트웨이로 모든 IPv6 트래픽을 라우팅하는 경로를 만듭니다.
  • IPv6 주소에 대한 규칙을 포함하도록 보안 그룹 규칙을 업데이트합니다. 이렇게 하면 IPv6 트래픽이 인스턴스를 들어오고 흐를 수 있습니다. 서브넷 간 트래픽 흐름을 제어하는 네트워크 보안 그룹 규칙이 있는 경우 IPv6 트래픽에 대한 규칙을 포함해야 합니다.
  • 인스턴스 유형이 IPv6을 지원하지 않는 경우 이전에 설명한 대로 IPv4에서 IPv6으로 변환되는 이중 스택을 사용하거나 NVA를 배포합니다.

IPAM(IP 주소 관리) 도구

IPAM 도구를 사용하면 중앙 집중식 관리 및 가시성을 제공하여 IP 주소 공간의 겹침 및 충돌을 방지하므로 Azure의 IP 주소 계획을 지원할 수 있습니다. 이 섹션에서는 IPAM 도구를 채택할 때의 필수 고려 사항 및 권장 사항을 안내합니다.

설계 고려 사항:

요구 사항 및 조직의 크기에 따라 다양한 IPAM 도구를 고려할 수 있습니다. 옵션은 기본 Excel 기반 인벤토리를 사용하는 것부터 오픈 소스 커뮤니티 기반 솔루션 또는 고급 기능 및 지원을 제공하는 포괄적인 엔터프라이즈 제품에 이르기까지 다양합니다.

  • 구현할 IPAM 도구를 평가할 때 다음 요소를 고려합니다.

    • 조직에 필요한 최소 기능
    • 라이선스 및 지속적인 기본 테넌스를 포함한 TCO(총 소유 비용)
    • 감사 내역, 로깅 및 역할 기반 액세스 제어
    • Microsoft Entra ID를 통한 인증 및 권한 부여
    • API를 통해 액세스할 수 있음
    • 다른 네트워크 관리 도구 및 시스템과 통합
    • 활성 커뮤니티 지원 또는 소프트웨어 공급자의 지원 수준

  • Azure IPAM과 같은 오픈 소스 IPAM 도구를 평가하는 것이 좋습니다. Azure IPAM은 Azure 플랫폼을 기반으로 하는 경량 솔루션입니다. Azure 테넌트 내에서 IP 주소 사용률을 자동으로 검색하고 중앙 집중식 UI 또는 RESTful API를 통해 모든 IP 주소 사용률을 관리할 수 있습니다.

  • 조직 운영 모델 및 IPAM 도구의 소유권을 고려합니다. IPAM 도구를 구현하는 목표는 종속성 및 병목 상태 없이 애플리케이션 팀에 새 IP 주소 공간을 요청하는 프로세스를 간소화하는 것입니다.

  • IPAM 도구 기능의 중요한 부분은 IP 주소 공간 사용량을 인벤토리에 추가하고 논리적으로 구성하는 것입니다.

디자인 권장 사항:

  • 겹치지 않는 IP 주소 공간을 예약하는 프로세스는 개별 애플리케이션 랜딩 존의 요구에 따라 다양한 크기를 요청해야 합니다.

    • 예를 들어 애플리케이션 팀이 요구 사항을 쉽게 설명할 수 있도록 티셔츠 크기 조정을 채택할 수 있습니다.
      • 작음 - /24 256개 IP 주소
      • 중간 - /22 1,024개 IP 주소
      • 대형 - /20 4,096개 IP 주소

  • IPAM 도구에는 IaC(Infrastructure as Code) 접근 방식을 지원하기 위해 겹치지 않는 IP 주소 공간을 예약하기 위한 API가 있어야 합니다. 또한 이 기능은 IPAM을 구독 자동 판매 프로세스에 원활하게 통합하여 오류의 위험과 수동 개입의 필요성을 줄이는 데 중요합니다.

  • Azure 지역 및 워크로드 아키타입에 따라 구조화하여 IP 주소 공간에 대한 체계적인 정렬을 만들고 클린 추적 가능한 네트워크 인벤토리를 보장합니다.

  • 워크로드에 대한 서비스 해제 프로세스에는 더 이상 사용되지 않는 IP 주소 공간 제거가 포함되어야 하며, 나중에 예정된 새 워크로드에 대해 용도를 변경하여 효율적인 리소스 사용률을 촉진할 수 있습니다.