VPN을 통한 Cloud SQL 프라이빗 IP: 아무도 내보내지 않는 경로

많은 팀이 Cloud SQL 프라이빗 IP가 VPC 내부에서만 작동한다고 믿고, 그 믿음은 실패가 데이터베이스 문제처럼 보이기 때문에 유지됩니다. Google은 Cloud VPN이나 Cloud Interconnect로 연결된 네트워크에서의 접근을 문서화합니다. 그 네트워크에 필요한 것은 특별한 데이터베이스 기능이 아니라 절반만 구성해 두기 쉬운 두 개의 경로 교환입니다. 터널은 올라오고, 컴퓨트 인스턴스는 응답하며, 데이터베이스 연결은 시간 초과됩니다. 사람들을 잘못된 콘솔로 보내는 바로 그 조합입니다.

오해: 프라이빗 IP는 VPC에 대해 프라이빗이라는 뜻

프라이빗 서비스 액세스는 당신의 네트워크와 Google이 소유한 프로듀서 네트워크 사이의 VPC 피어링입니다. 서비스에 할당된 범위는 프로듀서 쪽에 있고, 인스턴스 주소는 그 안에 있습니다. 이 피어링 때문에 프로젝트의 데이터베이스가 당신의 명시적 서브넷에 포함되지 않아도 VPC가 경로를 가진 주소에 있을 수 있습니다.

피어링이기 때문에 피어링 동작도 있습니다. 사용자 지정 경로가 자동으로 넘어가지 않는 부분도 그중 하나입니다.

오해: 작동하는 터널은 데이터베이스 경로도 함께 나른다

두 개의 범위가 이 여정을 견뎌야 합니다. 첫째는 클라이언트 접두사입니다. 온프레미스 네트워크는 구체적인 접두사로 Cloud Router에 알려져 있어야 합니다. 기본 경로는 프로듀서 네트워크가 반환 경로에 필요로 하는 임포트를 제공할 수 없기 때문입니다. 둘째는 할당된 서비스 범위이며, 외부 측이 이를 학습해야 데이터베이스로 가는 패킷에 목적지가 생깁니다. 이들은 서로 다른 경계에서 유지되는 서로 다른 경로이고, 하나를 고치면 다른 하나는 깨진 채로 남습니다.

Google 쪽에서는 해당 피어링 연결에서 Export custom routes를 활성화하고, 터널을 위해 Cloud Router가 광고하는 경로에 할당된 서비스 범위를 추가하는 것을 뜻합니다.

이미 있는 광고는 유지하십시오. 서비스 범위를 추가하면서 같은 BGP 세션이 다른 트래픽을 위해 나르는 VPC 경로를 제거해서는 안 되며, 광고 집합을 통째로 교체하는 것은 첫 번째 장애 뒤에 숨은 두 번째 장애입니다. 외부 장치의 유효 경로도 확인하십시오. VPN 게이트웨이나 다른 서브넷에 도달하는 것은 전송만 증명합니다.

오해: Cloud SQL Auth Proxy가 네트워크를 해결한다

The Auth Proxy 애플리케이션과 인스턴스 사이에 지원되는 인증과 암호화된 전송을 제공합니다. 경로를 만들지는 않습니다. 프라이빗 네트워크로 가는 경로가 없는 호스트에서 시작한 프록시는 직접 연결과 똑같이 실패하며, 그 로그는 이유에 대해 덜 도움이 됩니다. 프록시를 연결이 있는 호스트로 옮기면 경로의 어느 구간이 작동해야 하는지가 바뀌고, 그것은 우회가 아니라 실제 설계 결정입니다.

그것이 하지 않는 일은 연결이 끊긴 노트북이 프라이빗 전용 인스턴스에 도달하게 하는 것입니다.

오해: Private Service Connect도 같은 규칙을 따른다

Private Service Connect는 자신의 서브넷에 있는 엔드포인트와 자신이 제어하는 DNS 구성을 사용하므로, 그곳으로 가는 경로는 자신이 소유한 주소로 가는 평범한 경로입니다. 피어링 내보내기 설정은 그 설계에 적용되지 않으며, 피어링 변경을 PSC 배포에 복사하면 도달 가능성을 늘리지 않고 위험만 늘립니다.

둘 다 프라이빗 주소를 주지만, 비슷한 것은 거기까지입니다.

올바른 순서로 경로를 테스트하십시오

외부 클라이언트에서 먼저 데이터베이스의 TCP 엔드포인트를 테스트하십시오. TCP 핸드셰이크가 완료되면 라우팅, 방화벽, 리스너가 모두 갖춰졌다는 뜻이고, 다음 테스트는 허용된 인증 작업입니다. 그 시점의 인증 거부는 사실 좋은 소식입니다. 데이터베이스 리스너가 응답했다는 것을 증명하기 때문입니다. ICMP 시간 초과는 데이터베이스 접근에 대해 거의 아무것도 말하지 않습니다. 많은 경로가 TCP는 문제없이 전달하면서 ICMP는 버리기 때문입니다.

클라이언트 범위가 RFC 1918 밖이라면, 설계가 지원되지 않는다고 결론 내리기 전에 추가 경로 내보내기와 네트워크 승인 요구 사항을 검토하십시오.

연결과 함께 네 가지 객체를 기록하십시오. 외부 접두사, 할당된 서비스 범위, 관련된 피어링 연결, 광고하는 라우터입니다. 이 네 가지가 프라이빗 경로 전체를 설명하며, Cloud SQL이 항상 프록시가 필요하거나 VPN으로는 전혀 도달할 수 없다는 속설을 대체합니다.