VPN 경유 Google API: 서브넷이 아니라 VIP로 라우팅하세요

VPC 서브넷으로 가는 경로가 API의 VIP를 선택하지는 않습니다. 올바른 이름을 해석하고, VIP 프리픽스를 알리고, VPC의 반환 경로를 유지한 다음 HTTPS를 시험하세요.

SSH로 온프레미스 서버에 접속해 터널을 올리면 프라이빗 VM이 응답하는데, 그다음 첫 Google API 호출은 경로가 없어 실패한다. VM 서브넷과 API VIP는 서로 다른 목적지이므로 하나에 대한 경로가 다른 하나를 선택하지 않는다. 프라이빗 API 호출이 동작하려면 세 가지 조건이 성립해야 한다. API 이름이 VIP로 해석되어야 하고, VIP 프리픽스가 터널을 넘어 알려져야 하며, VPC가 응답을 되돌려 보내는 방법을 알아야 한다. ping은 그중 어느 것도 알려주지 않으며, 서브넷 안의 머신으로 통하는 SSH 세션도 마찬가지다.

API VIP는 별개의 목적지다

Google은 온프레미스에서의 API 접근을 위해 전용 VIP를 공개하며, API 이름에 대해 DNS가 돌려줘야 하는 주소가 바로 그것이다. 둘 다 작은 프리픽스이고 어느 것도 RFC 1918 공간이 아니다:

RecordResolves toWhat it does not give you
private.googleapis.com199.36.153.8/30, the general front door for Google APIsnot a bypass around a service perimeter
restricted.googleapis.com199.36.153.4/30, reachable only for services a perimeter allowsnot the whole API surface, so some names stay out of reach

공인처럼 보이는 주소라고 해서 경로가 터널을 떠나야 한다는 뜻은 아니다 일반 인터넷을 향해서는. 프리픽스가 있는 이유는 온프레미스 클라이언트가 임의의 이그레스 지점이 아니라 지원되는 경로로 Google 프런트엔드에 도달하게 하기 위해서다. 터널에 속한 목적지로 취급하고, 조사할 호스트로 보지 않는다. 인터넷 이그레스용으로 작성된 방화벽 규칙은 보통 이들을 버리며, 호출이 시작되기도 전에 실패하는 흔한 이유가 이것이다.

어느 엔드포인트에 도달하는지는 DNS가 정한다

선택한 엔드포인트에 대해 Google이 문서화한 레코드로 로컬 리졸버를 돌려, 애플리케이션에 필요한 이름이 그 VIP로 응답하게 한다. 단지 googleapis.com 를 매핑하는 것은 목록이 아니다. 패키지 레지스트리, 컨테이너 레지스트리, 마이그레이션 커넥터에는 각자의 문서화된 이름이 있다. 제한 VIP도 모든 서비스를 나르지는 않으므로 해석되는 이름이라도 여전히 지원되지 않을 수 있으므로, 리졸버를 건드리기 전에 애플리케이션이 실제로 접속하는 도메인을 적어 두자.

서비스 이름 대신 VPC VM 주소를 짐작하는 것은 해결이 아니며, 보통 다른 클라이언트가 실패할 때까지 DNS 공백을 감춘다.

VIP 프리픽스를 알리고 나머지는 유지하라

BGP 기반 연결에서는 Cloud Router가 선택한 VIP 프리픽스를 알려야 온프레미스 라우터가 의도한 세션을 통해 그 범위를 학습한다. VPC 서브넷만 알리면 그 범위가 더해지지 않고, 온프레미스 라우터는 그 주소들에 기본 경로를 계속 사용한다. 라우팅 테이블의 프리픽스만이 알림이 세션을 건넜다는 유일한 증거다.

새것을 더하는 동안 기존 알림을 유지해야 하는데, 라우터 수준과 피어 수준 옵션은 도달 범위가 달라 집합을 바꾸면 이미 동작하던 네트워크가 철회될 수 있다. 그다음 라우터 전체가 아니라 세션마다 유효 알림을 확인하라. 빠진 프리픽스와 철회된 프리픽스는 온프레미스 쪽에서 똑같이 보이므로, 누락과 퇴행을 가르는 것은 세션 뷰다.

VPC 쪽에는 자체 경로와 반환 경로가 필요하다

VPC 내부에서 VIP 경로는 다음 홉으로 기본 인터넷 게이트웨이를 써야 하며, 이름과 달리 그 트래픽은 Google 네트워크 안에 머문다. VPC에는 VPN을 통해 온프레미스 원본으로 돌아가는 경로도 필요하고, 이는 알린 프리픽스와 별개의 객체다. 터널과 클라이언트가 같은 리전에 없을 때는 문서화된 리전 라우팅 요구 사항을 고려하라.

반환 경로를 따로 확인해야 하는데, 요청 방향이 동작해도 응답 방향의 고장은 가려진다. 두 방향, 두 경로가 있고 각각은 자기 증상으로 실패한다.

요청을 시험하고, 그다음 거부를 읽어라

ICMP 에코는 이 VIP에서 응답을 받지 못하므로 실패한 ping은 아무것도 증명하지 못하고 성공한 ping은 아주 적게 증명한다. 실제 클라이언트에서 이름의 응답과 선택된 경로를 확인하고, 그다음 관심 있는 서비스로 권한이 부여된 HTTPS 요청을 보낸다. 요청이 서비스에 도달했는데 거부되면 자격 증명, IAM, 적용되는 서비스 경계 정책을 살펴라.

프라이빗 라우팅은 API 권한을 부여하지 않고, 아이덴티티가 무엇을 할 수 있는지도 바꾸지 않으므로, 전송 성공과 권한 있는 응답은 별개의 결과이며 둘 다 필요하다. IPv6 경로도 명시적으로 유지하라. IPv4 프리픽스를 설정하는 것은 IPv6를 선호하는 클라이언트에 대해 아무것도 말해 주지 않는다.

Google의 온프레미스 Private Google Access 안내서 는 DNS 레코드와 라우팅 요구 사항을 함께 다루므로, 리졸버와 알림 설정을 포럼 글이 아니라 이 안내서와 비교하라. 그다음 같은 요청을 다시 실행하고 응답과 경로를 같은 티켓에 기록하라.

관련 글