VPC 로의 VPN 은 되지만 관리형 서비스가 시간 초과된다
터널은 고객 쪽 경계에서 끝나며 공급자의 정문에서는 끝나지 않는다. 경로를 바꾸기 전에 대상을 VM 호스팅, VPC 연결, 공개 전용 중 하나로 분류하라.
VPN 을 통해 관리형 데이터베이스에 접근하는 일이 실패하는 이유는 대개 런북에 적혀 있지 않은데, 터널은 고객 네트워크의 경계에서 끝나고 서비스는 애초에 그 경계 안쪽에 있지 않기 때문이다. 경로 테이블은 맞아 보이고 터널은 정상이라고 보고하는데 연결은 시간 초과된다. 아래 네 가지 점검을 순서대로 수행하고 통과 조건이 성립하지 않는 첫 지점에서 멈춰야 하며, 그 뒤의 점검은 앞선 점검이 통과했음을 전제한다.
점검 하나: 엔드포인트는 실제로 어디에 있는가?
VPN 게이트웨이는 주소 체계를 직접 관리하는 두 네트워크를 연결한다. 관리형 서비스는 공급자 자신의 정문 뒤에서 운영되며, 그 정문은 제품에 따라 세 가지 형태 중 하나를 취한다. 어떤 형태를 다루는지 모른다면, 장애가 라우팅 장애가 아닐 수도 있으므로 경로를 아무리 손봐도 소용없다.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
낭비되는 오후의 대부분은 이 분류를 건너뛰고 곧장 경로 테이블로 가는 데서 생긴다. 공개 엔드포인트를 가진 공급자 호스팅 서비스는 도면이 뭐라 하든 고객 터널 뒤에 있지 않고, VPC 연결 서비스는 공개 DNS 응답에 절대 나타나지 않는다.
점검 둘: ElastiCache 같은 VPC 연결 서비스
그런 종류의 캐시는 고객 자신의 VPC 안에서 주소가 지정되며 인터넷을 향한 리스너가 전혀 없다. 같은 VPC 에서 끝나는 클라이언트 VPN 은 거기에 닿을 수 있지만 세 조건이 동시에 성립할 때뿐이다. 캐시 엔드포인트가 터널이 볼 수 있는 서브넷에 연결되어 있어야 하고, 보안 그룹이 클라이언트가 오는 주소를 허용해야 하며, 클라이언트 쪽에는 캐시 서브넷을 덮는 경로가 있어야 한다.
흔한 실수는 근처 어딘가의 연결도 셈에 넣는 것이다. VPN 을 다른 VPC 에 붙이거나 피어링에만 기대는 것으로는 캐시의 보안 그룹이나 그 서브넷의 경로 테이블이 클라이언트까지 확장되지 않는다. 기존 터널이 다른 곳에서 끝난다면 그 VPC 안에 둔 점프 호스트나 VPN 서버가 흔한 대안이다. 그 대안은 설계가 아니라 우회이며 런북에도 그렇게 표시해야 한다.
점검 셋: 공개 이름을 가진 PaaS 엔드포인트
Azure Database for PostgreSQL 은 공개 서버 이름을 제공한다. hosts 파일에 고정해 게이트웨이로 라우팅할 수 있는 사설 주소를 주지는 않는다. 가상 네트워크 서비스 엔드포인트는 어떤 서브넷이 리소스에 닿을 수 있는지를 제한할 뿐, VPN 으로 들어오는 온프레미스 클라이언트를 승인하지는 않는다.
사설 접근을 얻으려면 사설 엔드포인트나 프라이빗 링크 설계를 도입한 뒤, 공개 이름이 인터넷 대신 그 엔드포인트로 응답하도록 사설 DNS 영역을 추가해야 한다. VPN 에 서비스 엔드포인트 규칙을 더한 구성은 도면에서만 비슷해 보이는 다른 아키텍처다. App Service 는 같은 논리를 반대 방향에서 따라, VNet 통합은 앱이 VNet 으로 나가는 호출을 하게 할 뿐 터널에서 들어오는 사설 경로를 만들지 않는다. 따라서 들어오는 사설 접근에는 사설 엔드포인트, App Service 환경, 또는 앱 앞에 둔 게이트웨이가 필요하며, 무엇을 쓸 수 있는지는 플랜에 달려 있다.
점검 넷: 자체 정문을 가진 제품
Firebase Hosting 은 Cloud VPN 에 붙일 수 없다. 호스팅 계층이 프로젝트 VPC 안의 무언가가 아니라 전 세계 공통 프런트엔드이기 때문이다. 문서화된 대안은 프록시 인스턴스나 버킷으로 뒷받침되는 로드 밸런서로 통제된 진입점을 직접 만드는 것이다. 어느 쪽이든 사이트는 순수한 호스팅 제품이기를 그치고 이제 직접 운영하는 인프라가 되며, 그 맞교환은 누군가 터널이 그것을 덮을 것이라고 약속하기 전에 이름 붙일 가치가 있다.
Private API Gateway 는 VPC 서비스 쪽에 더 가까워서, interface 형 VPC 엔드포인트는 응답이 사설 주소인 호스트 이름을 게시하고, 사업장에서 오는 트래픽은 터널이나 전용 상호 연결을 통해 도착한다. 엔드포인트는 API 에 연결되어 있어야 하고, 인증서와 호스트 이름은 호출자가 쓰는 사용자 지정 도메인과 일치해야 한다.
Google Cloud VPN 터널은 이름이 아니라 피어 IP 주소에 묶인다. DNS 전달은 따로 구성하므로, 터널이 완전히 건강해도 원격 사설 영역의 조회는 계속 실패할 수 있다.
그다음 경계를 찾아라
VPC 안의 VM 에서 같은 연결을 실행해, 거기서 성공하고 VPN 클라이언트에서 실패한다면 틈은 클라이언트 경로와 서비스 엔드포인트 사이에 있다. 경로, 보안 그룹, 엔드포인트 정책, 또는 이름이다. 두 시도가 모두 실패한다면 그 네트워크의 무엇도 서비스에 닿지 못하며, VPN 은 애초에 장애물이 아니었다.
getent hosts db.internal.example
nc -vz db.internal.example 5432이름 조회와 포트 점검은, 실패하는 이유가 다르고 이 둘을 나란히 보면 경로의 어느 절반이 끊겼는지 알 수 있으므로 따로 하라. 공개 주소로 해석되는 이름은 사설 DNS 영역이 작동하지 않는다는 신호다.