경로

Google Cloud 경로는 네트워크 트래픽이 가상 머신(VM) 인스턴스에서 다른 대상 위치로 이동하는 경로를 정의합니다. 이러한 대상 위치는 Google Cloud Virtual Private Cloud(VPC) 네트워크 내부(예를 들어 다른 VM) 또는 외부에 있을 수 있습니다.

VPC 네트워크에서 경로는 CIDR 형식의 단일 대상 위치 프리픽스와 단일 다음 홉으로 구성됩니다. VPC 네트워크의 인스턴스가 패킷을 전송하면 패킷의 대상 위치 주소가 경로의 대상 범위 내에 있는 경우 Google Cloud가 패킷을 경로의 다음 홉으로 전달합니다.

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

Google Cloud의 라우팅

모든 VPC 네트워크는 확장 가능한 분산형 가상 라우팅 메커니즘을 사용합니다. 네트워크에 할당된 실제 기기가 없습니다. 일부 경로를 선택적으로 적용할 수도 있지만, VPC 네트워크의 라우팅 테이블이 VPC 네트워크 수준에서 정의됩니다.

각 VM 인스턴스에는 네트워크의 라우팅 테이블의 모든 적용 가능한 경로에 대한 정보를 유지하는 컨트롤러가 있습니다. VM에서 나가는 각 패킷은 라우팅 순서에 따라 적용 가능한 경로의 적절한 다음 홉으로 전달됩니다. 경로를 추가하거나 삭제하면 변경사항이 eventual consistency를 가진 설계를 사용하여 VM 컨트롤러로 전파됩니다.

경로 유형

다음 표에는 Google Cloud가 VPC 네트워크의 경로를 분류하는 방법이 요약되어 있습니다.

시스템 생성 기본 경로

기본 경로의 가능한 가장 광범위한 대상 위치는 IPv4의 경우 0.0.0.0/0, IPv6의 경우 ::/0입니다. Google Cloud는 패킷이 라우팅 순서의 더욱 구체적인 경로와 일치하지 않는 경우에만 기본 경로를 사용하여 패킷을 전달합니다.

외부 패스 스루 네트워크 부하 분산기 및 외부 프로토콜 전달의 특수 라우팅 경로가 기본값에 따라 달라지지 않으므로 기본 경로가 없어도 인터넷에서 네트워크를 격리할 필요가 없습니다.

VPC 네트워크를 만들면 Google Cloud에서 시스템 생성 IPv4 기본 경로를 VPC 네트워크에 추가합니다. 시스템 생성 IPv4 기본 경로는 0.0.0.0/0 대상과 기본 인터넷 게이트웨이 다음 홉이 있는 로컬 정적 경로입니다. 0.0.0.0/0 대상 및 기본 인터넷 게이트웨이 다음 홉이 있는 로컬 정적 경로는 인터넷의 IPv4 주소를 포함하여 외부 IPv4 주소 경로를 제공합니다. 다음 예시 리소스에서 이 경로를 사용합니다.

• 전송하는 패킷에 네트워크 인터페이스 기본 내부 IPv4 주소와 일치하는 소스가 있는 경우 네트워크 인터페이스에 할당된 외부 IPv4 주소가 있는 VM
• VM 네트워크 인터페이스에서 사용하는 서브넷에 NAT 서비스를 제공하도록 구성된 공개 Cloud NAT 게이트웨이 Cloud NAT 게이트웨이가 제공하도록 구성된 서브넷 IPv4 주소 범위에 따라 패킷 소스가 다음 중 하나와 일치할 수 있습니다.
  • VM 네트워크 인터페이스 별칭 IP 주소 범위의 내부 IPv4 주소(네트워크 인터페이스에 외부 IPv4 주소가 있는지 여부) 또는
  • 네트워크 인터페이스에 외부 IPv4 주소가 할당되지 않은 경우 VM 네트워크 인터페이스의 기본 내부 IPv4 주소

외부 IPv6 주소 범위가 있는 서브넷을 만들면 Google Cloud에서 시스템 생성 IPv6 기본 경로를 VPC 네트워크에 추가합니다(아직 없는 경우). 시스템 생성 IPv6 기본 경로는 ::/0 대상과 기본 인터넷 게이트웨이 다음 홉이 있는 로컬 정적 경로입니다. ::/0 대상과 기본 인터넷 게이트웨이 다음 홉이 있는 로컬 정적 경로는 인터넷의 IPv6 주소를 포함하여 외부 IPv6 주소 경로를 제공합니다. 다음에서 이 경로를 사용할 수 있습니다.

• 전송하는 패킷에 /96 주소 범위 내 소스가 있는 경우 네트워크 인터페이스에 할당된 /96 외부 IPv6 주소 범위를 갖는 VM

전역 Google API에 액세스하는 방법은 기본 인터넷 게이트웨이 다음 홉을 사용하는 로컬 IPv4 또는 IPv6 기본 경로에 따라 달라지는 경우가 있습니다.

• 패킷을 전역 Google API의 Private Service Connect 엔드포인트로 전송하여 전역 Google API 및 서비스에 액세스하는 경우에는 VPC 네트워크에 기본 인터넷 게이트웨이 다음 홉이 있는 기본 경로가 필요하지 않습니다. Google Cloud는 특수 라우팅 경로를 엔드포인트에 추가합니다.

• 패킷을 기본 도메인의 IPv4 또는 IPv6 주소로,private.googleapis.com의 IPv4 또는 IPv6 주소로 또는 restricted.googleapis.com의 IPv4 또는 IPv6 주소로 전송하여 전역 Google API 및 서비스에 액세스하는 경우 기본 인터넷 게이트웨이 다음 홉이 있는 기본 IPv4 및 IPv6 경로를 사용하거나 더욱 구체적인 대상과 기본 인터넷 게이트웨이 다음 홉이 있는 IPv4 및 IPv6 정적 경로를 만들어 사용할 수 있습니다.

  • VM에 내부 IP 주소만 있는 경우 비공개 Google 액세스의 라우팅 옵션을 참조하세요.
  • VM에 외부 IP 주소가 있는 경우 라우팅 옵션을 참조하세요.

서브넷 경로

서브넷 경로는 VPC 네트워크의 VM 및 내부 부하 분산기와 같은 리소스의 경로를 정의합니다.

각 서브넷에는 대상 위치가 서브넷의 기본 IPv4 범위와 일치하는 서브넷 경로가 하나 이상 있습니다. 서브넷에 보조 IP 범위가 있는 경우 각 보조 IP 주소 범위에 해당하는 서브넷 경로가 있습니다. 서브넷에 IPv6 범위가 있는 경우 IPv6 주소 범위에 해당하는 서브넷 경로가 있습니다. 서브넷 IP 범위에 대한 자세한 내용은 서브넷을 참조하세요.

VPC 네트워크에는 다음과 같은 유형의 서브넷 경로가 포함될 수 있습니다.

• 같은 VPC 네트워크에 있는 서브넷의 서브넷 경로(로컬 서브넷 경로라고 함)
• VPC 네트워크 피어링을 사용하여 연결된 네트워크에서 가져오는 피어링 서브넷 경로
• Network Connectivity Center 허브의 VPC 스포크에서 가져오는 Network Connectivity Center 서브넷 경로

정적 경로와의 상호작용

해당 서브넷이 하이브리드 서브넷으로 구성되지 않는 한 Google Cloud는 로컬 서브넷 경로, 피어링 서브넷 경로, Network Connectivity Center 서브넷 경로에 다음 규칙을 적용합니다.

• 새 정적 경로 대상이 기존 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로의 대상과 정확하게 일치하거나 대상에 속하는 경우 Google Cloud를 사용하여 새 정적 경로를 만들 수 없습니다. 예를 들면 다음과 같습니다.

  • 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로가 10.70.1.0/24 대상과 함께 있으면 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 또는 10.70.1.0/24에 속하는 다른 대상의 새로운 정적 경로를 만들 수 없습니다.

  • 2001:0db8:0a0b:0c0d::/64 대상과 함께 로컬 또는 피어링 서브넷 경로가 있으면 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 또는 2001:0db8:0a0b:0c0d::/64에 속하는 다른 대상의 새로운 정적 경로를 만들 수 없습니다.

• Google Cloud를 사용하여 기존 로컬 또는 피어링 정적 경로의 대상과 정확하게 일치하거나 이를 포함하는 서브넷 IP 주소 범위가 발생하는 서브넷을 변경할 수 없습니다. 예를 들면 다음과 같습니다.

  • VPC 네트워크에 10.70.1.128/25 대상이 있는 정적 경로가 있으면 10.70.1.128/25, 10.70.1.0/24의 기본 및 보조 IPv4 주소 범위 또는 10.70.1.128/25의 모든 IPv4 주소가 포함된 다른 IP 주소 범위가 있는 새로운 서브넷을 만들 수 없습니다.

  • VPC 네트워크에 2001:db8:a0b:c0d:e0f:f0e::/96 대상이 있는 정적 경로가 있으면 Google Cloud에서 2001:db8:a0b:c0d::/64의 IPv6 주소 범위 또는 2001:db8:a0b:c0d:e0f:f0e::/96의 모든 IPv6 주소가 포함된 다른 범위가 있는 새로운 로컬 또는 피어링 서브넷 경로 생성을 금지합니다.

동적 경로와의 상호작용

서브넷이 하이브리드 서브넷으로 구성되지 않는 한 Google Cloud는 다음 규칙을 적용합니다.

• 프리픽스가 기존 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로의 대상과 정확하게 일치하거나 대상에 속하는 경우 Google Cloud는 Cloud Router의 BGP 세션에서 학습된 프리픽스의 동적 경로를 만들지 않습니다. 예를 들면 다음과 같습니다.

  • 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로가 10.70.1.0/24 대상과 함께 있고 VPC 네트워크나 피어링된 VPC 네트워크의 Cloud Router에서 10.70.1.128/25, 10.70.1.0/24 또는 10.70.1.0/24에 속하는 다른 프리픽스를 수신한 경우 Google Cloud는 수신된 충돌하는 프리픽스의 로컬 또는 피어링 동적 경로를 만들지 않습니다.

  • 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로가 2001:0db8:0a0b:0c0d::/64 대상과 함께 있고 VPC 네트워크나 피어링된 VPC 네트워크의 Cloud Router에서 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 또는 2001:0db8:0a0b:0c0d::/64에 속하는 다른 프리픽스를 수신한 경우 Google Cloud는 수신된 충돌하는 프리픽스의 로컬 또는 피어링 동적 경로를 만들지 않습니다.

• 서브넷 변경으로 인해 대상이 기존 로컬 또는 피어링 동적 경로 대상과 정확하게 일치하거나 이를 포함하는 새로운 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로가 생성되면 Google Cloud는 기존 로컬 또는 피어링 동적 경로를 삭제합니다. 예를 들면 다음과 같습니다.

  • VPC 네트워크에 10.70.1.128/25 대상이 있는 로컬 또는 피어링 동적 경로가 있으면 10.70.1.128/25, 10.70.1.0/24 또는 10.70.1.128/25의 모든 IPv4 주소가 포함된 다른 IP 주소 범위의 새로운 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로가 생성되면 Google Cloud에서 동적 경로를 삭제합니다.

  • VPC 네트워크에 2001:db8:a0b:c0d::/96 대상이 있는 로컬 또는 피어링 동적 경로가 있으면 2001:db8:a0b:c0d::/64의 새 로컬, 피어링 또는 Network Connectivity Center 서브넷 경로가 생성될 때 Google Cloud에서 동적 경로를 삭제합니다.

서브넷 경로의 수명 주기

기본 IPv4 주소 범위, 보조 IPv4 주소 범위, IPv6 주소 범위 등 서브넷 일부인 모든 IP 주소 범위에는 해당하는 서브넷 경로가 있습니다. Google Cloud는 다음 시나리오에서 서브넷 경로를 만들고 삭제합니다.

• 서브넷 구성을 변경합니다. 예를 들면 다음과 같습니다.

  • 서브넷을 추가하거나 삭제합니다.
  • 기본 IPv4 범위를 확장합니다.
  • 보조 IPv4 범위를 추가하거나 삭제합니다.
  • IPv6 범위를 추가하거나 삭제합니다.

• Google Cloud는 새 리전을 추가하여 자동으로 새 서브넷을 자동 모드 네트워크에 추가합니다.

동적 경로

Cloud Router는 수신된 경계 게이트웨이 프로토콜(BGP) 메시지, 적용 가능한 BGP 경로 정책(미리보기), 사용자가 구성한 Cloud Router 커스텀 학습 경로를 기반으로 VPC 네트워크에 동적 경로를 생성, 업데이트, 삭제하도록 지시합니다. Cloud Router 제어 영역은 VPC 네트워크의 동적 라우팅 모드에 따라 리전별로 동적 경로를 설치합니다.

• VPC 네트워크가 리전별 동적 라우팅 모드를 사용하는 경우 각 리전의 Cloud Router는 Cloud Router와 동일한 리전에서만 동적 경로를 만듭니다.

• VPC 네트워크가 전역 동적 라우팅 모드를 사용하는 경우 각 리전의 Cloud Router는 VPC 네트워크의 모든 리전에 동적 경로를 만듭니다.

동적 경로의 다음 홉은 다음 중 하나일 수 있습니다.

• Dedicated Interconnect 연결 또는 Partner Interconnect 연결로 지원되는 VLAN 연결

• Cloud VPN 터널, HA VPN 터널 또는 동적 라우팅을 사용하도록 구성된 기본 VPN

• Network Connectivity Center의 라우터 어플라이언스 VM 인스턴스

동적 경로의 다음 홉에 액세스할 수 없는 경우 BGP 세션을 관리하는 Cloud Router는 다음 조건 중 하나가 충족되면 VPC 네트워크에 동적 경로를 삭제하도록 지시합니다.

• 피어 라우터의 단계적 재시작 타이머가 만료되었습니다(BGP 피어가 단계적 재시작을 지원하는 경우).

• Cloud Router의 보류 타이머가 만료되었습니다. Cloud Router 보류 타이머는 구성 가능한 Cloud Router 연결 유지 타이머에 비례합니다.

Google Cloud는 동적 경로와의 상호작용에 설명된 대로 동적 경로와 로컬 및 피어링 서브넷 경로 간의 충돌을 해결합니다.

피어링 서브넷 경로

피어링 서브넷 경로는 VPC 네트워크 피어링을 통해 연결된 다른 VPC 네트워크의 서브넷에 있는 리소스에 대한 경로를 정의합니다. 자세한 내용은 서브넷 경로 교환 옵션을 참조하세요.

로컬 서브넷 및 피어링 서브넷 경로는 겹칠 수 없습니다. 자세한 내용은 서브넷 및 피어링 서브넷 경로 상호작용을 참조하세요.

피어링 그룹당 서브넷 경로 수는 피어링 그룹당 네트워크별 서브네트워크 범위 할당량에 따라 제어됩니다.

피어링 정적 및 동적 경로

VPC 네트워크 피어링을 사용하여 두 VPC 네트워크를 연결하는 경우 한 네트워크에서 정적 경로와 동적 경로를 내보내고 다른 네트워크로 가져올 수 있습니다. 자세한 내용은 다음을 참고하세요.

• 커스텀 정적 경로 교환 옵션

• 커스텀 동적 경로 교환 옵션

피어링 그룹당 정적 경로 수와 피어링 그룹당 리전별 동적 경로 수는 네트워크별 정적 및 동적 경로 할당량에 따라 제한됩니다.

적용 여부 및 순서

적용 가능한 경로

각 인스턴스에는 VPC 네트워크에 있는 모든 경로의 하위 집합인 적용 가능한 경로 집합이 있습니다. 적용 가능한 경로는 패킷이 인스턴스에서 전송될 때 취할 수 있는 가능한 이그레스 경로입니다.

• 프록시 부하 분산기, 상태 점검 시스템, 기타 Google 서비스로 다시 라우팅할 때는 특수 라우팅 경로가 적용됩니다. 자세한 내용은 특수 라우팅 경로를 참조하세요. 이러한 경로는 경로 테이블에 표시되지 않습니다.

• 정책 기반 경로는 Compute Engine VM 인스턴스에서 전송된 패킷이나 Cloud Interconnect VLAN 연결에서 수신한 패킷에 적용될 수 있습니다. 정책 기반 경로는 패킷이 정책 기반 경로의 기준과 일치하는 경우에만 적용됩니다.

• 로컬 및 피어링 서브넷 경로는 모든 인스턴스에 적용됩니다. 정책 기반 경로를 제외하고 다른 경로 유형에는 로컬 또는 피어링 서브넷 경로의 대상 위치와 일치하거나 여기에 속하는 대상이 있을 수 없습니다. 서브넷, 정적 경로, 동적 경로 간의 충돌 해결에 대한 자세한 내용은 서브넷 및 정적 경로 상호작용 및 서브넷 및 동적 경로 상호작용을 참조하세요.

• 커스텀 정적 경로는 모든 인스턴스나 특정 인스턴스에 적용될 수 있습니다. 태그 속성이 있는 정적 경로는 동일한 네트워크 태그가 있는 인스턴스에 적용됩니다. 경로에 네트워크 태그가 없으면 경로가 네트워크의 모든 인스턴스에 적용됩니다.

• 동적 경로는 VPC 네트워크의 동적 라우팅 모드에 따라 인스턴스에 적용됩니다.

특수 라우팅 경로

VPC 네트워크에는 특정 서비스에 대한 특수 경로가 있습니다. 이러한 특수 라우팅 경로는 VPC 네트워크 경로 테이블에 표시되지 않습니다. 특수 라우팅 경로는 삭제할 수 없습니다. 그러나 VPC 방화벽 규칙 또는 방화벽 정책을 사용하여 패킷을 허용하거나 거부할 수 있습니다.

외부 패스 스루 네트워크 부하 분산기 및 외부 프로토콜 전달의 경로

외부 패스 스루 네트워크 부하 분산기 및 외부 프로토콜 전달은 Maglev 시스템을 사용하여 인터넷의 클라이언트에서 VPC 네트워크의 백엔드 VM 및 대상 인스턴스로 패킷을 라우팅합니다. 이러한 Maglev 시스템은 대상이 외부 전달 규칙의 대상과 일치하는 패킷을 라우팅합니다.

외부 패스 스루 네트워크 부하 분산기 또는 외부 프로토콜 전달의 각 전달 규칙은 또한 VPC 네트워크 외부 대상으로 패킷을 전송하기 위해 백엔드 VM 또는 대상 인스턴스에 대한 라우팅 경로를 제공합니다.

• 백엔드 VM 또는 대상 인스턴스가 전송한 패킷은 클라이언트로 다시 전송되는 아웃바운드 응답 패킷이거나 새 연결을 시작하는 아웃바운드 패킷일 수 있습니다.
• 패킷 소스는 전달 규칙의 IP 주소와 일치해야 합니다. 패킷 프로토콜 및 소스 포트는 전달 규칙의 프로토콜 및 포트 사양과 일치할 필요가 없습니다.
• 전달 규칙 라우팅 경로는 기본 경로나 기본 인터넷 게이트웨이 다음 홉 사용에 의존하지 않습니다.
• 백엔드 VM 및 대상 인스턴스에서는 IP 전달을 사용 설정할 필요가 없습니다.

Google 프런트엔드 및 백엔드 사이의 경로

외부 애플리케이션 부하 분산기와 외부 프록시 네트워크 부하 분산기는 Google 프런트엔드(GFE)를 사용합니다. 보조 레이어 GFEㄴ는 백엔드 VM에 대해 TCP 연결을 열고 다음 소스로부터 패킷을 전송합니다.

• 35.191.0.0/16
• 130.211.0.0/22

Google Cloud는 Google 네트워크의 경로를 사용하여 이러한 소스 범위로부터 VPC 네트워크의 백엔드 VM으로 패킷을 전달합니다. 각 VPC 네트워크에는 VM이 35.191.0.0/16 및 130.211.0.0/22로 응답 패킷을 전송하도록 허용하는 라우팅 경로가 포함되어 있습니다.

상태 점검 경로

모든 부하 분산기 및 관리형 인스턴스 그룹 자동 복구에 대한 상태 점검은 상태 점검 프로브 IP 주소 범위로부터 백엔드 VM으로 패킷을 전송합니다.

Google Cloud는 Google 네트워크의 경로를 사용하여 상태 점검 프로브 시스템에서 VPC 네트워크의 VM으로 패킷을 전달합니다. 각 VPC 네트워크에는 VM이 상태 점검 프로브 시스템에 응답 패킷을 전송하도록 허용하는 라우팅 경로가 포함되어 있습니다.

IAP(Identity-Aware Proxy) 경로

IAP를 사용하는 TCP 전달은 완전히 Google 네트워크 내에 있는 다음 홉과 함께 35.235.240.0/20을 내부 전용 범위로 사용합니다. Google은 35.235.240.0/20에 대한 경로를 인터넷에 게시하지 않습니다.

Google 네트워크의 경로는 IAP TCP 전달을 사용할 경우 35.235.240.0/20에서 VPC 네트워크의 VM으로 패킷을 전달합니다. 각 VPC 네트워크에는 VM이 35.235.240.0/20으로 응답 패킷을 전송하도록 허용하는 라우팅 경로가 포함되어 있습니다.

Cloud DNS 및 서비스 디렉터리 경로

다음 Cloud DNS 및 서비스 디렉터리 기능은 완전히 Google 네트워크 내에 있는 다음 홉과 함께 35.199.192.0/19를 내부 전용 범위로 사용합니다. Google은 35.199.192.0/19에 대한 경로를 인터넷에 게시하지 않습니다.

• 비공개 라우팅을 사용하는 Cloud DNS 전달 대상
• 비공개 라우팅을 사용하는 Cloud DNS 대체 이름 서버
• 서비스 디렉터리에 대한 비공개 네트워크 액세스

Google 네트워크의 경로는 이러한 Cloud DNS 및 서비스 디렉터리 기능을 사용할 때 35.199.192.0/19에서 VPC 네트워크의 VM으로 패킷을 전달합니다. 각 VPC 네트워크에는 VM이 35.199.192.0/19으로 응답 패킷을 전송하도록 허용하는 라우팅 경로가 포함되어 있습니다.

서버리스 VPC 액세스 경로

서버리스 VPC 액세스는 완전히 Google 네트워크 내에 있는 다음 홉과 함께 35.199.224.0/19를 내부 전용 범위로 사용합니다. Google은 35.199.224.0/19에 대한 경로를 인터넷에 게시하지 않습니다.

Google 네트워크의 경로는 35.199.224.0/19에서 서버리스 VPC 액세스 커넥터 인스턴스로 패킷을 전달합니다. 각 VPC 네트워크에는 커넥터 인스턴스가 35.199.224.0/19로 응답 패킷을 전송하도록 허용하는 라우팅 경로가 포함되어 있습니다.

전역 Google API의 Private Service Connect 엔드포인트 경로

전역 Google API의 Private Service Connect 엔드포인트를 만들 때 Google Cloud는 엔드포인트의 경로를 VPC 네트워크에 추가합니다. 경로 대상은 엔드포인트의 전역 내부 IP 주소입니다.

라우팅 순서

다음 프로세스는 이전 섹션에 설명된 적용 가능한 경로 집합으로 시작해서 VPC 네트워크 경로 선택 동작을 모델링합니다.

1. 특수 라우팅 경로: 일부 Google Cloud 특수 라우팅 경로는 VPC 네트워크 경로 테이블에 표시되지 않습니다. 자세한 내용은 특수 라우팅 경로를 참조하세요.

   특수 라우팅 경로를 적용할 수 있는 경우 경로 선택 모델에 특수 경로만 포함됩니다. 다른 모든 경로는 무시되고 이 단계에서 평가가 중지됩니다.

2. 정책 기반 경로: 정책 기반 경로는 특수 라우팅 경로 이후에 평가되지만 다른 유형의 경로 앞에서 평가됩니다. VPC 네트워크에 정책 기반 경로가 없으면 Google Cloud는 이 단계를 건너뛰고 가장 구체적인 대상 위치 단계로 진행합니다.

   Google Cloud는 정책 기반 경로를 평가할 때 우선순위만을 기준으로 합니다. Google Cloud는 우선순위가 가장 높은 정책 기반 경로 또는 경로부터 각 정책 기반 경로의 패킷 소스 및 대상을 평가합니다. 패킷의 특성이 정책 기반 경로와 일치하지 않는 경우 Google Cloud는 이 정책 기반 경로를 무시하고 계속해서 정렬된 목록의 다음 정책 기반 경로를 평가합니다. 평가할 다음 정책 기반 경로는 무시된 정책 기반 경로와 동일한 우선순위를 공유하거나 우선순위가 더 낮을 수 있습니다.

   • 경로 선택 모델의 모든 정책 기반 경로를 평가한 이후에 패킷 특성이 정책 기반 경로와 일치하지 않으면 Google Cloud에서 모든 정책 기반 경로를 무시하고 가장 구체적인 대상 위치 단계로 진행합니다.

   • 패킷의 특성이 최고 우선순위의 정책 기반 경로와 일치하는 경우 Google Cloud가 먼저 하위 우선순위의 정책 기반 경로를 모두 무시합니다. 목록에 정책 기반 경로가 둘 이상 남아 있으면 Google Cloud가 우선순위가 동일한 남은 각 정책 기반 경로를 평가합니다. 패킷 특성이 일치하지 않으면 Google Cloud는 남은 모든 정책 기반 경로를 무시합니다. 이 단계 이후 경로 선택 모델에 정책 기반 경로가 하나 이상 포함될 수 있습니다.

   • 경로 선택 모델에 특성이 일치하는 우선순위가 가장 높은 정책 기반 경로가 2개 이상 포함된 경우 Google Cloud는 내부 알고리즘을 사용하여 단일 정책 기반 경로를 선택합니다. 선택한 정책 기반 경로는 패킷의 소스 또는 대상에 대해 가장 일치하는 항목이 아닐 수 있습니다. 이러한 모호성을 방지하기 위해서는 우선순위가 고유한 정책 기반 경로를 만드는 것이 좋습니다.

   • 경로 선택 모델에 다른 정책 기반 경로를 건너뛰도록 구성된 우선순위가 가장 높은 정책 기반 경로 하나만 포함된 경우 Google Cloud는 가장 구체적인 대상 위치 단계의 정책 기반 경로가 아닌 경로를 평가하고 모든 정책 기반 경로를 무시합니다.

   • 경로 선택 모델에 다른 정책 기반 경로를 건너뛰도록 구성되지 않은 우선순위가 가장 높은 정책 기반 경로 하나만 포함된 경우 Google Cloud는 패킷을 다음 홉 내부 패스 스루 네트워크 부하 분산기로 보내고 정책 기반 경로가 아닌 모든 경로를 무시합니다.

3. 가장 구체적인 대상: Google Cloud는 적용 가능한 경로 중 패킷의 대상 IP 주소가 포함된 가장 구체적인 대상이 있는 경로를 결정합니다. Google Cloud는 대상 위치가 덜 구체적인 다른 모든 경로를 무시합니다. 예를 들어 10.240.1.0/24는 10.240.0.0/16보다 더 구체적인 대상 위치입니다.

   이 단계 후 경로 선택 모델에는 특수 라우팅 경로와 정책 기반 경로가 포함되지 않습니다. 가장 구체적인 대상이 있는 경로만 포함됩니다.

4. 단일 VPC 네트워크의 다음 홉: 이 단계는 경로가 모델링한 대로 동작하는 VPC 네트워크가 VPC 네트워크 피어링을 통해 VPC 네트워크 하나 이상에 연결된 경우에만 적용됩니다. VPC 네트워크 피어링을 사용하면 대상 위치가 동일한 커스텀 경로가 피어링 그룹에서 2개를 초과하는 네트워크에 존재할 수 있습니다. 이 단계에서 모델링되는 요구사항은 Google Cloud가 단일 VPC 네트워크에 모두 있는 다음 홉을 선택하는 것입니다.

   • 경로 모델에서 하나 이상의 경로에 모델링하는 VPC 네트워크 내에 다음 홉이 있으면 피어 네트워크에서 다음 홉이 있는 모든 경로를 무시합니다. 이 경우 동일한 대상 위치의 다음 홉이 하나 이상의 피어 VPC 네트워크에 있더라도 Google Cloud는 로컬 VPC 네트워크의 다음 홉만 사용합니다.

   • 경로 모델의 경로 중 모델링하는 VPC 네트워크 내에 다음 홉이 있는 경로가 없고 모든 다음 홉이 여러 피어 네트워크에 있는 경우 Google Cloud는 내부 알고리즘을 사용하여 가장 구체적인 대상 위치를 위한 다음 홉이 있는 단일 피어 네트워크를 선택합니다. 경로 우선순위는 이 시점에서 고려되지 않습니다. 또한 VPC 네트워크가 새 VPC 네트워크와 피어링되거나 기존 피어 VPC 네트워크와의 연결이 끊기면 다음 홉으로 선택된 VPC 네트워크가 변경될 수 있습니다.

   이 단계를 완료하면 경로 선택 모델에 가장 구체적인 대상이 있는 경로만 포함되며 이러한 경로들의 다음 홉은 모두 단일 VPC 네트워크에 존재합니다.

5. 사용할 수 없는 다음 홉이 있는 정적 및 동적 경로 무시: 이 단계는 Google Cloud에서 다운되거나 잘못된 다음 홉을 무시하는 상황을 모델링합니다.

   • 잘못된 다음 홉 VM IP 주소 사양: next-hop-address를 사용하여 지정된 IP 주소는 경로와 동일한 VPC 네트워크에서 다음 구성 중 하나로 확인되어야 합니다.

     • VM 네트워크 인터페이스의 기본 내부 IPv4 주소
     • VM 네트워크 인터페이스의 내부 또는 외부 IPv6 주소

   • 다음 홉 VM이 실행되지 않음: Google Cloud는 다음 홉 VM 인스턴스가 중지되거나 삭제된 모든 로컬 또는 피어링 정적 경로를 무시합니다. 이 동작은 next-hop-instance 또는 next-hop-address로 구성된 경로에 적용됩니다. 자세한 내용은 다음 홉 인스턴스에 대한 고려사항 섹션의 인스턴스 중지 또는 삭제 시 동작을 참조하세요.

   • 잘못된 다음 홉 내부 패스 스루 네트워크 부하 분산기 IP 주소 사양: 로컬 또는 피어링 정적 경로에 IP 주소별로 다음 홉 부하 분산기가 있는 경우 다음 홉 IP 주소는 경로의 VPC 네트워크가 피어링된 VPC 네트워크에 있는 내부 패스 스루 네트워크 부하 분산기의 전달 규칙으로 확인되어야 합니다. 다음 홉 IP 주소가 다른 유형의 부하 분산기에 대한 전달 규칙으로 확인되거나 전달 규칙을 전혀 확인하지 않으면 Google Cloud는 경로를 무시합니다.

   • 다음 홉 내부 패스 스루 네트워크 부하 분산기에 액세스할 수 없음: 로컬 또는 피어링 정적 경로에 다음 홉 부하 분산기가 있고 패킷을 전송하는 Google Cloud 리소스가 부하 분산기 리전과 다른 리전에 있는 경우 전달 규칙에 전역 액세스가 사용 설정되어 있지 않으면 Google Cloud는 경로를 무시합니다. 이름이나 IP 주소로 다음 홉이 지정되면 경로가 무시됩니다.

   • 설정되지 않은 다음 홉 기본 VPN 터널: Google Cloud는 다음 홉 기본 VPN 터널에 활성 1단계(IKE) 보안 연결(SA)이 없는 모든 로컬 또는 피어링 정적 경로를 무시합니다. 자세한 내용은 기본 VPN 문서의 경로 순서를 참조하세요.

   • 작동하지 않는 다음 홉이 있는 동적 경로: 로컬 또는 피어링 동적 경로 프로그래밍을 담당하는 BGP 세션이 중단되기 전에 다음 홉이 작동하지 않으면 Google Cloud는 다음 홉 Cloud VPN 터널, Cloud Interconnect VLAN 연결 또는 라우터 어플라이언스 VM을 무시합니다. 이 상황은 일반적으로 해당 Cloud Router BGP 세션이 종료될 때 동적 경로가 삭제되기 전 몇 초 동안만 발생합니다.

6. 우선순위가 낮은 경로 무시: 이 단계에서는 Google Cloud가 우선순위가 가장 높은 경로를 제외한 모든 경로를 무시하는 방법을 모델링합니다.

   이 단계 후에 경로 선택 모델이 비어 있거나 하나 이상의 경로가 포함될 수 있습니다. 모델에 경로가 포함된 경우 모든 경로에 다음 특성이 모두 포함됩니다.

   • 가장 구체적인 동일한 대상 위치
   • 단일 VPC 네트워크(로컬 VPC 네트워크 또는 단일 피어 VPC 네트워크)의 다음 홉 모두
   • 작동이 중지된 것으로 확인되지 않은 다음 홉
   • 동일한 가장 높은 우선순위

7. 가장 선호되는 선호도 카테고리만 선택: Google Cloud는 서로 다른 유형의 다음 홉 간에 ECMP 라우팅을 사용하지 않습니다. 다음 표에 설명된 선호도 카테고리 시스템을 사용하여 이 동작을 모델링할 수 있습니다. 이 단계에서는 경로 유형이 동일한 경로 또는 경로 유형 및 다음 홉 유형의 조합만 포함하도록 경로 모델을 조정합니다.

   선호도 카테고리	카테고리 및 다음 홉 조합
   첫 번째 선택(가장 높은 선호도)	다음 홉 인스턴스(next-hop-instance 또는 next-hop-address) 또는 다음 홉 기본 VPN 터널이 있는 로컬 또는 피어링 정적 경로
   두 번째 선택	로컬 또는 피어링 동적 경로
   세 번째 선택	다음 홉 내부 패스 스루 네트워크 부하 분산기가 있는 로컬 또는 피어링 정적 경로(다음 홉 지정 방법과 관계없음) Google Cloud는 내부 패스 스루 네트워크 부하 분산기 다음 홉이 다른 여러 정적 경로 간에 부하를 분산하지 않습니다. 자세한 내용은 내부 패스 스루 네트워크 부하 분산기 다음 홉에 대한 고려사항을 참조하세요.
   네 번째 선택	다음 홉이 default-internet-gateway인 로컬 정적 경로

   이 단계를 완료하면 경로 모델에 0개 경로, 1개 경로, 또는 2개 이상의 경로가 있을 수 있습니다.

8. 패킷 전송 또는 삭제: 경로 모델에 남아 있는 경로 수에 따라 발생하는 결과가 다릅니다.

   • 경로 모델이 비어 있으면 ICMP 대상 또는 네트워크에 연결할 수 없다는 오류가 표시되며 패킷이 삭제됩니다. Google Cloud는 작동 중인 다음 홉이 있을 수 있는 덜 구체적인 경로로 대체하지 않습니다.

   • 경로 모델에 단일 경로가 포함된 경우 Google Cloud는 패킷을 다음 홉으로 보냅니다. VM 다음 홉의 경우 Google Cloud는 VM 다음 홉이 패킷을 처리할 수 있는지 검사하지 않습니다. 자세한 내용은 인스턴스 및 내부 패스 스루 네트워크 부하 분산기 다음 홉에 대한 일반적인 고려사항을 참조하세요. 단일 경로가 서브넷 경로 또는 피어링 서브넷 경로이고 패킷의 대상 IP 주소에 Google Cloud 리소스가 없으면 패킷이 삭제됩니다.

   • 경로 모델에 2개 이상의 경로가 포함된 경우 경로가 가장 구체적인 대상 위치를 공유하고, 단일 VPC 네트워크에 위치하고, 다운된 것으로 확인되지 않은 다음 홉 및 동일한 가장 높은 우선순위를 갖고, 하나의 경로 유형과 다음 홉 조합(선호도 카테고리)에 속합니다. Google Cloud는 해싱 알고리즘을 사용하여 등가 멀티 경로(ECMP)를 구현하는 다음 홉 간에 패킷을 배포합니다. 해시 계산은 각 패킷이 전송될 때 현재 다음 홉 수를 기반으로 수행됩니다. 패킷에 포트 정보가 포함된 경우 Google Cloud는 5-튜플 해시를 사용합니다. 그렇지 않은 경우에는 3-튜플 해시를 사용합니다. 후속 패킷이 전송될 때 경로 모델이 변경되면 해시가 동일하더라도 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는 다음 홉에 대한 프로그래밍을 자동으로 업데이트합니다.

• 공유 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이 실행되지 않는 경우 대상에 대한 라우팅은 정확히 동일한 대상에 대한 다른 경로가 있는지 여부와 다른 경로에 실행 중인 다음 홉이 있는지 여부에 따라 달라집니다. 이 동작을 설명하려면 다음 예시를 살펴보세요.
  • 대상이 192.168.168.0/24에 해당하는 패킷은 우선순위가 가장 높은 경로의 다음 홉이 실행되지 않는 다음 상황에서 route-vm-b의 다음 홉으로 전송됩니다. 이 라우팅은 Google Cloud에서 라우팅 순서의 우선순위가 낮은 경로 무시 단계를 고려하기 전에 실행 중이 아닌 다음 홉을 무시하기 때문에 발생합니다.
  • route-vm-a, 대상 192.168.168.0/24, 우선순위 10, 다음 홉 VM 중지됨
  • route-vm-b, 대상 192.168.168.0/24, 우선순위 20, 다음 홉 VM 실행 중

  • route-vm-c, 대상 192.168.168.0/24, 우선순위 30, 다음 홉 VM 실행 중

  • 대상이 192.168.168.0/24에 해당하는 패킷은 더 광범위한 192.168.0.0/16의 경로에 실행 중인 다음 홉이 있는 경우라도 다음 예시와 같이 192.168.168.0/24 경로의 일부 다음 홉 VM이 실행 중이 아닌 경우 삭제됩니다. Google Cloud가 가장 구체적인 대상 위치 단계에서 대상 범위가 더 넓은(서브넷 마스크 길이가 더 짧은) 경로를 무시하므로 패킷이 삭제됩니다. 이는 다음 홉이 라우팅 순서의 단계를 실행하지 않는 커스텀 정적 경로를 무시하기 전에 발생합니다.

  • route-vm-x, 대상 192.168.168.0/24, 우선순위 10, 다음 홉 VM 중지됨

  • route-vm-y, 대상 192.168.168.0/24, 우선순위 20, 다음 홉 VM 중지됨

  • route-vm-z, 대상 192.168.0.0/16, 우선순위 0, 다음 홉 VM 실행 중

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

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

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

  • 전달 규칙 이름(--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 서비스 프로젝트 중 하나에 위치할 수 있습니다.

  • 전달 규칙 IPv4 주소 기준: IPv4 주소로 다음 홉 전달 규칙을 지정하는 경우 전달 규칙의 네트워크는 경로의 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 VPC 네트워크의 개요를 보려면 VPC 네트워크를 참조하세요.
• VPC 네트워크를 만들거나 수정하거나 삭제하려면 VPC 네트워크 만들기 및 관리를 참조하세요.