아웃바운드 엔드포인트 개요

이 문서에서는 Cloud DNS 아웃바운드 엔드포인트를 간략하게 설명합니다. 아웃바운드 엔드포인트를 전달 영역 또는 서버 정책에 연결하여 비공개 IP 주소를 사용해 VPC 네트워크에서 외부 및 온프레미스 DNS 리졸버로 직접 DNS 쿼리 전달을 사용 설정할 수 있습니다. 아웃바운드 엔드포인트를 사용하면 아웃바운드 DNS 트래픽을 세부적으로 제어할 수 있으며 하이브리드 및 멀티 클라우드 DNS 변환 사용 사례를 차단 해제하는 기능이 향상됩니다.

아웃바운드 엔드포인트를 만들고 업데이트하고 전달 영역 또는 서버 정책과 연결하는 방법은 아웃바운드 엔드포인트 만들기 및 업데이트를 참조하세요.

아웃바운드 엔드포인트 기능

아웃바운드 엔드포인트를 사용하면 아웃바운드 DNS 트래픽의 소스 IP 주소를 제어할 수 있으므로 각 네트워크에 고유한 이그레스 범위를 할당하여 VPC 네트워크별 동작을 사용 설정할 수 있습니다. 고유한 이그레스 범위는 기존 고정 전달 프록시 범위의 라우팅 제한사항을 극복합니다.

GKE 클러스터는 호스트 VPC 네트워크로 외부 대상을 쿼리할 때 아웃바운드 엔드포인트를 자동으로 상속합니다. 호스트 VPC 네트워크가 아웃바운드 엔드포인트로 구성된 표준 전역 Cloud DNS 전달 영역 또는 서버 정책에 대해 승인된 경우 VPC DNS 변환을 사용하는 포드는 클러스터 수준 수정이나 영역별 전달 영역 없이 리전 아웃바운드 엔드포인트를 통해 아웃바운드 쿼리를 자동으로 라우팅합니다.

기존 DNS 전달 설정을 아웃바운드 엔드포인트로 마이그레이션하는 방법에 대한 자세한 내용은 기존 Cloud DNS 전달 설정을 아웃바운드 엔드포인트로 마이그레이션을 참조하세요.

아웃바운드 엔드포인트 아키텍처 및 쿼리 라우팅

아웃바운드 엔드포인트는 특정 VPC 네트워크 내에서 생성되며(엔드포인트의 내부 IP 주소에 대해 대상 리전의 일반 서브넷 사용) 소스 IP 주소에 해당 네트워크의 리전 프록시 전용 서브넷을 사용합니다.

아웃바운드 엔드포인트를 전달 영역 또는 서버 정책에 연결하면 Cloud DNS는 먼저 기존 대상 순위 지정 알고리즘을 사용하여 가장 높은 순위의 아웃바운드 엔드포인트를 통해 DNS 쿼리를 라우팅하려고 시도합니다. 해당 엔드포인트가 비정상인 경우 Cloud DNS는 다음으로 순위가 높은 엔드포인트를 시도합니다. 지리적으로 가장 가까운 아웃바운드 엔드포인트가 선호되지만 보장되지는 않습니다.

대상 서버의 순위 지정 알고리즘은 자동으로 수행되며 기존 전달 영역 장애 조치 패턴인 최저 지연 시간 및 오류율 IP 선택을 기반으로 합니다. 다음 요소는 전달 대상의 순위를 높입니다.

  • 전달 대상에서 처리한 성공적인 DNS 응답 수가 더 많습니다. 성공적인 DNS 응답에는 NXDOMAIN 응답도 포함됩니다.
  • 전달 대상과 통신하는 데 지연 시간이 짧습니다.
  • 아웃바운드 엔드포인트까지의 지리적 거리가 짧습니다. 성공 및 지연 시간 데이터를 사용할 수 없는 경우 가장 가까운 대상이 선호됩니다.

리전 중단으로부터 보호하려면 컴퓨팅 워크로드를 실행하는 리전 중 최소 두 곳에서 아웃바운드 엔드포인트를 구성하면 됩니다. 이 접근 방식은 Cloud DNS에 리전 장애 조치 대상을 제공하고 최소 쿼리 지연 시간을 유지합니다. 하이브리드 연결이 일부 리전에서만 프로비저닝된 경우 다른 컴퓨팅 리전의 엔드포인트는 해당 연결을 통해 온프레미스 리졸버에 도달할 수 있습니다.

가장 높은 순위의 엔드포인트가 다른 리전에 있더라도 Cloud DNS는 해당 엔드포인트로 쿼리를 계속 라우팅합니다. 예를 들어 리전 A의 엔드포인트를 사용할 수 없게 되면 트래픽이 리전 B의 정상 엔드포인트로 자동으로 라우팅됩니다. 리전 A의 엔드포인트가 다시 정상 상태가 되면 순위 알고리즘이 성능 개선을 감지하고 향후 쿼리에 대해 다시 선호하기 시작합니다.

리전별 프로젝트당 최대 10개의 아웃바운드 엔드포인트를 사용할 수 있으며 전달 영역 또는 서버 정책에 최대 100개의 아웃바운드 엔드포인트를 연결할 수 있습니다.

리전 온프레미스 리졸버로 쿼리 라우팅

Cloud DNS는 트래픽이 원래 VM과 동일한 리전의 엔드포인트로 전송된다고 보장하지 않지만 위치정보 라우팅 정책을 사용하여 트래픽을 가장 가까운 대상 네임서버로 라우팅할 수 있습니다. Cloud DNS는 원래 쿼리 및 대상 네임서버에 가장 가까운 리전의 아웃바운드 엔드포인트로 트래픽을 우선적으로 라우팅하지만 대상 네임서버의 리전과 아웃바운드 엔드포인트 리전은 긴밀하게 결합되지 않습니다. 위치에 관계없이 Cloud DNS는 지금까지 가장 짧은 지연 시간을 제공한 엔드포인트를 선택합니다.

다음은 쿼리를 리전 온프레미스 리졸버로 라우팅하기 위해 수행해야 하는 작업을 간략하게 보여줍니다.

  • 위치정보 정책을 사용하여 영역 만들기: VPC 네트워크에 승인된 제어하는 FQDN (예: onprem-resolvers.example.com)에 대해 새 Cloud DNS 비공개 영역을 만듭니다. 이 영역에서 온프레미스 DNS 서버 IP에 대한 A 레코드를 만들고 위치정보 라우팅 정책을 적용합니다. 특정 리전에서 소싱된 쿼리에 대해 리졸버 IP를 반환하도록 정책을 구성합니다. 예를 들어 유럽 Google Cloud 리전에서 발생한 쿼리에 대해 유럽 리졸버 IP를 반환합니다.
  • FQDN을 전달 대상으로 사용: 전달 영역에서 방금 만든 FQDN (onprem-resolvers.example.com)을 대상 DNS 서버로 사용합니다.
  • 아웃바운드 엔드포인트 구성: 리전 아웃바운드 엔드포인트(예: 미국 리전의 엔드포인트 1개와 유럽 리전의 엔드포인트 1개)를 이 전달 영역과 연결합니다.

한 리전의 VM이 쿼리를 수행하면 시스템은 2단계 라우팅 프로세스를 따릅니다.

  • 엔드포인트 선택: Cloud DNS는 전달 영역과 연결된 아웃바운드 엔드포인트 목록을 평가하고 최적의 엔드포인트를 선택합니다(예: 유럽의 VM에서 쿼리하는 경우 유럽의 엔드포인트가 선택될 가능성이 높음).
  • 대상 확인: Cloud DNS는 쿼리 원본 리전의 대상 FQDN(onprem-resolvers.example.com)을 확인합니다. 그런 다음 Cloud DNS는 선택한 아웃바운드 엔드포인트를 통해 원래 쿼리를 확인된 DNS 서버 IP로 전달합니다. 위치정보 정책은 쿼리의 소스를 해당 리전으로 식별하고 해당 리전에 구성한 특정 IP 주소를 반환합니다.

자세한 내용은 Cloud DNS FQDN 아웃바운드 DNS 전달 튜토리얼을 참조하세요.

단일 VPC 네트워크에서 로컬 엔드포인트가 없는 리전에서 전달

Google Cloud VPC 네트워크는 여러 리전에 서브넷을 포함할 수 있는 전역 리소스입니다. 아웃바운드 엔드포인트를 구성하지 않은 리전에서 VM이 쿼리를 수행하는 경우에도 전달은 성공합니다. 쿼리는 리전 간에 동일한 VPC 네트워크 내에 존재하고 전달 영역 또는 서버 정책에 구성된 가장 높은 순위의 사용 가능한 아웃바운드 엔드포인트로 라우팅됩니다.

소스 IP 격리를 사용하여 동일한 리전의 여러 VPC 네트워크에서 전달

동일한 리전의 여러 VPC 네트워크에서 쿼리를 전달해야 하고 온프레미스 리졸버가 각 VPC 네트워크의 고유한 소스 IP 주소를 확인해야 하는 경우 다음 단계를 따르세요.

  1. 각 VPC 네트워크에서 아웃바운드 엔드포인트 만들기: 자세한 내용은 아웃바운드 엔드포인트 만들기를 참조하세요.
  2. 각 VPC 네트워크에서 전달 영역 또는 서버 정책 만들기: 해당 VPC 네트워크에 대해서만 전달 영역 또는 서버 정책을 승인하고 해당 VPC 네트워크의 아웃바운드 엔드포인트만 사용합니다.

이 작업을 수행하면 각 VPC 네트워크의 VM이 VPC 네트워크의 아웃바운드 엔드포인트를 통해 쿼리를 전송합니다. 각 엔드포인트는 쿼리를 온프레미스 리졸버로 전달합니다. 온프레미스 네트워크는 각 VPC 네트워크의 프록시 전용 서브넷의 소스 IP 주소를 확인하여 각 네트워크의 트래픽에 서로 다른 구성을 적용할 수 있습니다.

여러 VPC 네트워크 간 통합 전달 (허브 앤 스포크)

다른 중앙 집중식 VPC 네트워크 (허브)에서 아웃바운드 엔드포인트를 사용하도록 전달 영역 또는 서버 정책을 구성할 수 있습니다. Cloud DNS는 내부적으로 쿼리 전달을 처리하므로 허브 네트워크와 쿼리가 시작되는 VPC 네트워크 (스포크) 간에 네트워크 연결이 필요하지 않습니다.

아웃바운드 엔드포인트와 전달 영역 또는 서버 정책의 전달 대상 간에 네트워크 연결을 구성해야 합니다. Cloud Interconnect 또는 Cloud VPN을 사용하여 온프레미스 리졸버에 연결할 수 있습니다. VPC 네트워크 피어링을 사용하여 다른 VPC 네트워크의 전달 대상에 도달할 수 있습니다.

  1. 허브 VPC 네트워크에 아웃바운드 엔드포인트를 만듭니다.
  2. 스포크 VPC 네트워크에서 전달 영역 또는 서버 정책을 만들고 허브 네트워크의 아웃바운드 엔드포인트를 사용하도록 구성합니다.

스포크 VPC 네트워크의 VM은 허브 VPC 네트워크의 아웃바운드 엔드포인트를 통해 쿼리를 전송합니다. 엔드포인트는 쿼리를 온프레미스 리졸버로 전달합니다.

공유 VPC 지원

아웃바운드 엔드포인트는 공유 VPC 배포를 지원합니다. 엔드포인트, 일반 서브넷, 연결된 프록시 전용 서브넷은 호스트 프로젝트에서 중앙에서 생성됩니다. 서비스 프로젝트는 호스트 프로젝트에서 생성된 전달 영역 또는 서버 정책을 상속하거나 자체 비공개 전달 영역 또는 서버 정책을 생성하고 호스트 프로젝트의 중앙 집중식 아웃바운드 엔드포인트에 프로젝트 간에 바인딩할 수 있습니다 (호스트 프로젝트에 dns.outboundEndpoints.bindPrivateDNSZone 또는 dns.outboundEndpoints.bindPrivateDNSPolicy 필요).

아웃바운드 엔드포인트와 연결된 네트워크 리소스 관리

Cloud DNS 아웃바운드 엔드포인트는 기본 VPC 네트워크 및 서브넷과 엄격한 수명 주기 종속 항목을 적용하여 삭제 또는 수정과 같은 우발적인 인프라 변경으로부터 프로덕션 DNS 트래픽을 보호합니다.

아웃바운드 엔드포인트에서 사용 중인 프록시 전용 서브넷 또는 VPC 네트워크 삭제

발신 엔드포인트에서 활성 상태로 사용 중인 일반 서브넷, 프록시 전용 서브넷 또는 VPC 네트워크는 중단을 방지하기 위해 삭제되지 않도록 보호됩니다. 이러한 리소스를 삭제하려고 하면 오류가 발생합니다. 이러한 리소스를 삭제하려면 다음 단계를 정확한 순서대로 수행해야 합니다.

  1. Cloud DNS 구성 업데이트: 아웃바운드 엔드포인트를 사용하는 전달 영역 또는 서버 정책을 수정하고 구성에서 삭제하여 더 이상 사용되지 않도록 합니다.
  2. 아웃바운드 엔드포인트 삭제: 엔드포인트를 더 이상 사용하지 않으면 삭제할 수 있습니다. 이 작업을 수행하면 일반 서브넷 및 프록시 전용 서브넷에 대한 종속 항목이 해제됩니다.
  3. 서브넷 삭제: 다른 리소스가 사용 중이지 않은지 확인한 후 프록시 전용 서브넷과 일반 서브넷을 삭제합니다.
  4. VPC 네트워크 삭제: 다른 모든 VPC 종속 항목이 삭제되면 VPC 네트워크를 삭제할 수 있습니다.

서브넷 수정

아웃바운드 엔드포인트가 프록시 전용 서브넷을 활발하게 사용 중인 경우 프록시 전용 서브넷을 직접 수정할 수 없습니다. 이 제한은 IP 주소 범위와 같은 주요 속성을 수정하지 못하도록 하여 서비스 중단을 방지하는 데 도움이 됩니다. 서브넷을 수정하려면 기존 가이드라인에 따라 먼저 새 서브넷으로 마이그레이션해야 합니다.

아웃바운드 엔드포인트에서 사용 중인 서브넷을 수정하려면 다음을 수행합니다.

  1. 백업 서브넷 만들기: 동일한 VPC 네트워크 및 리전에 새 프록시 전용 서브넷을 만듭니다. 만드는 동안 이 서브넷의 역할을 BACKUP로 설정해야 합니다.
  2. 새 서브넷 활성화: 새 서브넷의 역할을 ACTIVE로 업데이트합니다. 이렇게 하면 원래 서브넷이 BACKUP 역할로 자동으로 설정되고 활성 연결 드레이닝이 시작됩니다.
  3. 드레이닝 대기: 연결 드레이닝 프로세스가 완료될 때까지 기다립니다.
  4. 이전 서브넷 삭제: 이제 원래 서브넷이 BACKUP 역할에 있고 활성 연결이 없으면 삭제할 수 있습니다.

온프레미스 방화벽을 위한 전용 소스 IP 예측 가능성

온프레미스 DNS 방화벽에 DNS 트래픽으로 격리된 전용 및 예측 가능한 소스 IP 주소 범위가 필요한 경우 다음 아키텍처를 적용하는 것이 좋습니다.

  • 전용 이그레스 VPC 네트워크에 배포: 일반 서브넷 (아웃바운드 엔드포인트 IP 주소용)과 Cloud DNS 전용으로 예약된 리전별 프록시 전용 서브넷 (--purpose=REGIONAL_MANAGED_PROXY 및 --role=ACTIVE)이 있는 전용 VPC 네트워크를 만듭니다.
  • 애플리케이션 VPC 네트워크 격리: 애플리케이션 VPC 네트워크를 이 전용 이그레스 네트워크에 피어링하거나 라우팅하지 마세요. Cloud DNS는 Google Cloud인프라 내에서 내부적으로 쿼리를 라우팅하므로 이러한 VPC 네트워크 간의 직접 네트워크 연결이 필요하지 않습니다.
  • 전용 이그레스 VPC 네트워크를 외부 전달 대상에 연결: 전용 이그레스 VPC 네트워크와 외부 또는 온프레미스 대상 네임서버 간에만 연결을 구성합니다. 다음을 사용하여 이 경로를 설정합니다.
    • 기존 전송 VPC에 대한 VPC 네트워크 피어링: 권장되는 접근 방식이며 가장 비용 효율적입니다. 조직에 이미 온프레미스에 대한 Cloud Interconnect 또는 Cloud VPN이 있는 중앙 전송 VPC 네트워크가 있는 경우 전용 DNS VPC 네트워크를 해당 전송 허브에 피어링합니다. 이 접근 방식은 중복 하이브리드 회로 프로비저닝을 방지하고 비용을 최소화합니다.
    • 직접 하이브리드 연결: 전용 DNS VPC 네트워크에서 직접 종료되는 Dedicated Interconnect, Cross-Cloud Interconnect 또는 Cloud VPN.

제한사항

아웃바운드 엔드포인트에는 다음과 같은 제한사항이 있습니다.

  • 소스 IP 및 서브넷 공유가 동일한 리전의 리소스로 제한됨: 아웃바운드 엔드포인트는 연결된 VPC 네트워크의 리전 프록시 전용 서브넷에서 소스 IP 범위를 할당합니다. 표준 배포에서 이 프록시 전용 서브넷은 리전 애플리케이션 부하 분산기와 같은 다른 리전 리소스와 공유될 수 있습니다.

  • 프록시 전용 서브넷에 대한 다이렉트 피어링은 지원되지 않음: 프록시 전용 서브넷과 직접 피어링할 수 없습니다. 외부 네임서버에 대한 네트워크 연결은 Cloud Interconnect, Cloud VPN 또는 VPC 네트워크 피어링과 같은 표준 VPC 라우팅을 통해 설정되어야 합니다.

  • IPv4만 지원: 아웃바운드 엔드포인트의 소스 IP 주소는 IPv4 전용이며 쿼리는 IPv4 주소로 확인되는 전달 영역의 IPv4 대상 또는 FQDN 전달 대상으로만 전달될 수 있습니다.

  • 프로젝트 간 네트워크에 아웃바운드 엔드포인트 바인딩은 지원되지 않음: 호스트 프로젝트의 공유 VPC 네트워크에 연결된 서비스 프로젝트에서 아웃바운드 엔드포인트를 만드는 것은 지원되지 않습니다. 아웃바운드 엔드포인트는 연결되는 VPC 네트워크 및 서브넷과 동일한 프로젝트에 있어야 합니다.

  • 비공개 대상으로 제한: 아웃바운드 엔드포인트는 비공개 대상 (RFC 1918, RFC 6598, --private-forward-targets 또는 forwardingPath: "private"로 구성된 비공개로 라우팅된 비RFC 1918 주소 포함)으로의 전달만 지원하며 공개 인터넷 DNS 트래픽의 이그레스 프록시 또는 정적 소스 IP 앵커로 사용할 수 없습니다. 공개 인터넷 타겟에 대한 쿼리는 Google의 분산 애니캐스트 에지를 통해 직접 확인되어 지연 시간을 최소화하고 Cloud NAT 종속 항목을 방지합니다.

  • 리전 범위: 아웃바운드 엔드포인트는 리전별 리소스입니다. 엔드포인트를 사용하려는 각 리전에 엔드포인트를 만들어야 합니다.

  • 단일 전달 메커니즘만: 전달 메커니즘 (기본 35.199.192.0/19 범위 또는 아웃바운드 엔드포인트)이 전달 영역 또는 서버 정책 수준에서 구성됩니다. 하지만 동일한 영역 또는 정책에 두 방법을 동시에 사용할 수는 없습니다.

다음 단계