경로 개요

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 네트워크의 경로를 분류하는 방법이 요약되어 있습니다.

유형 및 대상 다음 홉 참고
시스템 생성 경로
시스템 생성 기본 경로
0.0.0.0/0
default-internet-gateway 전체 VPC 네트워크에 적용

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

사용자가 서브넷 또는 보조 IP 주소 범위를 생성, 수정 또는 삭제할 때 Google Cloud에서 자동으로 생성, 업데이트, 삭제합니다.
커스텀 경로
정적 경로
다양한 대상 위치를 지원합니다.
유효한 정적 경로 다음 홉 다음 홉 내부 TCP/UDP 부하 분산기의 경우 전역 액세스가 사용 설정되어 있지 않다면 부하 분산기와 동일한 리전의 TCP 및 UDP 트래픽에만 적용됩니다.

다른 정적 다음 홉의 경우 경로에 네트워크 태그를 지정하면 특정 VM에 경로를 적용할 수 있습니다. 네트워크 태그를 지정하지 않으면 VPC 네트워크의 모든 VM에 경로가 적용됩니다.
동적 경로
서브넷 경로 또는 정적 경로와 충돌하지 않는 대상 위치
Cloud Router의 BGP 세션 피어 VPC 네트워크의 Cloud Router에서 자동으로 경로를 추가하고 삭제합니다.

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

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

시스템 생성 기본 경로

VPC 네트워크를 생성하면 시스템 생성 기본 경로가 포함됩니다. 이 기본 경로의 용도는 두 가지입니다.

  • 인터넷으로 가는 경로를 포함하여 VPC 네트워크에서 나가는 경로를 정의합니다. 인터넷에 액세스해야 하는 인스턴스는 이 경로를 사용할 뿐만 아니라 추가 요구사항도 충족해야 합니다.

  • 비공개 Google 액세스의 표준 경로를 제공합니다.

시스템 생성 기본 경로의 우선순위는 1000입니다. 이 경로의 대상 위치는 가능한 가장 광범위한 값(0.0.0.0/0)이기 때문에 Google Cloud는 오직 보다 구체적인 경로를 가진 대상 위치가 패킷에 적용되지 않는 경우에만 이 대상 위치를 사용합니다. 대상 위치의 구체성과 경로 우선순위를 사용하여 경로를 선택하는 방법에 대한 자세한 내용은 라우팅 순서를 참조하세요.

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

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

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

서브넷 경로

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

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

다른 경로의 대상 위치는 서브넷 경로의 대상 위치와 일치하거나 그보다 구체적일 수 있습니다(서브넷 마스크가 더 많음).

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

서브넷 경로가 생성되고 삭제되는 방식은 다음과 같습니다.

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

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

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

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

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

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

정적 경로

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

동적 경로

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

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

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

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

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

피어링 서브넷 경로

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

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

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

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

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

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

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

피어링 커스텀 경로

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

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

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

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

적용 여부 및 순서

적용 가능한 경로

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

  • 서브넷 및 피어링 서브넷 경로는 모든 인스턴스에 적용됩니다. 서브넷 경로와 피어링 서브넷 경로는 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 주소가 서브넷 또는 피어링 서브넷 경로의 대상 위치보다 작은 범위에 속하면 다음이 적용됩니다.

      • 패킷이 실행 중인 VM 인스턴스 또는 구성된 내부 부하 분산기의 내부 IP 주소로 전달됩니다.

      • 중지된 VM 인스턴스를 대상으로 하는 패킷이 삭제됩니다.

      • IP 주소를 사용하도록 구성된 Google Cloud 리소스가 없으면 내부 IP 주소로 향하는 패킷이 삭제됩니다.

    • Google Cloud에서는 대상 위치가 서브넷 경로 또는 피어링 서브넷 경로와 일치하거나 그보다 구체적인 커스텀 정적 경로를 만들 수 없습니다.

    • Cloud Router는 서브넷 경로 또는 피어링 서브넷 경로의 대상 위치와 정확하게 일치하는 학습된 프리픽스를 무시합니다.

    • Cloud Router는 서브넷 경로 또는 피어링 서브넷 경로보다 작은 범위에 속하는(서브넷 마스크가 더 긴) 학습된 프리픽스를 무시합니다.

  2. 서브넷 경로 또는 피어링 서브넷 경로로 패킷을 라우팅할 수 없는 경우 Google Cloud는 대상 위치가 가장 구체적인 정적, 동적 또는 피어링 커스텀 경로를 찾습니다. 예를 들어 대상 위치가 10.240.1.4인 패킷의 경우 10.240.1.0/2410.240.0.0/16보다 더 구체적인 대상 위치입니다.

  3. 두 개 이상의 경로에 동일한 가장 구체적인 대상 위치가 포함된 경우 Google Cloud는 다음 프로세스를 사용하여 경로 후보에서 경로를 선택합니다. 경로 후보는 가장 구체적인 대상 위치를 가진 정적, 동적, 피어링 커스텀 경로입니다.

    1. VPC 네트워크가 피어 네트워크에 연결되어 있는 경우 Google Cloud는 단일 VPC 네트워크의 경로 후보를 제외한 모든 경로 후보를 삭제합니다.

      • 로컬 VPC 네트워크에 하나 이상의 경로 후보가 있는 경우 Google Cloud는 피어 네트워크의 모든 경로 후보를 무시합니다.

      • 로컬 VPC 네트워크에 있는 경로 후보는 없지만 여러 피어 네트워크에 있는 경로 후보가 있다면 Google Cloud는 피어 네트워크 중 1개에 정의된 경로 후보를 제외한 모든 경로 후보를 무시합니다. Google Cloud는 내부 알고리즘을 사용하여 단일 피어 네트워크를 선택하며, 이 알고리즘에서는 프로세스의 현재 경로 우선순위를 고려하지 않습니다. 새 네트워크와 피어링하거나 기존 피어 네트워크와의 연결을 해제하면 Google Cloud에서 선택한 VPC 네트워크 하나가 변경될 수 있습니다.

    2. Google Cloud는 우선순위가 가장 높은 경로 후보를 제외한 모든 경로 후보를 삭제합니다. 이로 인해 경로가 하나만 남게 되면 Google Cloud는 패킷을 다음 홉으로 보냅니다.

    3. 여러 경로 후보의 우선순위가 동일한 경우 Google Cloud는 경로의 다음 홉 및 경로 유형을 사용하여 삭제 프로세스를 계속 진행합니다. 이로 인해 경로가 하나만 남게 되면 Google Cloud는 패킷을 다음 홉으로 보냅니다.

      1. 다음 홉이 다음 홉 인스턴스, 다음 홉 IP 또는 다음 홉 VPN 터널인 커스텀 정적 경로를 가장 권장합니다. 이러한 다음 홉 유형을 사용하는 경로 후보가 있으면 다른 모든 경로 후보가 제거됩니다.

      2. 두 번째로 권장하는 것은 커스텀 동적 경로입니다.

      3. 다음 홉 내부 TCP/UDP 부하 분산기를 사용하는 커스텀 정적 경로는 세 번째로 권장합니다.

      4. 기본 인터넷 게이트웨이 다음 홉을 사용하는 커스텀 정적 경로를 가장 마지막으로 권장합니다.

    4. 경로 후보 중에서 2개 이상의 경로가 남았다면 이러한 경로는 모두 동일한 VPC 네트워크 내에 있으며 우선순위가 똑같습니다. Google Cloud는 어피니티에 5-튜플 해시를 사용하여 등가 멀티 경로 라우팅(ECMP)을 구현함으로써 경로 후보의 다음 홉 간에 트래픽을 분산합니다. 해시 계산은 각 패킷이 전송될 때 경로 선택 알고리즘에 의해 결정된 경로 후보의 수를 기반으로 수행됩니다. 경로 후보 수가 변경되면 해시가 동일한 5-튜플 해시가 있는 패킷을 다른 다음 홉으로 보낼 수 있습니다.

  4. 적용 가능한 대상 위치를 찾지 못하면 Google Cloud는 패킷을 삭제하고, ICMP 대상 또는 네트워크에 연결할 수 없다는 오류로 응답합니다.

특수 반환 경로

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 주소 범위를 포함할 수 있습니다(서브넷 마스크가 더 짧음). 이 경우 패킷이 서브넷 경로의 대상 위치보다 작은 범위에 속하지 않는 경우에만 정적 경로의 다음 홉으로 패킷이 전송됩니다. 가능한 가장 광범위한 대상 위치는 0.0.0.0/0입니다.

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

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

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

정적 경로의 다음 홉

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

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

  • 다음 홉 인스턴스(next-hop-instance). 이름영역을 지정하여 Google Cloud의 기존 인스턴스로 트래픽을 전달할 수 있습니다. 트래픽은 경로를 정의하는 VPC 네트워크의 VM 네트워크 인터페이스의 기본 내부 IP 주소로 전달됩니다.

    • VPC 네트워크에서 VM 인스턴스의 네트워크 인터페이스에 대한 기본 내부 IP 주소가 변경되면 Google Cloud는 VPC 네트워크의 라우팅 테이블을 자동으로 업데이트하여 트래픽이 새 IP 주소에서 VM으로 계속 전달되도록 합니다.

    • VM이 동일한 영역에서 동일한 이름의 새 VM으로 교체되면 Google Cloud는 VPC 네트워크의 라우팅 테이블을 자동으로 업데이트하여 트래픽이 대체 VM으로 전달되도록 합니다.

    • Google Cloud는 경로를 만들 때 다음 홉 VM이 존재하는지만 확인합니다. VM이 패킷을 처리하거나 전달할 수 있는지는 확인하지 않습니다. VM이 삭제되었지만 대체되지 않은 경우 그 경로가 여전히 적용되어 패킷이 삭제될 수 있습니다. 자세한 내용은 다음 홉으로 사용되는 인스턴스를 참조하세요.

  • 다음 홉 내부 TCP/UDP 부하 분산기(next-hop-ilb). 내부 TCP/UDP 부하 분산의 경우 부하 분산기의 IP 주소를 정상적인 백엔드 인스턴스 간에 트래픽을 분산하는 다음 홉으로 사용할 수 있습니다. 예를 들어 다음 홉이 내부 TCP/UDP 부하 분산기인 커스텀 정적 경로를 사용하여 트래픽을 백엔드 VM 간에 분산할 수 있습니다. 이 다음 홉을 사용하는 커스텀 정적 경로는 네트워크 태그를 사용하여 범위를 특정 인스턴스로 지정할 수 없습니다.

  • 다음 홉 IP(next-hop-address). Google Cloud VM에 할당된 내부 IP 주소를 다음 홉으로 제공할 수 있습니다.

    • next-hop-address를 사용하면 Google Cloud가 그 IP 주소에 할당된 VM 인스턴스로 트래픽을 전달합니다. VM 인스턴스를 동일한 IP 주소를 사용하는 다른 VM 인스턴스로 바꾸면 인스턴스의 이름이 달라도 트래픽이 대체 인스턴스로 이동합니다. VM 이름으로 다음 홉을 정의하려면 다음 홉 인스턴스를 대신 사용하세요.

    • 경로를 만들 때 Google Cloud는 IP 주소가 서브넷의 기본 또는 보조 IP 범위의 유효한 구성원인지만 확인합니다. 인스턴스가 다음 홉 IP 주소에 있는지는 확인하지 않습니다. 다음 홉 IP 주소가 인스턴스에 할당되지 않은 경우 경로가 계속 적용되고 따라서 패킷이 삭제될 수 있습니다. 자세한 내용은 인스턴스 및 부하 분산기의 다음 홉에 대한 고려사항을 참조하세요.

    • 임의 IP 주소를 다음 홉으로 지정할 수 없습니다. VPC 네트워크에서 서브넷의 IP 주소 범위를 벗어나는 주소는 허용되지 않습니다.

  • 다음 홉 VPN 터널(next-hop-vpn-tunnel). 정책 기반 라우팅 및 경로 기반 VPN을 사용하는 Cloud VPN 터널의 경우 다음 홉이 이름과 리전으로 터널을 참조하는 경로를 만들어 VPN 터널로 트래픽을 보낼 수 있습니다. Google Cloud는 다음 홉이 다운된 Cloud VPN 터널인 경로를 무시합니다. 경로와 Cloud VPN 터널이 상호 작용하는 방식의 더 많은 예시는 Cloud VPN 라우팅 예시를 참조하세요.

인스턴스 및 부하 분산기의 다음 홉에 대한 고려사항

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

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

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

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

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

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

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

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

다음 홉 인스턴스와 관련된 고려사항

  • 인스턴스를 다음 홉(next-hop-instance 또는 next-hop-address)으로 사용할 때 인스턴스가 영역별 리소스임을 기억하세요. 영역을 선택하면 묵시적으로 리전을 선택한 것으로 간주됩니다. Google Cloud는 다음 홉 인스턴스를 사용하는 경로의 리전 거리를 고려하지 않으므로 다른 리전의 다음 홉으로 트래픽을 보내는 경로를 만들 수 있습니다. 이렇게 하면 이그레스 비용이 추가되고 네트워크 지연이 발생합니다.

  • Google Cloud는 경로를 만들 때만 다음 기본 유효성 검사 중 하나를 수행합니다.

    • next-hop-instance를 지정하는 경우 이 인스턴스가 이미 존재해야 합니다.
    • next-hop-address를 지정하는 경우 IP 주소가 기존 서브넷의 기본 또는 보조 IP 범위에 있어야 합니다.
  • 예를 들어 인스턴스를 삭제하거나 나중에 서브넷을 삭제해도 Google Cloud는 적용 가능한 경로를 평가할 때 해당 인스턴스를 다음 홉으로 사용하는 모든 경로를 고려합니다. 이로 인해 네트워크의 다른 경로에 따라 특정 대상 위치의 일부 패킷 또는 모든 패킷이 삭제될 수 있습니다.

  • VM 인스턴스(예: VM의 운영체제 또는 패킷을 라우팅하는 VM의 프로세스)의 소프트웨어가 실패하면 해당 인스턴스로 향하는 패킷이 삭제됩니다. 신뢰성을 높이려면 그 대신 내부 TCP/UDP 부하 분산기를 다음 홉으로 사용하는 것이 좋습니다. 내부 TCP/UDP 부하 분산기에는 상태 확인이 구성되어야 하며 이 상태 확인은 새 연결이 라우팅되는 방식을 결정합니다.

  • 인스턴스의 게스트 운영체제를 구성하여 네트워크 인터페이스를 사용 중지해도 Google Cloud에서 인터페이스를 경로의 다음 홉으로 간주하기를 멈추지 않습니다.

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

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

다음 단계