이 페이지에서는 Cloud VPN 터널의 다음 홉이 포함된 커스텀 경로가 Google Cloud에서 작동하는 방식을 설명합니다.
경로 적용 여부, 순서, 정적 경로 매개변수를 포함한 Google Cloud 경로에 대한 배경 정보는 Virtual Private Cloud(VPC) 경로 개요를 참고하세요.
경로 유형
Cloud VPN 터널은 VPC 네트워크의 커스텀 경로에 대한 다음 홉일 수 있습니다. Cloud VPN 터널의 다음 홉이 포함된 각 커스텀 경로는 VPC 네트워크에서 나가는 패킷의 이그레스 경로를 정의합니다.
Cloud Router는 항상 동적 라우팅을 사용하는 기본 VPN 터널 또는 HA VPN 터널을 관리합니다. Cloud Router는 BGP 공지를 수신하여 피어 VPN 게이트웨이로 BGP 메시지를 보냅니다.
Cloud Router는 VPC 네트워크에 동적 경로(즉, 피어 네트워크에 대상이 있는 경로)를 자동으로 만들고 제거합니다. 또한 피어 네트워크에 경로를 공지합니다. 즉, VPC 네트워크에 있는 서브넷의 IP 범위 또는 Cloud Router 구성에서 사용자가 지정하는 커스텀 대상으로 라우팅됩니다. VPC 네트워크의 동적 라우팅 모드는 Cloud Router가 가져오고 내보내는 경로 집합을 제어합니다.
정책 기반 또는 경로 기반의 기본 VPN 터널은 정적 라우팅을 사용합니다.
Google Cloud 콘솔을 사용하여 이러한 터널 중 하나를 만들면Google Cloud 는 Cloud VPN 구성에 지정된 원격 IP 주소 범위를 기준으로 정적 경로를 자동으로 만듭니다. Google Cloud CLI를 사용하여 이러한 터널을 하나 만드는 경우 터널을 다음 홉으로 사용하는 정적 경로를 수동으로 만들어야 합니다.
시나리오 예시
Google Cloud 는 패킷을 전송해야 할 다음 홉을 선택할 때 잘 정의된 적용 가능성 및 순서를 따릅니다. 다음 예시는 경로와 Cloud VPN 간의 일반적인 상호작용을 보여줍니다.
서브넷 경로와의 상호작용
다음 표에는 서브넷 경로와 커스텀 경로가 상호작용하는 방식이 나와 있습니다.
각 행은 VPC 네트워크에 있는 서브넷의 가능한 IP 범위를 나타냅니다. 온프레미스 범위는 10.2.0.0/16(IPv4) 및 fd20:a:b:c::/64(IPv6)입니다.
IPv6 트래픽은 IPv4 및 IPv6의 이중 스택 유형으로 구성된 HA VPN 게이트웨이에서만 지원됩니다.
VPC 네트워크
Cloud VPN 터널 라우팅
Google Cloud 서브넷의 IP 범위
정적(정책 기반, 경로 기반)
기본 VPN 전용
동적(BGP)
기본 VPN 또는 HA VPN
10.2.0.0/16
온프레미스 IP 범위와 동일
Google Cloud 에서는 대상이 10.2.0.0/16이고 다음 홉이 Cloud VPN 터널인 정적 경로를 만들 수 없습니다.
터널과 연결된 Cloud Router는 대상이 10.2.0.0/16인 모든 공지된 경로를 무시합니다. 대상이 10.2.0.0/16인 트래픽은 VPC 네트워크에 남게 됩니다.
fd20:a:b:c::/64
온프레미스 IP 범위와 동일
기본 VPN은 IPv6를 지원하지 않습니다.
터널과 연결된 Cloud Router는 대상이 fd20:a:b:c::/64인 모든 공지된 경로를 무시합니다. 대상이 fd20:a:b:c::/64인 트래픽은 VPC 네트워크에 남게 됩니다.
10.0.0.0/8
온프레미스 IP 범위보다 넓음
(더 작은 서브넷 마스크)
Google Cloud 에서는 대상이 10.2.0.0/16이고 다음 홉이 Cloud VPN 터널인 정적 경로를 만들 수 없습니다.
터널과 연결된 Cloud Router는 대상이 10.2.0.0/16을 포함한 10.0.0.0/8와 일치하거나 이 범위에 들어가는 모든 공지된 경로를 무시합니다. 대상이 10.0.0.0/8인 트래픽은 VPC 네트워크에 남게 됩니다.
fd20:a:b::/48
온프레미스 IP 범위보다 넓음
(더 작은 서브넷 마스크)
기본 VPN은 IPv6를 지원하지 않습니다.
터널과 연결된 Cloud Router는 대상이 fd20:a:b:c::/64을 포함한 fd20:a:b::/48와 일치하거나 이 범위에 들어가는 모든 공지된 경로를 무시합니다. 대상이 fd20:a:b::/48인 트래픽은 VPC 네트워크에 남게 됩니다.
10.2.99.0/24
온프레미스 IP 범위보다 좁음
(더 큰 서브넷 마스크)
Google Cloud 에서는 대상이 10.2.0.0/16이고 다음 홉이 Cloud VPN 터널인 정적 경로를 만들 수 있습니다. 하지만 10.2.99.0/24의 IP 주소 트래픽은 VPC 네트워크 내에 유지됩니다.
터널과 연결된 Cloud Router는 대상이 10.2.0.0/16인 모든 공지된 경로를 허용합니다. 단, 10.2.99.0/24의 IP 주소로 들어가는 트래픽은 VPC 네트워크 내에 남게 됩니다.
fd20:a:b:c::/80
온프레미스 IP 범위보다 좁음
(더 큰 서브넷 마스크)
기본 VPN은 IPv6를 지원하지 않습니다.
터널과 연결된 Cloud Router는 대상이 fd20:a:b:c::/64인 모든 공지된 경로를 허용합니다. 단, fd20:a:b:c::/80의 IP로 주소로 들어가는 트래픽은 VPC 네트워크 내에 남게 됩니다.
터널이 작동 중지된 경우
동적(BGP) 라우팅
동적 라우팅 또는 HA VPN 터널을 사용하는 기본 VPN 터널이 작동 중지되면 이를 관리하는 Cloud Router가 학습된 경로를 자동으로 삭제합니다. 손상을 감지하는 데 걸리는 시간은 양방향 전달 감지(BFD)가 사용 설정되었는지 여부에 따라 달라집니다. BFD가 사용 설정되었으면 BGP 대기 타이머가 만료될 때 감지가 수행됩니다.
그렇지 않으면 60초 이내에 감지가 수행됩니다. 터널이 다시 작동되면 학습된 경로를 다시 추가할 수 있습니다.
이 프로세스는 완전 자동으로 수행되지만 Cloud Router가 영향을 받는 경로를 삭제하는 동안 패킷 손실이 발생할 수 있습니다.
정적 라우팅
Google Cloud 는 IKE 보안 연결(SA)을 유효한 다음 홉으로 설정하지 않은 Cloud VPN 터널 사용은 고려하지 않습니다. Cloud VPN 터널이 IKE SA를 설정한 경우 Google Cloud에서는 이를 작동하는 것으로 간주합니다. 작동하는 Cloud VPN 터널은 라우팅 순서에 따라 다음 홉으로 선택된 경우에만 트래픽을 전달합니다. 보다 구체적인 대상을 포함하거나 더 높은 우선순위를 갖는 다른 경로의 다음 홉을 대신 사용해야 합니다.
다음 시나리오는 예상되는 동작을 보여줍니다.
동일한 대상에 여러 정적 경로가 있는 경우 각각 다음 홉 Cloud VPN 터널이 다르다면 Google Cloud는 IKE SA를 설정한 터널만 고려합니다(1단계). 작동이 중지되어 유효한 IKE SA가 없는 터널은 경로 우선순위를 고려하기 전에 무시됩니다.
예를 들어 192.168.168.0/24 대상에 3개의 정적 경로가 있다고 가정해 보겠습니다. 즉, 우선순위가 10인 첫 번째 경로의 다음 홉 Cloud VPN 터널은 작동 중지되었고, 우선순위가 20인 두 번째 경로의 다음 홉 터널은 작동 중이며, 우선순위가 30인 세 번째 경로의 다음 홉도 작동 중이라고 가정합시다. Google Cloud 는 다음 홉이 작동 중지된 경로보다 우선순위가 낮더라도 두 번째 경로의 다음 홉으로 트래픽을 전송합니다.
첫 번째 터널이 다시 설정되면 Google Cloud 은 해당 터널을 유효한 다음 홉으로 고려하므로 이 경로가 대신 사용됩니다.
대상이 동일한 정적 경로의 다음 홉 역할을 하는 모든 Cloud VPN 터널의 작동이 중지되면 트래픽이 삭제됩니다. 작동 중인 다음 홉 터널이 있는 더 넓은 범위의 대상에 대한 정적 경로가 있는 경우에도 트래픽이 삭제됩니다.
예를 들어 192.168.168.0/24에 대한 정적 경로가 있고 다음 홉 Cloud VPN 터널 작동이 중지(유효한 IKE SA 없음)되었다고 가정해 보겠습니다. 192.168.0.0/16에 대한 경로가 있어도 다음 홉이 작동 중인 Cloud VPN 터널이면 192.168.168.0/24로 들어가는 트래픽은 삭제됩니다. 이는 Google Cloud가 항상 가장 구체적인 대상이 있는 경로를 선택하기 때문입니다.
트래픽이 특정 다음 홉 Cloud VPN 터널에서 다른 터널로 전환되면 패킷 손실이 발생할 수 있습니다. 이동 중인 패킷도 삭제될 수 있으며 이 경우 다시 전송해야 합니다.
ECMP 지원 터널
동적 및 정적 라우팅의 경우, 대상이 같은 커스텀 경로가 2개 이상 있고 각 경로의 우선순위가 동일하며 활성(IKE SA 설정됨) 다음 홉 터널이 있으면 Google Cloud 는 동일 비용 다중 경로(ECMP) 라우팅을 사용하여 터널 간에 패킷을 분산합니다.
이러한 균형 조정 방법은 해시 기반이므로 터널이 작동되는 한 동일 흐름의 모든 패킷은 동일한 터널을 사용합니다.
ECMP 동작을 테스트하려면 iperf3을 사용하여 여러 개의 동시 TCP 스트림을 여러Google Cloud 가상 머신(VM) 인스턴스에서 Cloud VPN 터널을 통해 전송하는 것이 좋습니다. ECMP 동작을 검증해야 하는 경우에는 ICMP(ping)를 사용하여 테스트를 수행하지 마세요. 하나의 VM 인스턴스에서 수행되는 ping 테스트는 Cloud VPN 터널을 통해 ECMP 기반 이그레스를 테스트하기에 충분하지 않습니다. 소스 및 대상이 고정되어 있으면 터널이 한 개만 선택되기 때문입니다.
ICMP는 포트라는 개념을 사용하지 않는 고정 프로토콜이므로 소스 및 대상 주소(2튜플 해시)라는 두 가지 정보를 기반으로 해시가 계산됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-08(UTC)"],[],[],null,["# Order of routes\n\n| **Warning:** Certain Classic VPN dynamic routing functionality is deprecated. For more information, see [Classic VPN dynamic routing partial deprecation](/network-connectivity/docs/vpn/deprecations/classic-vpn-deprecation).\n\nThis page describes how custom routes with next hops of Cloud VPN\ntunnels work in Google Cloud.\n\nFor background information about Google Cloud routes, including\nroute applicability and order and static route parameters, see\nthe Virtual Private Cloud (VPC) [routes overview](/vpc/docs/routes).\n\nRoute types\n-----------\n\nA Cloud VPN tunnel can be a next hop for a custom route in your\nVPC network. Each custom route with a next hop Cloud VPN\ntunnel defines an *egress path* for packets leaving your VPC\nnetwork:\n\n- A Cloud Router always manages a Classic VPN tunnel that uses\n [dynamic routing](/network-connectivity/docs/vpn/concepts/choosing-networks-routing#dynamic-routing)\n or an HA VPN tunnel. The\n Cloud Router receives BGP advertisements from and sends BGP messages\n to a [peer VPN gateway](/network-connectivity/docs/vpn/concepts/key-terms#peer-definition).\n Cloud Router automatically creates and removes [dynamic\n routes](/vpc/docs/routes#dynamic_routes) in your VPC\n network---that is, the routes with destinations in a peer network. It also\n advertises routes to a peer network---that is, routes to the IP\n ranges of subnets in your VPC network or to [custom\n destinations that\n you specify](/network-connectivity/docs/router/how-to/advertising-custom-ip)\n in a Cloud Router configuration. The [dynamic\n routing mode](/vpc/docs/vpc#routing_for_hybrid_networks) of your\n VPC network controls the set of routes that\n Cloud Router imports and exports.\n\n- A policy-based or route-based Classic VPN tunnel uses [static\n routing](/network-connectivity/docs/vpn/concepts/choosing-networks-routing#static-routing).\n If you use the Google Cloud console to create one of these tunnels,\n Google Cloud automatically creates [static\n routes](/vpc/docs/static-routes) based on the remote IP ranges that you\n specify in the Cloud VPN configuration. If you use the Google Cloud CLI\n to create one of these tunnels, you must manually create the static routes\n that use the tunnel as a next hop.\n\nExample scenarios\n-----------------\n\nGoogle Cloud follows a well-defined\n[applicability and order](/vpc/docs/routes#instancerouting) when selecting\nthe next hop to which a packet should be sent. The following examples\ndemonstrate common interactions between routes and Cloud VPN.\n\n### Interaction with subnet routes\n\nThe following table demonstrates how subnet routes and custom routes interact.\nEach row represents a possible IP range of a subnet in a VPC\nnetwork. The on-premises ranges are `10.2.0.0/16` for IPv4 and `fd20:a:b:c::/64` for IPv6.\n\nIPv6 traffic is supported only by HA VPN gateways that are\nconfigured with a dual stack type of IPv4 and IPv6.\n\n### When tunnels are down\n\n#### Dynamic (BGP) routing\n\nWhen a Classic VPN tunnel that uses dynamic routing or an\nHA VPN tunnel goes down, the Cloud Router\nmanaging it automatically removes the learned routes. The length of time that\nit takes to detect the breakage varies depending on whether\n[Bidirectional Forwarding Detection (BFD)](/network-connectivity/docs/router/concepts/bfd)\nis enabled. If\nBFD is enabled, the detection occurs when the BGP holddown timer expires.\nOtherwise, detection occurs in less than 60 seconds. The learned routes can be\nre-added when the tunnel is re-established.\n\nThis process is fully automatic, but can still result in some packet loss during\nthe time that it takes for Cloud Router to remove the affected routes.\n\n#### Static routing\n\nGoogle Cloud never considers a Cloud VPN tunnel as a valid next\nhop that has not established an IKE security association (SA). If a\nCloud VPN tunnel has established an IKE SA, Google Cloud\nconsiders it operational. An operational Cloud VPN tunnel\nonly passes traffic if it is selected as the next hop according to the\n[routing order](/vpc/docs/routes#routeselection). The next hop for a different\nroute, with either a more specific destination or with a higher priority,\nmight be used instead.\n\nThe following scenarios demonstrate expected behaviors:\n\n- If you have multiple static routes for the same destination, each\n having a different next hop Cloud VPN tunnel, Google Cloud\n only considers those tunnels that have established IKE SAs (Phase 1). Tunnels\n that are down---that is, that do not have valid IKE SAs---are disregarded\n *before* considering route priority.\n\n For example, suppose that you have three static\n routes for the `192.168.168.0/24` destination: one with priority `10` whose\n next hop Cloud VPN tunnel is down, a second with priority `20` whose\n next hop tunnel is up, and a third with priority `30` whose next hop tunnel is\n also up. Google Cloud sends traffic to the second next hop, even\n though its route has a lower priority than the route whose next hop is down.\n If the first tunnel is re-established, then Google Cloud considers\n it a valid next hop and uses that route instead.\n- Traffic is dropped if all Cloud VPN tunnels serving as next hops for\n static routes with the same destination are down. Traffic is dropped even\n if there is a static route for a broader destination with an\n operational next hop tunnel.\n\n For example, suppose that you have a static route for\n `192.168.168.0/24` whose next hop Cloud VPN\n tunnel is down (no valid IKE SA). Even if you have a route for\n `192.168.0.0/16` whose next hop is an operational Cloud VPN tunnel,\n traffic to `192.168.168.0/24` is dropped. This is because Google Cloud\n always selects routes with the most specific destinations.\n\nWhen traffic switches from one next hop Cloud VPN tunnel to another,\nyou should still expect packet loss. In-flight packets might be dropped and need\nto be re-transmitted.\n\n### ECMP over tunnels\n\nFor both dynamic and static routing, if more than one custom route exists for\nthe same destination and has the same priority and an active (IKE SA\nestablished) next hop tunnel, Google Cloud uses equal-cost multipath\n(ECMP) routing to distribute packets among the tunnels.\n\nThis balancing method is based on a hash, so all packets from the same flow use\nthe same tunnel as long as that tunnel is up.\n\nTo test ECMP behavior, use [iperf3](/community/tutorials/network-throughput)\nto send multiple simultaneous TCP streams, ideally from multiple\nGoogle Cloud virtual machine (VM) instances,\nthrough Cloud VPN tunnels. If you need to validate ECMP behavior, do\nnot use ICMP (`ping`) to perform tests. A `ping` test from one VM instance isn't\nsufficient to test ECMP-based egress through Cloud VPN tunnels\nbecause only one tunnel is selected when you have a fixed source and destination.\nICMP has no concept of ports and is a fixed protocol, so the hash is only\ncalculated from two pieces of information: the source and destination addresses\n(a two-tuple hash).\n\nWhat's next\n-----------\n\n- To learn about the basic concepts of Cloud VPN, see the [Cloud VPN overview](/network-connectivity/docs/vpn/concepts/overview).\n- To help you solve common issues that you might encounter when using Cloud VPN, see [Troubleshooting](/network-connectivity/docs/vpn/support/troubleshooting)."]]
