GCP Cloud VPN: 게이트웨이, 터널, 방화벽을 순서대로 점검하세요

모든 프로브가 시간 초과되는데 터널이 설정됨으로 보고된다면 보통 VPC 방화벽 규칙이 빠져 있습니다. 게이트웨이, 선택기, 라우팅 유형을 그 순서로 점검하세요.

콘솔에는 초록색 터널이 보이는데 온프레미스 모니터링은 여전히 어떤 인스턴스에도 닿지 못하고, 터널을 다시 만드는 것이 뻔한 해결책처럼 보입니다. 그러나 그런 경우는 드뭅니다. 설정된 터널은 두 게이트웨이가 IKE 교환을 마쳤다는 것만 증명합니다. 패킷이 VPC로 한 번이라도 허용되었는지는 전혀 말해 주지 않습니다.

그 초록색 아이콘과 응답 사이에는 네 가지 결정이 있고, 그것들은 예측 가능한 순서로 실패합니다. 가장 저렴한 것부터 처리하세요.

세 개의 객체, 그중 암호화하는 것은 하나뿐

VPN 게이트웨이는 상대 측이 암호화해 보내는 외부 주소를 소유합니다. 콘솔에서 직접 만들 일은 없으며, 연결 양식 안에서 주소를 선택하거나 예약하면 게이트웨이가 그것과 함께 나타납니다. HA 게이트웨이는 두 인터페이스에 두 주소를 차지하며, 이는 나중 쿼터 점검에서 중요합니다.

터널은 그 게이트웨이와 상대 측 사이의 짝입니다. 공유 비밀과 보호하겠다고 약속한 트래픽 선택기를 나릅니다. 대부분의 조용한 장애는 바로 그 선택기에서 시작됩니다. 로컬 선택기가 10.0.0.0/24를 덮는 터널은 상태가 아무리 건강해 보여도 10.0.1.0/24를 전달하지 않습니다.

원격 측은 자체 목록을 유지하며 보통 암호화 도메인이라고 부르고, 종단 하드웨어가 그것을 여러분의 목록과 비교합니다. 어느 쪽도 한 번도 주어지지 않은 선택기를 협상하지 않습니다.

라우팅 유형이 라우팅 테이블에 무엇이 도달하는지를 결정합니다

Cloud VPN은 세 가지 라우팅 형태를 제공하며 그것들은 깔끔하게 섞이지 않습니다. 정책 기반 라우팅은 정적 선택기 쌍을 유지하고, 경로 기반 라우팅은 정적 경로를 직접 추가하기를 기대하며, 동적 라우팅은 BGP를 통해 Cloud Router로 프리픽스를 알립니다. 의도적으로 하나를 고르세요.

손으로 쓴 정적 경로를 옆에 둔 동적 터널은 BGP 세션이 흔들릴 때마다 비는 라우팅 테이블을 만듭니다.

동적만이 터널을 다시 만들지 않고 보호 프리픽스를 바꿀 수 있는 형태이며, Cloud Router를 검증해야 할 객체 집합으로 끌어들입니다. 상대 측이 BGP를 말할 수 없는 하드웨어 방화벽이라면 정적 선택기는 여전히 쓸 만합니다. 그때는 양쪽 끝에 같은 범위가 필요하고, 더 구체적인 항목이 양쪽에서 이겨야 합니다. 서브넷 하나만큼 어긋난 쌍은 설정된 뒤 트래픽의 절반만 나릅니다.

암묵적 거부는 터널 뒤에 있습니다

인바운드 트래픽은 가장 낮은 우선순위의 암묵적 거부와 비교해 평가되며, 그 규칙은 패킷이 암호화되어 도착했는지 신경 쓰지 않습니다. 방화벽 규칙이 온프레미스 범위와 사용 중인 포트를 지목하기 전까지 패킷은 복호화되고 검사되고 버려집니다. VPN 로그는 터널이 약속한 것을 정확히 했으므로 내내 깨끗합니다.

터널이 살아 있는데 프로브가 시간 초과되면 대신 방화벽 거부 로그를 읽고, 그다음 규칙을 소스 범위와 필요한 포트로 좁히세요:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

한쪽 방향만 통하는 것은 방화벽의 단서입니다

아웃바운드는 암묵적 허용 규칙이 인스턴스를 어디로든 보내도록 두기 때문에 다르게 동작합니다. VM에 닿지 못하는 데이터 센터는 흔히 반대 방향으로는 완벽하게 동작하는 아웃바운드 경로 뒤에 있습니다. 이 비대칭이 양쪽 방향을 한꺼번에 끊는 라우팅 결함과 방화벽 누락을 갈라 줍니다. 규칙을 하나 더 고치기 전에 반대 방향을 시험하세요.

주소 생성도 쿼터 작업입니다. 사용 중인 외부 주소 한도에 가까운 프로젝트는 권한 실패처럼 읽히는 오류로 연결을 거부합니다.

선택기, 쿼터, 그다음 네 가지 점검

콘솔에서 만든 터널은 생성된 경로가 트래픽을 올바로 나르는데도 gcloud compute vpn-tunnels describe에서 빈 원격 트래픽 선택기를 돌려주곤 합니다. 터널이 잘못됐다고 판단하기 전에 API가 기록한 내용을 실제로 보호하는 범위와 비교하세요. API나 SDK로 만들면 선택기가 명시적으로 유지됩니다.

쿼터도 놓치기 쉬운 지점입니다. 증액은 유지보수 창이 시작되기 전에 요청하고, 주소 수는 게이트웨이와 같은 프로젝트에서 확인하세요.

바깥에서 안으로 진행하세요: 상대 측 상태, 두 선택기 목록, 각 측의 경로, 소스 범위와 포트에 대한 인바운드 규칙, 그다음 패킷 캡처입니다. 서브넷을 추가할 다음 엔지니어에게 세 가지가 모두 필요하므로, 터널이 새것일 때 게이트웨이 주소, 두 선택기 목록, 라우팅 유형을 변경 티켓에 적어 두세요.

관련 글