이 페이지에서는 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튜플 해시)라는 두 가지 정보를 기반으로 해시가 계산됩니다.
다음 단계
- Cloud VPN의 기본 개념에 대해 알아보려면 Cloud VPN 개요를 참조하세요.
- Cloud VPN을 사용할 때 발생할 수 있는 일반적인 문제를 해결하려면 문제 해결을 참조하세요.