경로 개요

Google Cloud Routes는 네트워크 트래픽이 가상 머신(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
default-internet-gateway 전체 VPC 네트워크에 적용

삭제 또는 교체 가능
서브넷 경로
서브넷 IP 주소 범위에 대해 자동으로 생성됩니다.
VPC 네트워크
VM 및 내부 부하 분산기로 패킷을 전달합니다.
전체 VPC 네트워크에 적용

사용자가 서브넷 또는 보조 IP 주소 범위를 생성, 수정 또는 삭제할 때 Google Cloud에서 자동으로 생성, 업데이트, 삭제합니다.
커스텀 경로
정적 경로
다양한 대상 위치를 지원합니다.
패킷을 정적 경로 다음 홉으로 전달합니다. 정적 경로 다음 홉에 대한 상세 설명은 다음을 참조하세요.
동적 경로
서브넷 경로 또는 정적 경로와 충돌하지 않는 대상 위치
Cloud Router의 BGP 세션 피어 VPC 네트워크의 Cloud Router에서 자동으로 경로를 추가하고 삭제합니다.

VPC 네트워크의 동적 라우팅 모드에 따라 VM에 경로가 적용됩니다.
피어링 경로
피어링 서브넷 경로
VPC 네트워크 피어링을 사용하여 연결된 네트워크의 서브넷 IP 주소 범위를 나타냅니다.
피어 VPC 네트워크
피어 네트워크의 VM 및 내부 부하 분산기로 패킷을 전달합니다.
전체 VPC 네트워크에 적용됩니다.

피어 네트워크에서 서브넷이 생성, 수정 또는 삭제되면 Google Cloud에서 자동으로 생성, 업데이트, 삭제합니다.
피어링 커스텀 경로
VPC 네트워크 피어링을 사용하여 연결된 네트워크의 커스텀 정적 경로 또는 커스텀 동적 경로
피어 VPC 네트워크의 다음 홉 피어 네트워크의 정적 경로가 지원하는 피어링 커스텀 경로는 다음과 같이 적용됩니다.
  • 네트워크 태그를 사용하는 피어 네트워크의 정적 경로는 피어링 커스텀 경로로 가져오지 않습니다.
  • 기본 인터넷 게이트웨이 다음 홉을 사용하는 피어 네트워크의 정적 경로는 피어링 커스텀 경로로 가져오지 않습니다.
  • 내부 TCP/UDP 부하 분산기 다음 홉을 사용하는 피어 네트워크의 정적 경로는 전역 액세스 사용 설정 여부에 따라 하나의 리전 또는 모든 리전에 적용될 수 있습니다. 자세한 내용은 내부 TCP/UDP 부하 분산기 다음 홉에 대한 고려사항을 참조하세요.
피어 네트워크의 동적 경로가 지원하는 피어링 커스텀 경로는 경로를 가져오는 VPC 네트워크의 동적 라우팅 모드에 따라 적용됩니다.

시스템 생성 기본 경로

VPC 네트워크를 만들면, 여기에 시스템에서 생성되는 IPv4 기본 경로(0.0.0.0/0)가 포함됩니다. VPC 네트워크에서 외부 IPv6 주소 범위로 이중 스택 서브넷을 만들면 시스템에서 생성되는 IPv6 기본 경로(::/0)가 네트워크에 추가됩니다(아직 없는 경우). 기본 경로는 다음과 같은 용도로 사용됩니다.

Google Cloud는 보다 구체적인 대상이 있는 경로가 패킷에 적용되지 않는 경우에만 기본 경로를 사용합니다. 대상 위치의 구체성과 경로 우선순위를 사용하여 경로를 선택하는 방법에 대한 상세 설명은 라우팅 순서를 참조하세요.

네트워크를 인터넷에서 완전히 분리하거나 기본 경로를 커스텀 경로로 대체해야 하는 경우 기본 경로를 삭제할 수 있습니다.

  • IPv4만 해당: 인터넷 트래픽을 다른 다음 홉으로 라우팅하려면 기본 경로를 커스텀 정적 경로 또는 동적 경로로 바꿉니다. 예를 들어 다음 홉이 프록시 VM인 커스텀 정적 경로로 바꿀 수 있습니다.

  • IPv4 및 IPv6: 기본 경로를 삭제하고 대체하지 않으면 다른 경로로 처리되지 않는 IP 범위로 향하는 패킷이 삭제됩니다.

서브넷 경로

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

각 서브넷에는 대상 위치가 서브넷의 기본 IP 범위와 일치하는 서브넷 경로가 하나 이상 있습니다. 서브넷에 보조 IP 범위가 있는 경우 각 보조 IP 주소 범위에 해당하는 서브넷 경로가 있습니다. 서브넷 IP 범위에 대한 상세 설명은 네트워크 및 서브넷을 참조하세요.

서브넷 경로의 대상 위치는 항상 가장 구체적입니다. 다른 경로의 우선순위가 더 높더라도 이 경로보다 우선 적용될 수 없습니다. Google Cloud에서 경로를 선택할 때 우선순위보다 대상 위치의 구체성을 먼저 고려하기 때문입니다. Google Cloud는 모든 서브넷 경로의 우선순위로 0을 사용합니다.

커스텀 정적 경로와의 상호작용

로컬 서브넷 경로와 가져오기한 피어링 서브넷 경로는 다음과 같은 방식으로 커스텀 정적 경로와 상호작용합니다.

  • Google Cloud에서는 대상 위치가 서브넷 경로 또는 피어링 서브넷 경로와 일치하거나 그보다 좁은 커스텀 정적 경로를 만들 수 없습니다. 예를 들어 10.70.1.0/24 대상의 로컬 서브넷 경로 또는 피어링 서브넷 경로가 있는 경우 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/2510.70.1.0/24에 속하는 기타 대상에 대한 새로운 커스텀 정적 경로를 만들 수 없습니다.

  • 반대로 Google Cloud에서는 대상 위치가 기존 커스텀 정적 경로와 정확히 일치하거나 더 광범위한(포함하는) 새 서브넷 또는 피어링 서브넷 경로를 만들 수 없습니다. 예를 들어 VPC 네트워크에 10.70.1.128/25 대상에 대한 커스텀 정적 경로가 있는 경우 Google Cloud는 기본 또는 보조 서브넷 IP 주소 범위가 10.70.1.128/25, 10.70.1.0/24이거나 10.70.1.128/25의 모든 IP 주소가 포함된 기타 범위가 있는 서브넷 또는 피어링 서브넷 경로를 만들 수 없습니다.

커스텀 동적 경로와의 상호작용

로컬 서브넷 경로와 가져오기한 피어링 서브넷 경로는 다음과 같은 방식으로 Cloud Router와 상호작용합니다.

  • Cloud Router가 서브넷 또는 피어링 서브넷 경로의 대상 위치와 정확히 일치하는 프리픽스를 학습하면 Google Cloud는 이러한 커스텀 동적 경로를 무시합니다. 예를 들어 10.70.1.0/24 대상 위치에 대한 서브넷 또는 피어링 서브넷 경로가 있고 VPC 네트워크에서 하나 이상의 Cloud Router가 BGP를 통해 10.70.1.0/24 프리픽스를 수신하면 Google Cloud는 서브넷 또는 피어링 서브넷 경로를 사용하고 충돌하는 커스텀 동적 경로를 무시합니다.

  • Cloud Router가 서브넷 또는 피어링 서브넷 경로의 대상 위치 내에 속하는 프리픽스를 학습하면 Google Cloud는 이러한 커스텀 동적 경로를 무시합니다. 예를 들어 10.70.1.0/24 대상 위치에 대한 서브넷 또는 피어링 서브넷 경로가 있고 VPC 네트워크에서 하나 이상의 Cloud Router가 BGP를 통해 10.70.1.0/25 프리픽스를 수신하면 Google Cloud는 서브넷 또는 피어링 서브넷 경로를 사용하고 충돌하는 커스텀 동적 경로를 무시합니다.

서브넷 경로의 수명 주기

서브넷 경로는 서브넷 또는 서브넷의 IP 주소 범위를 만들거나 수정하거나 삭제할 때 생성, 업데이트, 삭제됩니다.

  • 서브넷을 추가하면 Google Cloud가 서브넷의 기본 IP 주소 범위에 해당하는 서브넷 경로를 만듭니다.

  • 자동 모드 VPC 네트워크에서는 자동으로 생성된 각 서브넷의 기본 IP 범위에 해당하는 서브넷 경로가 생성됩니다. 이러한 서브넷을 삭제하려면 자동 모드 VPC 네트워크를 커스텀 모드로 전환해야 합니다.

  • 서브넷을 수정하거나 삭제하지 않으면 서브넷 경로를 삭제할 수 없습니다.

    • 서브넷에서 보조 범위를 삭제하면 해당 보조 범위의 서브넷 경로가 자동으로 삭제됩니다.

    • 서브넷을 삭제하면 기본 범위와 보조 범위의 모든 서브넷 경로가 자동으로 삭제됩니다. 다른 방법으로는 서브넷의 기본 범위에 대한 서브넷 경로를 삭제할 수 없습니다.

VPC 네트워크의 서브넷 경로 수는 서브넷 IP 범위(기본 및 보조)의 최대 개수에 의해 제한됩니다.

정적 경로

정적 경로는 정적 경로 매개변수를 사용하여 정의되며 정적 경로 다음 홉을 지원합니다. 정적 경로는 다음 두 가지 방법 중 하나로 만들 수 있습니다.

동적 경로

동적 경로는 VPC 네트워크의 Cloud Router에서 관리합니다. 이 경로의 대상 위치는 항상 BGP 피어에서 수신된 VPC 네트워크 외부의 IP 주소 범위를 나타냅니다. 동적 경로가 사용되는 곳은 다음과 같습니다.

대상 위치가 다음 기준 중 하나와 일치하는 경우 VPC 네트워크는 Cloud Router에서 수신한 모든 대상 위치를 무시합니다.

  • 대상 위치가 서브넷 IP 주소 범위와 정확하게 일치하는 경우

  • 대상 위치가 서브넷 IP 주소 범위보다 작은 범위에 속하는 경우(서브넷 마스크가 더 긴 경우)

하지만 동적 경로의 대상 위치는 서브넷의 IP 범위를 포함할 수 있습니다(서브넷 마스크가 더 작을 수 있음). 예를 들어 서브넷 IP 범위가 10.10.10.0/24이면 대상 위치가 10.10.10.0/23인 동적 경로를 사용할 수 있습니다. 패킷의 대상 IP 주소가 서브넷 경로의 대상 위치보다 작은 범위에 속하지 않는 경우 패킷이 동적 경로의 다음 홉으로 전송됩니다. 가능한 가장 광범위한 대상 위치는 0.0.0.0/0입니다.

피어링 서브넷 경로

피어링 서브넷 경로는 VPC 네트워크 피어링을 사용하여 연결된 다른 VPC 네트워크의 서브넷을 사용하는 리소스 경로를 정의합니다. 다른 네트워크를 피어 VPC 네트워크라고 합니다.

피어 네트워크는 다음과 같은 방법으로 서브넷 경로를 공유합니다.

  • 피어 네트워크는 모든 기본 및 보조 IP 주소 범위의 서브넷 경로를 항상 내보냅니다.

  • 경로의 대상 위치(서브넷 IP 주소 범위)가 비공개로 사용되는 공개 IP 주소가 아니라면 피어 네트워크가 서브넷 경로를 자동으로 가져옵니다. 필요한 경우 비공개로 사용되는 공개 IP 주소를 사용하는 서브넷 경로를 가져오도록 피어를 구성할 수 있습니다.

  • 피어링을 사용 중지하지 않으면 가져온 피어링 서브넷 경로를 삭제할 수 없습니다. 피어링을 사용 중지하면 가져온 모든 피어링 서브넷 경로가 자동으로 삭제됩니다.

  • Google Cloud는 피어링된 네트워크 간에 서브넷 IP 주소 범위 충돌을 방지합니다.

VPC 네트워크의 모든 서브넷 경로 수와 모든 피어 네트워크에서 가져온 피어링 서브넷 경로 수를 합한 숫자는 서브넷 IP 범위(기본 및 보조)의 최대 개수에 의해 제한됩니다.

피어링 커스텀 경로

커스텀 경로를 내보내거나 가져오도록 피어 네트워크를 구성할 수 있습니다. 이 경우 커스텀 경로는 VPC 네트워크의 정적 경로와 동적 경로를 모두 의미합니다.

VPC 네트워크가 커스텀 경로를 내보내도록 구성된 경우에도 이러한 유형의 경로는 생략됩니다.

VPC 네트워크의 정적 및 동적 경로 수와 모든 피어 네트워크에서 가져온 피어링 커스텀 경로 수를 합한 숫자는 제한됩니다.

  • 피어링 그룹 내 정적 경로의 최대 개수
  • 피어링 그룹 내 동적 경로의 최대 개수

적용 여부 및 순서

적용 가능한 경로

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

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

  • 서브넷 및 피어링 서브넷 경로는 모든 인스턴스에 적용됩니다. 서브넷 경로와 피어링 서브넷 경로는 VPC 네트워크의 서브넷과 피어 네트워크에서 가져온 서브넷에 해당합니다.

  • 시스템 생성 기본 경로는 모든 인스턴스에 적용됩니다. 원하는 경우 시스템 생성 기본 경로를 커스텀 정적 경로로 바꿀 수 있습니다.

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

    • 커스텀 정적 경로에 VM 인스턴스의 다음 홉이 있으면 다음 홉 VM이 삭제되거나 전원이 꺼지거나 오작동해도 이 경로는 항상 유효합니다. 자세한 내용은 다음 홉으로 사용되는 인스턴스를 참조하세요.

    • 커스텀 정적 경로에 Cloud VPN 터널의 다음 홉이 있는 경우 터널이 작동하면 경로가 항상 유효합니다. 터널이 다운되었을 때 Google Cloud가 터널 경로를 처리하는 방법은 Cloud VPN 문서에서 터널이 다운되었을 때를 참조하세요.

  • 동적 경로는 VPC 네트워크의 동적 라우팅 모드에 따라 인스턴스에 적용됩니다. VPC 네트워크가 리전별 동적 라우팅 모드를 사용하는 경우 모든 Cloud Router가 로컬 리전에서 학습된 프리픽스의 동적 경로만 만듭니다. VPC 네트워크가 전역 동적 라우팅 모드를 사용하는 경우 모든 Cloud Router가 모든 리전에서 학습된 프리픽스의 동적 경로를 만듭니다.

    • Cloud Router는 액세스할 수 없는 다음 홉(Cloud VPN 터널 또는 Cloud Interconnect 연결)에 해당하는 학습된 프리픽스를 자동으로 삭제합니다. 네트워크에 따라 Cloud Router가 다음 홉이 다운된 동적 경로를 제거하는 데 최대 40초의 처리 시간이 걸릴 수 있습니다.

라우팅 순서

다음 프로세스는 VPC 네트워크 경로 선택 동작을 모델링합니다. 이전 섹션에 설명된 대로 적용 가능한 경로 집합부터 Google Cloud가 이 프로세스에 따라 패킷에 대해 수행하는 경로 선택 결정을 모델링할 수 있습니다.

  1. 가장 구체적인 대상 위치: Google Cloud는 먼저 적용할 수 있는 경로 중 패킷의 대상 IP 주소를 포함하는 가장 구체적인 대상 위치가 있는 경로를 결정합니다. Google Cloud는 대상 위치가 덜 구체적인 다른 모든 경로를 무시합니다. 예를 들어 10.240.1.0/2410.240.0.0/16보다 더 구체적인 대상 위치입니다. 가장 구체적인 대상 위치는 모든 유형의 경로일 수 있습니다. 그러나 서브넷 경로, 피어링 서브넷 경로, 특수 반환 경로는 정의에 따라 가장 구체적인 경로입니다.

  2. 이 단계 후에 경로 선택 모델에는 가장 구체적인 대상 위치가 있는 경로만 포함됩니다.

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

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

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

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

  4. 다음 홉이 다운된 커스텀 정적 경로를 무시: 이 단계는 다운된 것으로 간주되는 다음 홉을 Google Cloud에서 무시하는 두 가지 상황을 모델링합니다. 이 단계는 커스텀 정적 경로에만 적용됩니다. 대신 BGP 공지를 사용하여 커스텀 동적 경로를 자동으로 추가하고 삭제합니다.

    • Google Cloud는 다음 홉 VM이 중지되거나 삭제된 경우 다음 홉 VM 인스턴스(next-hop-instance 또는 next-hop-address)를 모두 무시합니다. 자세한 내용은 다음 홉 인스턴스 고려사항 섹션의 인스턴스 중지 또는 삭제 시 동작을 참조하세요. 경로 모델에 다음 홉 VM이 중지되거나 삭제된 정적 경로가 포함된 경우 모델에서 해당 경로를 삭제합니다.

    • 터널에 1단계(IKE) 보안 연결(SA)이 없는 경우 Google Cloud는 다음 홉 기본 VPN 터널을 사용하는 모든 커스텀 정적 경로를 무시합니다. 자세한 내용은 기본 VPN 문서의 경로 순서를 참조하세요. 설정된 IKE SA가 없는 기본 VPN 터널이 다음 홉인 정적 경로가 경로 모델에 포함되는 경우 모델에서 이러한 경로를 삭제합니다.

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

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

    • 가장 구체적인 동일한 대상 위치
    • 단일 VPC 네트워크(로컬 VPC 네트워크 또는 단일 피어 VPC 네트워크)의 다음 홉 모두
    • 작동이 중지된 것으로 확인되지 않은 다음 홉
    • 동일한 가장 높은 우선순위
  6. 가장 선호되는 선호도 카테고리만 선택: Google Cloud는 서로 다른 유형의 다음 홉 간에 ECMP 라우팅을 사용하지 않습니다. 다음 표에 설명된 선호도 카테고리 시스템을 사용하여 이 동작을 모델링할 수 있습니다. 이 단계에서는 경로 유형이 동일한 경로 또는 경로 유형 및 다음 홉 유형의 조합만 포함하도록 경로 모델을 조정합니다.

    선호도 카테고리 카테고리 및 다음 홉 조합
    첫 번째 선택(가장 높은 선호도) 작동 중인 다음 홉 인스턴스(next-hop-instance 또는 next-hop-address) 또는 IKE SA가 설정된 다음 홉 기본 VPN 터널이 있는 커스텀 정적 경로
    두 번째 선택 모든 Cloud Router의 BGP 세션에서 학습된 커스텀 동적 경로
    세 번째 선택 내부 TCP/UDP 부하 분산기 다음 홉이 있는 단일 커스텀 정적 경로
    Google Cloud는 내부 알고리즘을 사용하여 단일 다음 홉 내부 TCP/UDP 부하 분산기를 선택하며 동일한 우선순위의 다른 내부 TCP/UDP 부하 분산기를 무시합니다. 자세한 내용은 내부 TCP/UDP 부하 분산기 다음 홉에 대한 고려사항 섹션에서 '동일 대상 및 여러 다음 홉 내부 TCP/UDP 부하 분산기'를 참조하세요.
    네 번째 선택 default-internet-gateway 다음 홉을 사용하는 커스텀 정적 경로

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

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

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

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

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

특수 반환 경로

VPC 네트워크에는 특정 서비스에 대한 특수 경로가 있습니다. 이 경로는 VPC 네트워크 외부의 Google 프로덕션 네트워크에 정의되며, VPC 네트워크의 라우팅 테이블에 나타나지 않습니다. VPC 네트워크에서 기본 경로를 삭제하거나 바꿔도 이 경로를 삭제하거나 재정의할 수 없습니다. 하지만 방화벽 규칙을 사용하여 이러한 서비스에 대한 트래픽을 제어할 수 있습니다.

부하 분산기 반환 경로

다음 Google Cloud 부하 분산기 중 하나를 사용하는 경우 Google Cloud에는 부하 분산기 및 관련 상태 확인을 위한 특수 경로가 있으며 자세한 내용은 다음 섹션에 설명되어 있습니다.

HTTP(S), SSL 프록시, TCP 프록시 부하 분산기의 반환 경로

이러한 부하 분산기 유형의 경우 Google 프런트 엔드(GFE) 시스템은 프록시 역할을 합니다. 클라이언트가 부하 분산기에 요청을 보내면 프록시가 TCP 세션을 종료하고 백엔드 VM과의 새로운 TCP 세션을 엽니다. VPC 네트워크 외부에 정의된 경로는 GFE 프록시에서 백엔드 VM으로, 백엔드 VM에서 GFE 프록시로의 통신을 지원합니다.

자세한 내용은 다음 페이지를 참조하세요.

네트워크 부하 분산기의 반환 경로

인터넷상의 클라이언트가 네트워크 부하 분산기를 통해 TCP 또는 UDP 요청을 백엔드 VM으로 전송하면 Google Cloud는 VPC 네트워크 외부에 정의된 경로를 사용하여 클라이언트에서 백엔드 VM으로 그리고 백엔드 VM에서 클라이언트로의 통신을 지원합니다.

자세한 내용은 네트워크 부하 분산을 참조하세요.

모든 부하 분산기 유형의 상태 확인

Google Cloud 상태 확인 프로브 시스템에서 전송된 패킷에는 프로브 IP 범위 및 방화벽 규칙에 설명된 대로 소스가 있습니다. Google Cloud 상태 확인 프로브 시스템과 백엔드 VM 간의 통신을 용이하게 하는 경로는 VPC 네트워크 외부에 있으며 제거할 수 없습니다. 하지만 VPC 네트워크에는 이러한 시스템의 트래픽을 허용하는 인그레스 허용 방화벽 규칙이 있어야 합니다.

IAP

35.235.240.0/20의 경로는 IAP를 사용한 TCP 전달을 지원하기 위해 포함됩니다. Google의 프로덕션 네트워크에서는 인터넷의 다른 소스로부터 오는 35.235.240.0/20에 대한 경로가 허용되지 않습니다.

Cloud DNS

35.199.192.0/19 경로는 비공개 라우팅을 사용하는 전달 대상 또는 비공개 라우팅을 사용하는 대체 이름 서버에 대한 연결을 지원합니다. Google의 프로덕션 네트워크에서는 인터넷의 다른 소스로부터 오는 35.199.192.0/19에 대한 경로가 허용되지 않습니다.

정적 경로 매개변수

각 정적 경로는 다음 구성요소로 이루어집니다.

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

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

  • 대상 범위. 대상 범위는 수신 패킷을 받는 시스템의 IP 주소를 포함하는 단일 IPv4 CIDR 블록입니다. 대상 위치는 CIDR 표기법으로 표현되어야 합니다. 대상 위치는 서브넷 IP 주소 범위와 정확히 일치할 수 없으며 서브넷 IP 주소 범위보다 작은 범위에 속할 수도 없습니다(더 긴 서브넷 마스크를 가질 수 없음). 그러나 정적 경로의 대상은 서브넷의 IP 범위를 포함할 수 있습니다(서브넷 마스크가 더 작을 수 있음). 예를 들어 서브넷 IP 범위가 10.10.10.0/24이면 대상 위치가 10.10.10.0/23인 정적 경로를 가질 수 있습니다. 패킷의 대상 IP 주소가 서브넷 경로의 대상 위치보다 작은 범위에 속하지 않는 경우 패킷이 정적 경로의 다음 홉으로 전송됩니다. 가능한 가장 광범위한 대상 위치는 0.0.0.0/0입니다.

  • 우선순위. 여러 경로의 대상 위치가 동일한 경우 우선순위를 사용하여 어느 경로를 사용할지 결정합니다. 숫자가 낮을수록 우선순위가 높습니다. 예를 들어 우선순위 값이 100인 경로는 우선순위 값이 200인 경로보다 우선순위가 높습니다. 가장 높은 경로 우선순위는 음수가 아닌 가장 작은 정수를 의미합니다. 0은 음수가 아닌 가장 작은 정수이므로 우선순위가 가장 높습니다.

  • 다음 홉. 정적 경로에는 기본 인터넷 게이트웨이, Google Cloud 인스턴스 또는 Cloud VPN 터널을 가리키는 다음 홉이 있을 수 있습니다. 자세한 내용은 정적 경로 다음 홉을 참조하세요.

  • 태그. 경로가 나열된 태그 중 하나 이상이 있는 인스턴스에만 적용되도록 네트워크 태그의 목록을 지정할 수 있습니다. 태그를 지정하지 않으면 Google Cloud는 네트워크의 모든 인스턴스에 경로를 적용합니다. 다음 홉 내부 TCP/UDP 부하 분산기는 네트워크 태그를 지원하지 않습니다.

정적 경로의 다음 홉

정적 경로에 유효한 다음 홉은 다음과 같습니다. 각 유형에 대한 자세한 내용은 gcloud 참조 문서를 확인하세요.

  • 다음 홉 게이트웨이(next-hop-gateway): 기본 인터넷 게이트웨이를 지정하여 외부 IP 주소의 경로를 정의할 수 있습니다.

  • 이름별 다음 홉 인스턴스(next-hop-instance) 또는 주소(next-hop-address 참조). 경로와 동일한 VPC 네트워크에 있는 네트워크 인터페이스를 사용하여 기존 인스턴스로 트래픽을 전달할 수 있습니다. 자세한 내용은 다음 홉 인스턴스에 대한 고려사항을 참조하세요.

  • 다음 홉 내부 TCP/UDP 부하 분산기(next-hop-ilb). 기존 내부 TCP/UDP 부하 분산기의 여러 백엔드 인스턴스로 트래픽을 전달할 수 있습니다. 자세한 내용은 내부 TCP/UDP 부하 분산기 다음 홉에 대한 고려사항을 참조하세요.

  • 다음 홉 VPN 터널(next-hop-vpn-tunnel). 정책 기반 라우팅 및 경로 기반 VPN을 사용하는 기본 VPN 터널의 경우 다음 홉이 이름과 리전으로 터널을 참조하는 경로를 만들어 VPN 터널로 트래픽을 보낼 수 있습니다. 자세한 내용은 기본 VPN 터널의 다음 홉에 대한 고려사항을 참조하세요.

인스턴스 및 내부 TCP/UDP 부하 분산기 다음 홉에 대한 일반적인 고려사항

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

다음 홉으로서의 내부 TCP/UDP 부하 분산기는 다음 홉이 내부 TCP/UDP 부하 분산기(next-hop-ilb)인 정적 경로를 나타냅니다.

인스턴스 기반 라우팅 또는 내부 TCP/UDP 부하 분산기를 다음 홉으로 구성할 때 다음 가이드라인을 고려하세요.

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

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

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

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

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

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

  • 인스턴스 이름별 다음 홉(next-hop-instance): 경로와 다음 홉 인스턴스가 모두 동일한 프로젝트에 있는 경우 해당 이름과 영역을 사용하여 다음 홉 인스턴스를 지정할 수 있습니다. Google Cloud에서 경로를 만들려면 먼저 다음 홉 인스턴스가 존재하고 다음 기준을 모두 충족해야 합니다.

    • 인스턴스 이름은 경로의 다음 홉 VM 이름과 일치해야 합니다.
    • 인스턴스 영역은 경로의 다음 홉 영역과 일치해야 합니다.
    • 인스턴스에 경로 VPC 네트워크의 네트워크 인터페이스 1개가 있어야 합니다.

    Google Cloud는 다음 상황에서 next-hop-instance가 다음 홉을 지정하는 경로를 자동으로 업데이트합니다.

    • 다음 홉 인스턴스의 IPv4 주소가 변경되는 경우
    • 다음 홉 인스턴스를 대체할 때 대체 인스턴스가 대체된 인스턴스와 동일한 기준을 충족하는 경우
  • 다음 홉 인스턴스 내부 IP 주소(next-hop-address): 경로의 VPC 네트워크에 있는 네트워크 인터페이스와 연결된 내부 IPv4 주소를 사용하여 다음 홉 인스턴스를 지정할 수 있습니다. Google Cloud에서 경로를 만들려면 먼저 다음 홉 인스턴스가 존재하고 다음 기준을 모두 충족해야 합니다.

    • 인스턴스에 경로 VPC 네트워크의 네트워크 인터페이스가 하나 이상 있어야 합니다.
    • 인스턴스의 네트워크 인터페이스에는 경로의 다음 홉 주소와 일치하는 내부 IPv4 주소가 있어야 합니다. 내부 IPv4 주소는 네트워크 인터페이스의 기본 IPv4 주소 또는 네트워크 인터페이스의 별칭 IP 범위에 있는 IPv4 주소일 수 있습니다.

    Google Cloud는 IPv4 주소가 다른 VM으로 이동하면 다음 홉이 next-hop-address로 지정된 경로를 자동으로 업데이트합니다. 단, 대체 VM이 위의 기준을 충족해야 합니다.

  • 공유 VPC 서비스 프로젝트의 다음 홉: 다음 홉 인스턴스가 서비스 프로젝트에 있는 공유 VPC 네트워크에서 경로를 만들어야 하는 경우 next-hop-address를 사용하여 다음 홉을 지정해야 합니다. next-hop-instance를 사용하여 다음 홉을 지정할 수는 없습니다.

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

  • 상태 확인, 구성 검증 없음: Google Cloud는 다음 홉 인스턴스가 인스턴스 및 내부 TCP/UDP 부하 분산기의 다음 홉에 대한 공통 고려사항 섹션에 기재된 모든 요구 사항을 충족하는지 결코 체크하지 않습니다. 인스턴스의 게스트 운영체제를 구성하여 VM의 네트워크 인터페이스를 사용 중지해도 Google Cloud은 다음 홉 인스턴스를 무시하지 않습니다. 신뢰성을 높이려면 그 대신 내부 TCP/UDP 부하 분산기를 다음 홉으로 사용하세요.

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

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

    VPC 네트워크 연결을 위해 여러 인터페이스가 있는 VM을 두 개 이상 사용하고 동일한 VM이 특정 연결에 대해 양방향으로 패킷을 처리해야 하는 경우 다음 홉 내부 TCP/UDP 부하 분산기를 사용해야 합니다. 다음 홉 내부 TCP/UDP 부하 분산기가 필요한데, 이는 대칭 해싱을 제공하기 때문입니다. 대칭 해싱에 대한 상세 설명은 다음 홉으로 사용되는 내부 TCP/UDP 부하 분산기의 대칭 해싱을 참조하세요.

  • 인스턴스가 중지 또는 삭제될 때의 동작: 사용자가 지정한 방법(next-hop-instance 또는 next-hop-address 사용)에 관계없이 Google Cloud는 사용자가 다음 홉 인스턴스를 중지하거나 삭제하는 것을 막지 않습니다. Google Cloud는 라우팅 순서의 선호도 카테고리 지정 단계에서 중지되거나 삭제된 모든 인스턴스를 삭제합니다. 다음 예시는 이 동작을 명료하게 설명합니다.

    • 192.168.168.0/24 대상에 3개의 커스텀 정적 경로가 있다고 가정해 봅시다. 여기서 우선순위 10인 첫 번째 경로의 다음 홉 VM은 작동 중지되었고, 선호도 20인 두 번째 경로의 다음 홉 VM은 작동 중이며, 선호도 30인 세 번째 경로의 다음 홉 VM도 작동 중이라고 가정하겠습니다. Google Cloud는 두 번째 경로가 다음 홉 VM이 중지된 경로보다 우선순위가 낮음에도 두 번째 VM으로 패킷을 전송합니다. 사용자가 첫 번째 홉의 VM을 시작하면 Google Cloud은 대신 첫 번째 경로를 사용합니다.

    • 앞에서 설명한 대로 커스텀 정적 경로가 3개 있지만 다음 홉 VM이 모두 중지되거나 삭제되었다고 가정해 보겠습니다. Google Cloud는 다음 홉 VM이 실행 중인지 결정하기 전에 대상 위치의 구체성을 고려하기 때문에 작동 중인 다음 홉이 있는 덜 구체적인 경로가 있는 경우에도 패킷이 삭제됩니다.

내부 TCP/UDP 부하 분산기 다음 홉에 대한 고려사항

  • 전역 액세스의 영향. 내부 TCP/UDP 부하 분산기 다음 홉을 사용하는 커스텀 정적 경로는 모든 리전에서 프로그래밍됩니다. 다음 홉의 사용 가능 여부는 부하 분산기의 전역 액세스 설정에 따라 다릅니다. 전역 액세스를 사용 설정하면 VPC 네트워크의 모든 리전에서 부하 분산기 다음 홉에 액세스할 수 있습니다. 전역 액세스가 중지된 경우 부하 분산기와 동일한 리전에서만 부하 분산기 다음 홉에 액세스할 수 있습니다. 전역 액세스가 중지되면 다른 리전에서 내부 TCP/UDP 부하 분산기 다음 홉을 사용하는 경로로 전송된 패킷이 삭제됩니다.
  • 모든 백엔드가 비정상일 경우. 내부 TCP/UDP 부하 분산기의 모든 백엔드에서 상태 확인에 실패해도 이 부하 분산기 다음 홉을 사용하는 경로가 계속 적용됩니다. 경로를 통해 처리된 패킷은 트래픽 분산에 따라 다음 홉 부하 분산기의 백엔드 중 하나로 전송됩니다.

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

  • 동일한 대상과 여러 다음 홉 내부 TCP/UDP 부하 분산기. 동일한 대상에서 서로 다른 내부 TCP/UDP 부하 분산기 다음 홉을 사용하여 2개 이상의 커스텀 정적 경로를 만드는 경우 Google Cloud는 ECMP를 사용하여 부하 분산기 다음 홉 간에 트래픽을 분산하지 않습니다. 경로가 고유한 우선순위를 가지는 경우 Google Cloud는 우선순위가 가장 높은 경로의 다음 홉 내부 TCP/UDP 부하 분산기를 사용합니다. 경로가 동일한 우선순위를 가지는 경우에도 Google Cloud는 다음 홉 내부 TCP/UDP 부하 분산기를 하나만 선택합니다. 후자의 경우, 아래 다이어그램에 표시된 것처럼 Google Cloud는 확정 내부 알고리즘을 사용하여 단일 다음 홉 전달 규칙(forwarding-rule-a)을 선택하며, 우선순위가 같은 다른 경로를 무시합니다.

    같은 대상, 다른 내부 TCP/UDP 부하 분산기 다음 홉
    같은 대상, 다른 내부 TCP/UDP 부하 분산기 다음 홉
  • 여러 대상 및 동일한 다음 홉 내부 TCP/UDP 부하 분산기.

    인스턴스 태그 포함:

    인스턴스 태그(네트워크 태그라고도 함)를 사용하는 경우 대상 및 우선순위가 같은 여러 커스텀 정적 경로에 동일한 다음 홉 내부 TCP/UDP 부하 분산기를 사용할 수 있습니다.

    인스턴스 태그 제외: 인스턴스 태그가 없으면 대상, 우선순위, 내부 TCP/UDP 부하 분산기 다음 홉에 대해 동일한 조합을 갖는 커스텀 정적 경로를 여러 개 만들 수 없습니다. 예를 들어 route-x, route-y, route-z를 모두 만들 수 있지만 route-x-copy를 만들 수 없습니다.

    공통 내부 TCP/UDP 부하 분산기 다음 홉을 사용하는 태그가 지정되지 않은 경로 예시
    공통 내부 TCP/UDP 부하 분산기 다음 홉을 사용하는 태그가 지정되지 않은 경로 예시
  • 인스턴스 태그

    인스턴스 태그(네트워크 태그라고도 함)를 지정하여 다음 홉 경로가 태그로 구성된 클라이언트 인스턴스에만 적용되도록 할 수 있습니다. 이렇게 하면 태그가 지정된 다음 홉 경로가 채워진 클라이언트 인스턴스, 트래픽을 라우팅할 어플라이언스 집합을 선택할 수 있습니다.

    서로 다른 클라이언트 인스턴스를 각각 어플라이언스 집합을 프런트엔드하는 선호하는 TCP/UDP 부하 분산기를 가리키도록 별도의 VPC 네트워크로 분리할 필요는 없습니다.

  • 동일한 대상 프리픽스에 대한 다중 경로 인스턴스 태그를 사용하면 다른 내부 부하 분산기를 사용하는 동일한 대상에 대한 경로 여러 개를 다음 홉으로 지정할 수 있습니다. 이러한 동일한 대상 경로에 다른 인스턴스 태그나 다른 속성을 사용할 수 있습니다.

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

  • 리전 간 비용 및 지연 시간: Google Cloud는 다음 홉 기본 VPN 터널을 사용하는 경로의 리전 거리를 고려하지 않습니다. 다른 리전의 다음 홉 기본 VPN 터널로 트래픽을 전송하면 이그레스 비용이 추가되고 네트워크 지연이 발생합니다. HA VPN 터널 또는 동적 라우팅을 사용하는 기본 VPN 터널을 대신 사용하는 것이 가장 좋습니다.

  • 기본 VPN 터널이 작동 중지될 때의 동작: 다음 홉이 기본 VPN 터널인 커스텀 정적 경로는 기본 VPN 터널이 작동 중지될 때 자동으로 삭제되지 않습니다. 터널 작동이 중지되면 어떻게 되는지에 대한 자세한 내용은 기본 VPN 문서에서 터널이 작동 중지된 경우를 참조하세요.

다음 단계