정적 경로

이 페이지에서는 Google Cloud에서 정적 경로가 작동하는 방식을 간략히 설명합니다.

Google Cloud의 경로에 관한 일반적인 개요는 경로 개요를 참조하세요.

정적 경로 만들기 고려사항

정적 경로는 다음 두 가지 방법 중 하나로 만들 수 있습니다.

• Google Cloud 콘솔, gcloud compute routes create, routes.insert API를 사용하여 수동으로 정적 경로를 만들 수 있습니다.

• Google Cloud 콘솔을 사용하여 동적 라우팅을 사용하지 않는 기본 VPN 터널을 만드는 경우 Cloud VPN에서 해당 정적 경로를 자동으로 만들 수 있습니다. 자세한 내용은 Cloud VPN 네트워크 및 터널 라우팅을 참조하세요.

VPC 네트워크 피어링 문서의 커스텀 정적 경로 교환 옵션에 설명된 대로 정적 경로를 피어링된 VPC 네트워크로 바꿀 수 있습니다.

경로 매개변수

정적 경로는 다음 속성을 지원합니다.

• 이름 및 설명. 이 필드는 경로를 식별합니다. 이름은 필수사항이지만 설명은 선택사항입니다. 프로젝트의 모든 경로에는 고유한 이름이 있어야 합니다.

• 네트워크. 각 경로는 정확히 하나의 VPC 네트워크와 연결되어야 합니다.

• 다음 홉. 다음 홉은 패킷을 전송할 네트워크 리소스를 식별합니다. 모든 다음 홉 유형은 IPv4 대상을 지원하고 일부 다음 홉 유형은 IPv6 대상을 지원합니다. 자세한 내용은 다음 홉과 기능을 참조하세요.

• 대상 범위. 대상 범위는 단일 IPv4 또는 IPv6 CIDR 표기법입니다.

  정적 경로의 대상은 정적 경로와의 상호작용 및 서브넷 및 정적 경로 상호작용에 설명된 규칙을 따라야 합니다. IPv4 정적 경로에 사용할 수 있는 가장 광범위한 대상 위치는 0.0.0.0/0입니다. IPv6 정적 경로에 사용할 수 있는 가장 광범위한 대상 위치는 ::/0입니다.

• 우선순위. 더 낮은 숫자가 높은 우선순위를 나타냅니다. 가능한 최고 우선순위는 0이고 가능한 최저 우선순위는 65,535입니다.

• 네트워크 태그. 네트워크 태그로 식별된 VPC 네트워크의 VM 인스턴스만 선택하도록 정적 경로를 적용할 수 있습니다. 네트워크 태그를 지정하지 않으면 Google Cloud는 네트워크의 모든 인스턴스에 정적 경로를 적용합니다. VPC 네트워크 피어링을 사용할 때는 태그가 포함된 정적 경로가 절대 교환되지 않습니다.

다음 홉과 기능

다음 표에서는 다음 홉 유형별로 지원되는 정적 경로 기능을 요약해서 보여줍니다.

다음 홉 프로젝트와 네트워크

정적 경로 다음 홉은 VPC 네트워크 및 프로젝트와 모두 연관되어 있습니다.

• 네트워크: 아래 표에 표시된 것을 제외하고 다음 홉의 VPC 네트워크는 경로의 VPC 네트워크와 일치해야 합니다.

• 프로젝트: 아래 표에 표시된 경우를 제외하고 다음 홉은 다음 홉의 VPC 네트워크를 포함하는 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트)에 있어야 합니다. 일부 다음 홉은 공유 VPC 서비스 프로젝트에 배치될 수 있습니다.

인스턴스 및 내부 패스 스루 네트워크 부하 분산기 다음 홉에 일반적인 고려사항

인스턴스 기반 라우팅은 다음 홉이 VM 인스턴스(next-hop-instance 또는 next-hop-address)인 정적 경로를 나타냅니다.

다음 홉으로서의 내부 패스 스루 네트워크 부하 분산기는 다음 홉이 내부 패스 스루 네트워크 부하 분산기(next-hop-ilb)인 정적 경로를 나타냅니다.

인스턴스 기반 라우팅 또는 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 구성할 때 다음 가이드라인을 고려하세요.

• 백엔드 VM 또는 다음 홉 인스턴스에서 모든 소스 IP 주소의 패킷을 전달하도록 구성해야 합니다. 전달을 구성하려면 VM을 만들 때 VM별로 IP 전달을 사용 설정(can-ip-forward)하세요. 관리형 인스턴스 그룹의 일부로 자동 생성된 VM의 경우에는 인스턴스 그룹이 사용하는 인스턴스 템플릿에서 IP 전달을 사용 설정해야 합니다. 패킷을 라우팅하는 데 필요한 운영체제 구성 외에 이 구성을 추가로 변경해야 합니다.

• 백엔드 VM 또는 다음 홉 인스턴스에서 실행되는 소프트웨어를 적절하게 구성해야 합니다. 예를 들어 라우터 또는 방화벽으로 작동하는 타사 어플라이언스 VM은 제조업체의 안내에 따라 구성되어야 합니다.

• 백엔드 VM 또는 다음 홉 인스턴스에 적절한 방화벽 규칙이 있어야 합니다. 라우팅되는 패킷에 적용되는 방화벽 규칙을 구성해야 합니다. 다음 사항에 유의하세요.

  • 라우팅 기능을 수행하는 인스턴스에 적용되는 인그레스 방화벽 규칙에는 라우팅된 패킷 소스의 IP 주소가 포함되어야 합니다. 묵시적 인그레스 거부 규칙은 들어오는 패킷을 모두 차단하므로 최소한 커스텀 인그레스 허용 방화벽 규칙을 만들어야 합니다.
  • 라우팅 함수를 수행하는 인스턴스에 적용 가능한 이그레스 방화벽 규칙에는 라우팅된 패킷 대상의 IP 주소가 포함되어야 합니다. 묵시적 이그레스 허용 규칙은 이 규칙보다 우선하는 명확한 이그레스 거부 규칙을 생성하지 않는 한 이를 허용합니다.
  • 방화벽 규칙을 만들 때 백엔드 VM 또는 다음 홉 인스턴스가 네트워크 주소 변환(NAT)을 수행하는지 여부를 고려하세요.

  자세한 내용은 묵시적 방화벽 규칙을 참조하세요.

• 백엔드 VM 또는 다음 홉 인스턴스에서 전송한 패킷의 소스 리전은 백엔드 VM 또는 다음 홉 인스턴스가 있는 리전입니다. 예를 들어 us-west1의 백엔드 VM이나 다음 홉 인스턴스에서 처리하는 패킷은 백엔드 VM 또는 다음 홉 인스턴스가 원래 us-west1에서 다른 리전의 리소스로부터 패킷을 수신했더라도 us-west1에서만 액세스할 수 있는 대상으로 전송될 수 있습니다. 패킷을 전송하는 VM과 동일한 리전에서만 액세스할 수 있는 리소스의 예시에는 다음이 포함됩니다.

  • 전역 액세스가 해제된 내부 패스 스루 네트워크 부하 분산기, 내부 애플리케이션 부하 분산기, 리전 내부 프록시 네트워크 부하 분산기
  • VPC 네트워크가 리전별 동적 라우팅을 사용하는 경우 Cloud VPN 터널, Cloud Interconnect VLAN 연결, Network Connectivity 라우터 어플라이언스 VM

다음 홉 인스턴스에 대한 고려사항

• 인스턴스 이름 및 영역별 다음 홉(next-hop-instance): 인스턴스 이름과 영역으로 지정된 다음 홉 인스턴스가 있는 정적 경로를 만들 경우 Google Cloud를 사용하려면 해당 이름의 인스턴스가 지정된 영역에 있고 다음을 충족해야 합니다.

  • 인스턴스는 경로와 동일한 프로젝트에 있습니다.
  • 인스턴스에는 경로의 VPC 네트워크(피어링된 VPC 네트워크 아님)에 네트워크 인터페이스(NIC)가 있습니다.

  정적 경로가 있으면 다음이 적용됩니다.

  • Google Cloud는 다음 중 하나에 해당하는 경우 다음 홉에 대한 프로그래밍을 자동으로 업데이트합니다.

    • 다음 홉 인스턴스의 기본 내부 IPv4 주소가 변경되거나
    • 다음 홉 인스턴스를 바꾸면 교체 인스턴스 이름이 같고 같은 영역과 프로젝트에 있으며 경로의 VPC 네트워크에 네트워크 인터페이스가 있습니다.

  • Google Cloud는 다음과 같은 경우에 다음 홉에 대한 프로그래밍을 업데이트하지 않습니다.

    • 인스턴스가 삭제된 경우
    • 인스턴스의 NIC에 할당된 IPv6 주소 범위가 변경된 경우
    • 인스턴스의 IPv4 또는 IPv6 주소가 할당 취소된 경우

• 다음 홉 인스턴스 IP 주소(next-hop-address): 유효한 다음 홉 VM IP 주소는 다음과 같습니다.
  • VM 네트워크 인터페이스의 기본 내부 IPv4 주소
  • VM 네트워크 인터페이스에 할당된 /96 IPv6 주소 범위의 모든 내부 또는 외부 IPv6 주소

  IP 주소로 지정된 다음 홉 인스턴스를 사용하여 정적 경로를 만들면 Google Cloud는 경로와 동일한 VPC 네트워크에 있는 서브넷의 서브넷 범위에 속하는 VM이 할당한 IP 주소를 허용합니다. 그러나 Google Cloud는 다음 홉 주소가 유효한 다음 홉 VM IP 주소인 경우에만 경로를 프로그래밍합니다. 예를 들어 경로를 만들고 다음 홉을 별칭 IP 범위에서 제공되는 IP 주소로 지정하면 경로가 생성됩니다. 하지만 별칭 IP 주소는 유효한 다음 홉 VM IP 주소가 아니므로 경로는 프로그래밍되지 않습니다.

  다음 홉 IP 주소가 다른 VM으로 이동하고 IP 주소에 유효한 다음 홉 VM IP 주소가 남아 있으면 Google Cloud는 다음 홉에 대한 프로그래밍을 자동으로 업데이트합니다.

  IP 주소로 다음 홉 인스턴스를 지정하면 패킷이 특정 IP 주소가 아닌 인스턴스의 네트워크 인터페이스로 라우팅됩니다.

• 공유 VPC 서비스 프로젝트의 다음 홉 인스턴스: IP 주소로 다음 홉 VM을 지정하면 해당 VM이 경로와 동일한 프로젝트(독립 실행형 프로젝트 또는 공유 VPC 호스트 프로젝트)에 위치하거나 또는 공유 VPC 서비스 프로젝트에 위치할 수 있습니다. 인스턴스 이름 및 영역에 따라 다음 홉 VM을 지정할 때 다음 홉 VM은 경로 및 VPC 네트워크와 동일한 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트)에 있어야 합니다.

• 리전 간 비용 및 지연 시간: VM을 다음 홉으로 사용하면 다음 홉은 리전의 영역에 있습니다. 다음 홉을 사용하는 경로는 동일한 VPC 네트워크의 모든 인스턴스에서 사용할 수 있거나 일치하는 네트워크 태그가 있는 인스턴스를 선택할 수 있습니다. Google Cloud는 인스턴스를 다음 홉으로 사용하는 경로의 리전 거리를 고려하지 않으므로 트래픽을 다른 리전의 다음 홉 VM으로 전송하는 경로를 만들 수 있습니다. 한 리전에서 다른 리전으로 패킷을 전송하면 아웃바운드 데이터 전송 비용이 추가되고 네트워크 지연 시간이 발생합니다.

• 상태 점검, 구성 검증 없음: Google Cloud는 다음 홉 인스턴스가 인스턴스 및 내부 패스 스루 네트워크 부하 분산기 다음 홉에 일반적인 고려사항 섹션에 설명된 모든 요구 사항을 충족하는지 확인하지 않습니다. 인스턴스 게스트 운영체제를 구성하여 VM 네트워크 인터페이스를 중지해도 Google Cloud은 다음 홉 인스턴스를 무시하지 않습니다.

• VPC 네트워크 2개를 연결할 때 대칭 해싱 없음: 다음 기준을 모두 충족하는 구성에서 네트워크 인터페이스가 여러 개 있는 다음 홉 VM을 2개 이상 사용할 때 Google Cloud는 대칭 해싱을 제공하지 않습니다.

  • VM은 하나의 VPC 네트워크에 하나의 네트워크 인터페이스를 포함하고 두 번째 VPC 네트워크에 다른 인터페이스를 포함합니다.
  • 각 VPC 네트워크에는 동일한 우선순위를 사용하여 동일한 대상에 2개 이상의 커스텀 정적 경로 집합이 있습니다. 이때 집합의 각 경로는 고유한 다음 홉 VM을 참조합니다.

  인터페이스가 여러 개 있는 VM을 2개 이상 사용하여 VPC 네트워크에 연결하고 같은 VM에서 특정 연결에 대한 패킷을 양방향으로 처리해야 하는 경우 다음 홉 내부 패스 스루 네트워크 부하 분산기에서만 지원하는 대칭 해싱이 필요합니다. 자세한 내용은 대칭 해싱을 참조하세요.

• 인스턴스가 중지 또는 삭제될 때의 동작: Google Cloud는 이름과 영역 또는 내부 주소로 지정된 정적 경로 다음 홉 VM 중지나 삭제를 방지하지 않습니다. 다음 홉 VM이 실행되지 않는 경우 라우팅은 정확히 동일한 대상에 대한 다른 경로가 있는지 여부와 다른 경로에 실행 중인 다음 홉이 있는지 여부에 따라 달라집니다. 이 동작을 설명하려면 다음 예시를 살펴보세요.

  • 다음과 같은 경로와 VM 상태가 있습니다.

    • route-a, 대상 192.168.168.0/24, 우선순위 10, 다음 홉 VM vm-a 중지됨
    • route-b, 대상 192.168.168.0/24, 우선순위 20, 다음 홉 VM vm-b 실행 중
    • route-c, 대상 192.168.168.0/24, 우선순위 30, 다음 홉 VM vm-c 실행 중

    이 예시에서 대상이 192.168.168.0/24에 해당하는 패킷은 우선순위가 가장 높은 route-a의 vm-a 다음 홉이 실행되지 않으므로 vm-b 다음 홉으로 전송됩니다. 이는 Google Cloud 라우팅 순서에서 사용할 수 없는 다음 홉이 있는 정적 및 동적 경로 무시 단계가 우선순위가 낮은 경로 무시 단계보다 먼저 적용되기 때문입니다.

  • 다음과 같은 경로와 VM 상태가 있습니다.

    • route-x, 대상 192.168.168.0/24, 우선순위 10, 다음 홉 VM vm-x 중지됨
    • route-y, 대상 192.168.168.0/24, 우선순위 20, 다음 홉 VM vm-y 중지됨
    • route-z, 대상 192.168.0.0/16, 우선순위 0, 다음 홉 VM vm-z 실행 중

    이 예에서 대상이 192.168.168.0/24에 해당하는 패킷은 두 개의 192.168.168.0/24 경로 (route-x 및 route-y)의 다음 홉 VM이 실행되지 않기 때문에 삭제됩니다. 하지만 더 광범위한 192.168.0.0/16 대상에 대한 경로 (route-z)가 있고 이 경로의 다음 홉 VM이 실행 중입니다. 이는 Google Cloud 라우팅 순서에서 가장 구체적인 대상 단계가 사용할 수 없는 다음 홉이 있는 정적 및 동적 경로 무시 단계보다 먼저 적용되기 때문입니다.

내부 패스 스루 네트워크 부하 분산기 다음 홉에 대한 고려사항

• 지원되는 전달 규칙. Google Cloud는 다음 홉 내부 패스 스루 네트워크 부하 분산기 전달 규칙만 지원합니다. Google Cloud는 다른 부하 분산기, 프로토콜 전달, Private Service Connect 엔드포인트에서 사용되는 다음 홉 전달 규칙을 지원하지 않습니다.

• 사양 메서드 및 전달 규칙 네트워크 및 프로젝트. 다음 세 가지 방법 중 하나를 사용해서 다음 홉 전달 규칙을 지정할 수 있습니다. 사용하는 사양 메서드에 따라 전달 규칙의 네트워크가 경로의 네트워크와 일치해야 하는지 여부와 전달 규칙이 배치할 수 있는 프로젝트가 결정됩니다.

  다음 방법 중 하나를 선택하고 전달 규칙의 IP 버전이 만든 정적 경로의 IP 버전과 일치하는지 확인합니다.

  • 전달 규칙 이름(--next-hop-ilb) 및 리전(--next-hop-ilb-region): 이름 및 리전별로 다음 홉 전달 규칙을 지정할 때 전달 규칙의 네트워크는 경로의 VPC 네트워크와 일치해야 합니다. 전달 규칙은 전달 규칙의 네트워크가 포함된 동일한 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트)에 있어야 합니다.

  • 전달 규칙 리소스 링크별: 전달 규칙의 리소스 링크는 /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME 형식을 사용합니다. PROJECT_ID는 전달 규칙을 포함하는 프로젝트의 프로젝트 ID, REGION은 전달 규칙의 리전, FORWARDING_RULE_NAME은 전달 규칙의 이름입니다. 해당 리소스 링크로 다음 홉 전달 규칙을 지정할 때는 전달 규칙의 네트워크가 경로의 VPC 네트워크와 일치해야 합니다. 전달 규칙은 전달 규칙의 네트워크가 포함된 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트) 또는 공유 VPC 서비스 프로젝트 중 하나에 위치할 수 있습니다.

  • 전달 규칙 IP 주소 기준: IPv4 또는 IPv6(미리보기) 주소로 다음 홉 전달 규칙을 지정하는 경우 전달 규칙의 네트워크는 경로의 VPC 네트워크 또는 피어링된 VPC 네트워크 중 하나가 될 수 있습니다. 전달 규칙은 전달 규칙의 네트워크가 포함된 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트) 또는 공유 VPC 서비스 프로젝트 중 하나에 위치할 수 있습니다.

• 전역 액세스의 영향. 내부 패스 스루 네트워크 부하 분산기 다음 홉을 사용하는 커스텀 정적 경로는 모든 리전에서 프로그래밍됩니다. 다음 홉의 사용 가능 여부는 부하 분산기의 전역 액세스 설정에 따라 다릅니다. 전역 액세스를 사용 설정하면 VPC 네트워크의 모든 리전에서 부하 분산기 다음 홉에 액세스할 수 있습니다. 전역 액세스가 중지된 경우 부하 분산기와 동일한 리전에서만 부하 분산기 다음 홉에 액세스할 수 있습니다. 전역 액세스가 중지되면 다른 리전에서 내부 패스 스루 네트워크 부하 분산기 다음 홉을 사용하는 경로로 전송된 패킷이 삭제됩니다.

• 모든 백엔드가 비정상일 경우. 내부 패스 스루 네트워크 부하 분산기의 모든 백엔드에서 상태 점검에 실패해도 이 부하 분산기 다음 홉을 사용하는 경로가 계속 적용됩니다. 경로를 통해 처리된 패킷은 트래픽 분산에 따라 다음 홉 부하 분산기의 백엔드 중 하나로 전송됩니다.

• 공통 내부 IP 주소(--purpose=SHARED_LOADBALANCER_VIP)를 사용하는 전달 규칙은 지원되지 않음. 다음 홉 내부 패스 스루 네트워크 부하 분산기 및 공통 IP 주소를 사용하는 내부 패스 스루 네트워크 부하 분산기 전달 규칙은 상호 배타적인 기능입니다. 다음 홉 내부 패스 스루 네트워크 부하 분산기는 하나의 백엔드 서비스(하나의 부하 분산기)만 명확하게 참조되도록 부하 분산기의 전달 규칙에 고유한 IP 주소를 사용해야 합니다. 공통 내부 IP 주소를 사용하는 전달 규칙이 다양한 백엔드 서비스(다른 내부 패스 스루 네트워크 부하 분산기)를 참조할 수 있습니다.

• 대상 및 우선순위가 동일하지만 다음 홉 내부 패스 스루 네트워크 부하 분산기가 다른 여러 경로. Google Cloud에서는 ECMP를 사용하여 2개 이상의 다음 홉 내부 패스 스루 네트워크 부하 분산기 간에 트래픽을 분산하지 않습니다. 대신 Google Cloud에서는 확정 내부 알고리즘을 사용하여 다음 홉 내부 패스 스루 네트워크 부하 분산기를 하나만 선택합니다. 이러한 모호함을 피하기 위해 각 경로에 고유한 네트워크 태그를 사용할 수 있습니다.

  

• 대상, 우선순위, 다음 홉 내부 패스 스루 네트워크 부하 분산기가 동일한 여러 경로 네트워크 태그를 사용하지 않으면 Google Cloud에서는 대상, 우선순위, 내부 패스 스루 네트워크 부하 분산기 다음 홉의 조합이 동일한 여러 정적 경로를 만들 수 없습니다. 네트워크 태그를 사용하면 대상, 우선순위, 내부 패스 스루 네트워크 부하 분산기 다음 홉의 조합이 동일한 여러 정적 경로를 만들 수 있습니다.

기본 VPN 터널의 다음 홉에 대한 고려사항

• 리전 간 비용 및 지연 시간: Google Cloud는 다음 홉 기본 VPN 터널을 사용하는 경로의 리전 거리를 고려하지 않습니다. 다른 리전의 다음 홉 기본 VPN 터널로 트래픽을 전송하면 아웃바운드 데이터 전송 비용이 추가되고 네트워크 지연 시간이 발생합니다. 동적 라우팅 대신 HA VPN 터널을 사용하는 것이 가장 좋습니다. 해당 구성은 리전 거리를 고려하기 때문입니다.

• 기본 VPN 터널이 실행되지 않을 때의 동작: 다음 홉이 기본 VPN 터널인 커스텀 정적 경로는 기본 VPN 터널이 실행 중이 아니면 자동으로 삭제되지 않습니다. 터널이 실행되지 않을 때 발생하는 결과에 대한 자세한 내용은 기본 VPN 문서의 터널이 작동 중지되는 경우를 참조하세요.

다음 단계

• 경로를 만들고 관리하려면 경로 사용을 참조하세요.
• Google Cloud 경로에 대한 일반적인 개요는 경로를 참조하세요.