Cloud Run에서 온프레미스 VPN으로: Direct VPC 이그레스 설정

터널은 올라가 있고 VM은 온프레미스 서버에 도달하는데, 같은 호스트로 가는 Cloud Run 서비스는 시간 초과가 납니다. 이것이 이 작업의 흔한 출발점이며, 터널 자체가 원인인 경우는 드뭅니다. Cloud Run 리비전은 기본적으로 VPC 안에 있지 않습니다. 연결된 뒤에도 이미 라우팅한 VM 서브넷이 아니라 자체 소스 주소를 사용합니다. 아래 런북은 서비스를 연결하고, 실제 소스 범위를 라우팅한 다음, 요청을 처리한 리비전에서 경로를 증명합니다. 이 순서대로 실행하세요. 첫 단계를 건너뛰는 것이 이런 사례가 아무것도 고치지 않는 VPN 변경으로 끝나는 이유입니다.

터널을 디버그하기 전에 리비전을 연결하세요

Cloud Run은 Direct VPC 이그레스를 지원하며, Serverless VPC Access 커넥터 없이 서비스 트래픽을 VPC의 서브넷에 올립니다. 기존 서비스의 업데이트는 다음과 같습니다:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

자리 표시자를 바꾸고, 배포가 라이브 트래픽에 무엇을 하는지 검토하고, 서비스 리전에서 충분한 주소 용량과 올바른 네트워크 권한을 갖춘 서브넷을 선택하세요.

대상에 맞는 이그레스 모드를 선택하세요

private-ranges-only 는 프라이빗으로 분류한 대상만 VPC를 통해 보냅니다. «VPN으로 도달할 수 있는 모든 것»을 뜻하지 않으며, 온프레미스 서비스가 설정이 그렇게 분류하지 않는 범위에 있을 때 그 차이가 드러납니다. 대상이 포함되지 않으면 all-traffic 가 다른 문서화된 모드이며, 서비스의 공개 종속성을 포함해 모든 것을 VPC를 통해 보냅니다. 의식적으로 선택하고 그 결과를 변경 기록에 남기세요.

이미 커넥터를 쓰는 서비스는 토글이 아니라 마이그레이션이므로, 둘 다 구성하지 말고 계획하세요.

VM 소스가 아니라 Cloud Run 소스를 라우팅하세요

Direct VPC 이그레스는 선택한 서브넷에서 임시 주소를 할당하고, 온프레미스 쪽은 그 범위로 트래픽을 돌려보내야 합니다. 다른 VM 서브넷을 위해 작성한 반환 경로나 방화벽 허용은 다이어그램에서는 맞아 보이지만 실제로는 실패합니다. 서브넷 CIDR은 기억이 아니라 VPC에서 가져오고, 원격 장비의 크립토 ACL이나 라우팅 테이블에 포함되어 있는지 확인하세요.

동적 라우팅에서는 Cloud Router가 실제로 광고하는 내용과 VPC가 가져오는 내용을 사용자 지정 광고 정책까지 포함해 확인하세요. 콘솔에 있지만 이 대상에 선택되지 않은 경로는 경로가 없는 것과 같습니다.

모두 충족해야 하는 세 가지 조건

동작하는 경로에는 다음이 모두 필요하며, 각각은 저마다의 방식으로 실패합니다:

• VPC에 의도한 Cloud VPN 연결을 통해 온프레미스 프리픽스로 향하는 경로.
• 온프레미스 쪽에 Cloud Run 서브넷으로 가는 반환 경로.
• 소스, 대상, 포트를 허용하는 방화벽 및 IPsec 보호 범위.

경로가 없으면 보통 원격 쪽에 증거가 없는 시간 초과로 보입니다. 반환 경로 문제는 요청은 도착하고 응답이 사라지는 모습으로 보입니다. 방화벽이나 선택자 문제는 장비에 따라 거부나 조용한 드롭처럼 보일 수 있습니다. 세 가지 중 무엇인지 파악하면 다음 명령의 범위가 크게 좁아집니다.

임시 Cloud Run 주소 하나를 허용 목록에 넣지 마세요. 서브넷 범위와 애플리케이션에 맞는 권한 설계를 사용하세요.

요청을 처리한 리비전을 테스트하세요

테스트 전에 배포된 네트워크 설정과 트래픽 배분을 확인하세요. 업데이트로 새 리비전이 생겨도 요청은 여전히 이전 리비전에 도달할 수 있습니다. 그런 다음 사용자 요청이 수행하는 것과 같은 작업을 그 리비전에서 실행하세요. 대상이 프라이빗 호스트 이름이라면 그 환경에서의 이름 해석과 생성된 주소를 확인하세요. 노트북의 기업 DNS 응답은 서비스의 네임스페이스에 대해 아무것도 증명하지 않습니다. TLS 호스트 이름 검증과 원격 애플리케이션 자체의 인증은 유지하세요.

Direct VPC의 문서화된 시작 연결 지연을 예상하고, 콜드 스타트마다 끊긴 터널로 진단하는 대신 클라이언트에 준비 상태나 재시도 전략을 주세요.

롤백과 이것이 하지 않는 일

롤백하려면 서비스의 네트워크와 이그레스 설정을 이전 값으로 되돌리고 이전 리비전이 여전히 트래픽을 처리하는지 확인하세요. gcloud 명령을 변경 기록에 남기세요. 부분 변경의 반대는 육 주 후에는 분명하지 않습니다. VPC 연결을 제거하면 서비스가 이전 이그레스 경로로 돌아가며, 인시던트 중에는 그것이 바로 원하는 것일 수 있습니다.

이 설계는 Cloud Run이 시작하는 연결과 그 응답을 다룹니다. 온프레미스 네트워크에 서비스 내부의 주소 지정 가능한 소켓을 주지는 않습니다. 인바운드 노출은 ingress 결정이기 때문입니다.