Google Cloud VPC에 대한 개발자 원격 액세스: 경로를 선택하세요
IAP, 원격 액세스 VPN, Cloud VPN은 서로 다른 문제를 해결합니다. 리스너를 열기 전에 경로를 목적지와 신원에 맞추세요.
개발자에게는 SSH 세션 하나, 데이터베이스 포트 하나, 또는 십여 개의 프라이빗 서비스에 대한 폭넓은 액세스가 필요하며, 그 요청은 모두 같은 질문처럼 보입니다. 그렇지 않습니다. 목적지, 프로토콜, 관련된 신원이 어떤 Google Cloud 액세스 경로가 맞는지를 결정하며, 기본값으로 가장 넓은 것을 고르면 떠맡을 필요가 없었던 일이 생깁니다.
목적지와 프로토콜을 적어 두세요
작업에 실제로 필요한 프라이빗 주소, 포트, 프로토콜을 나열한 다음, 어떤 신원을 별도로 인증해야 하는지 표시하세요. 데이터베이스 포트와 프라이빗 DNS 영역은 서로 다른 요구 사항이며, UDP 서비스는 아래 옵션 중 하나를 완전히 배제합니다. 작성된 목록은 무엇을 부여하지 않는지도 보여 줍니다. 검토자가 묻는 부분이 바로 그것입니다.
리스너를 열기 전에 이렇게 하세요. 목록은 나중에 인수 테스트가 되며, 좁은 터널과 우연히 동작하는 넓은 터널을 구분하는 유일하게 신뢰할 수 있는 방법입니다.
몇몇 TCP 서비스에는 IAP
Identity-Aware Proxy의 TCP 포워딩은 서비스를 인터넷에 노출하지 않고 적격 VM 리소스로 인증된 터널을 제공합니다. 일상적인 형태는 gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a이며, 단일 포트는 gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a로 로컬에서 포워딩할 수 있습니다.
호출자에게 IAP 터널 액세스 역할이 필요하고, 방화벽이 IAP 소스 범위를 허용해야 하며, 목적지가 인스턴스에서 도달 가능해야 한다는 세 가지가 맞아야 합니다. 터널을 만들 권한은 데이터베이스 자격 증명, SSH 로그인 또는 RDP 세션이 아니므로 애플리케이션 인증은 제자리에 두세요.
IAP TCP 포워딩은 네트워크 계층 VPN이 아닙니다. 선택한 목적지로 TCP를 전달할 뿐 임의의 IP 트래픽이나 UDP를 전달하지 않으며, 애플리케이션이 여러 서비스에 걸쳐 프라이빗 DNS를 필요로 할 때는 적합하지 않습니다.
더 넓은 도달 범위를 위한 원격 액세스 VPN
여러 목적지, 프로토콜 또는 프라이빗 DNS 영역이 필요할 때는 VM이나 지원되는 어플라이언스에서 명시적으로 관리되는 원격 액세스 VPN이 더 나은 형태입니다. 그 배포는 Google이 관리하는 Cloud VPN과 별개이며, 클라이언트 신원 등록, 소프트웨어 업데이트, 클라이언트 경로, VPC 반환 경로는 사용자가 소유합니다.
공용 리스너만이 아니라 전체 목록을 계획하세요. 터널 풀, 그쪽으로 돌아가는 VPC 경로, 포워딩 제어, DNS 확인, 서비스별 액세스 정책을 포함하세요. 연결은 되지만 내부 이름을 확인할 수 없는 VPN은 한 번도 연결되지 않는 VPN만큼이나 개발자의 작업 흐름을 완전히 실패하게 만듭니다.
Cloud VPN은 사이트 게이트웨이이지 노트북 프로필이 아닙니다
Google Cloud VPN은 IPsec을 통해 피어 게이트웨이를 연결하며, 그 자주 묻는 질문은 그 사이트 간 역할을 클라이언트-게이트웨이 액세스와 구분합니다. 터널을 만들어도 직원이 노트북으로 가져오는 프로필이 생기지 않습니다. 누군가 Cloud VPN 프로필을 요청할 때 이 구분이 중요합니다. 답은 다른 제품입니다.
게이트웨이가 잘하는 것은 사무실 네트워크 뒤의 머신에 VPC로 들어가는 경로를 주는 것입니다. 모든 직원을 인증하지도, 애플리케이션 권한을 부여하지도 않으므로 그 정책은 신원별로 적용할 수 있는 네트워크 및 애플리케이션 계층에 남습니다.
검증하고 기록하세요
가장 좁은 목적지부터 시험하고, 그다음 DNS가 필요한 목적지, 그다음 거부된 상태로 남아야 하는 목적지를 시험하세요. 관리자 워크스테이션에서의 성공은 다른 네트워크를 쓰는 개발자 노트북에 대해 거의 아무것도 증명하지 못하므로, 각 시험은 프로덕션에서 그 경로를 사용할 동일한 클라이언트에서 실행하세요.
선택한 모델, 그것이 포괄하는 목적지, 인증하는 신원, 경로를 사용할 수 없을 때의 실패 동작을 기록하세요. 그 기록이 다음 요청이 문서화된 설계에 목적지 하나를 추가하는 대신 터널을 조용히 넓히는 것을 막습니다.