네트워킹은 Google Cloud 조직 내에서 그리고 클라우드 환경과 온프레미스 환경 사이의 통신을 위한 리소스에 반드시 필요합니다. 이 섹션에서는 VPC 네트워크, IP 주소 공간, DNS, 방화벽 정책, 온프레미스 환경에 대한 연결의 청사진 구조에 대해 설명합니다.
네트워크 토폴로지
청사진 저장소는 네트워크 토폴로지에 대해 다음 옵션을 제공합니다.
- 환경 간에 직접 허용되는 네트워크 트래픽 없이 각 환경에 개별 공유 VPC 네트워크 사용하기
- 허브 및 스포크 모델을 사용하여, 네트워크 가상 어플라이언스(NVA)로 통제되는 환경 간의 네트워크 트래픽으로 Google Cloud의 각 환경을 연결하는 허브 네트워크 추가하기
환경 간에 직접 네트워크 연결을 원하지 않으면 이중 공유 VPC 네트워크 토폴로지를 선택하세요. 해당 환경의 모든 서버에 직접 네트워크 경로가 필요한 기존 도구에 의지할 때처럼 NVA에서 필터링되는 환경 간에 네트워크 연결을 허용하려면 허브 및 스포크 네트워크 토폴로지를 선택하세요.
두 토폴로지 모두 공유 VPC를 기본 네트워킹 구성 요소로 사용하는데, 이는 공유 VPC는 책임 소재를 명확하게 구분할 수 있기 때문입니다. 네트워크 관리자는 중앙 집중식 호스트 프로젝트에서 네트워크 리소스를 관리하고 워크로드팀은 자체 애플리케이션 리소스를 배포하고 호스트 프로젝트에 연결된 서비스 프로젝트에서 네트워크 리소스를 사용합니다.
두 토폴로지에는 각 VPC 네트워크의 기본 버전과 제한된 버전이 포함됩니다. 기본 VPC 네트워크는 민감하지 않은 정보가 포함된 리소스에 사용되고, 제한된 VPC 네트워크는 VPC 서비스 제어가 필요한 민감한 정보가 있는 리소스에 사용됩니다. VPC 서비스 제어 구현에 대한 자세한 내용은 VPC 서비스 제어로 리소스 보호를 참조하세요.
이중 공유 VPC 네트워크 토폴로지
Google Cloud에서 개발, 비프로덕션, 프로덕션 네트워크 간에 네트워크 격리가 필요한 경우 이중 공유 VPC 네트워크 토폴로지를 사용하는 것이 좋습니다. 이 토폴로지에서는 각 환경에 대해 개별 공유 VPC 네트워크를 사용하고, 각 환경은 기본 공유 VPC 네트워크 및 제한된 공유 VPC 네트워크 간에 추가로 분할됩니다.
아래는 이중 공유 VPC 네트워크 토폴로지를 보여주는 다이어그램입니다.
이 다이어그램은 이중 공유 VPC 토폴로지의 주요 개념을 설명합니다.
- 각 환경(프로덕션, 비프로덕션, 개발)에는 기본 네트워크용 공유 VPC 네트워크 1개와 제한된 네트워크용 공유 VPC 네트워크 1개가 있습니다. 이 다이어그램에서는 프로덕션 환경만 표시되어 있지만, 각 환경에는 동일한 패턴이 반복됩니다.
- 각 공유 VPC 네트워크에는 서브넷이 서로 다른 리전에 있는 두 개의 서브넷이 있습니다.
- 4개의 Cloud Router 서비스(중복화를 위해 각 리전에 2개씩)를 사용하여 각 공유 VPC 네트워크의 Dedicated Interconnect 인스턴스에 4개의 VLAN 연결을 통해 온프레미스 리소스와의 연결이 설정됩니다. 자세한 내용은 온프레미스 환경과 Google Cloud 간의 하이브리드 연결을 참조하세요.
기본적으로 이 토폴로지에서는 네트워크 트래픽이 환경 간에 직접 이동하는 것을 허용하지 않습니다. 네트워크 트래픽을 환경 간에 직접 전달해야 하는 경우 이 네트워크 경로를 허용하는 추가 단계를 수행해야 합니다. 예를 들어 한 VPC 네트워크의 서비스를 다른 VPC 네트워크로 노출하도록 Private Service Connect 엔드포인트를 구성할 수 있습니다. 또는 트래픽이 Google Cloud 환경으로부터 온프레미스 환경으로 이동한 다음 다른 Google Cloud 환경으로 이동하도록 온프레미스 네트워크를 구성할 수 있습니다.
허브 및 스포크 네트워크 토폴로지
여러 환경의 리소스에 대한 직접 네트워크 경로가 필요한 Google Cloud의 리소스를 배포하는 경우 허브 및 스포크 네트워크 토폴로지를 사용하는 것이 좋습니다.
허브 및 스포크 토폴로지는 이중 공유 VPC 토폴로지에 포함되는 몇 가지 개념을 사용하지만 허브 네트워크를 추가하도록 토폴로지를 수정합니다. 다음은 허브 및 스포크 토폴로지를 보여주는 다이어그램입니다.
이 다이어그램에서는 허브 및 스포크 네트워크 토폴로지의 주요 개념을 설명합니다.
- 이 모델은 허브 네트워크를 추가하며, 각 개발, 비프로덕션, 프로덕션 네트워크(스포크)는 VPC 네트워크 피어링을 통해 허브 네트워크에 연결됩니다. 또는 할당량 한도가 초과될 것으로 예상되면 HA VPN 게이트웨이를 대신 사용할 수 있습니다.
- 온프레미스 네트워크에 대한 연결은 허브 네트워크를 통해서만 허용됩니다. 모든 스포크 네트워크는 허브 네트워크의 공유 리소스와 통신하고 이 경로를 사용하여 온프레미스 네트워크에 연결할 수 있습니다.
- 허브 네트워크에는 각 리전의 NVA가 포함되며, 내부 네트워크 부하 분산기 인스턴스 뒤에 중복 배포됩니다. 이 NVA는 스포크 네트워크 간의 트래픽 통신을 허용하거나 거부하는 게이트웨이 역할을 합니다.
- 허브 네트워크는 다른 모든 네트워크에 연결해야 하는 도구도 호스팅합니다. 예를 들어 구성 관리를 위해 VM 인스턴스에 도구를 공통 환경에 배포할 수 있습니다.
- 각 네트워크의 기본 버전 및 제한된 버전에 대해 허브 및 스포크 모델이 중복됩니다.
스포크 간 트래픽을 사용 설정하기 위해 청사진은 네트워크 간 게이트웨이로 작동하는 허브 공유 VPC 네트워크에 NVA를 배포합니다. 경로는 커스텀 경로 교환을 통해 허브에서 스포크 VPC 네트워크로 교환됩니다. 이 시나리오에서는 VPC 네트워크 피어링이 전환할 수 없기 때문에 스포크 간의 연결이 NVA를 통해 라우팅되어야 합니다. 따라서 스포크 VPC 네트워크가 서로 직접 데이터를 교환할 수 없습니다. 이제 스포크 간의 트래픽을 선택적으로 허용하도록 가상 어플라이언스를 구성해야 합니다.
NVA를 사용하여 스포크 간의 트래픽을 제어하는 방법에 대한 자세한 내용은 Google Cloud의 중앙 집중식 네트워크 어플라이언스를 참조하세요.
프로젝트 배포 패턴
워크로드용 새 프로젝트를 만들 때는 이 프로젝트의 리소스가 기존 네트워크에 연결되는 방법을 결정해야 합니다. 다음 표에서는 청사진에 사용된 프로젝트를 배포하는 패턴에 대해 설명합니다.
| 패턴 | 설명 | 사용 예시 |
|---|---|---|
| 공유 기본 프로젝트 | 이러한 프로젝트는 기본 공유 VPC 호스트 프로젝트의 서비스 프로젝트로 구성됩니다. 프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.
|
example_base_shared_vpc_project.tf |
| 제한된 공유 프로젝트 | 이러한 프로젝트는 제한된 공유 VPC 호스트 프로젝트에 대한 서비스 프로젝트로 구성됩니다. 프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.
|
example_restricted_shared_vpc_project.tf |
| 유동 프로젝트 | 유동 프로젝트는 토폴로지의 다른 VPC 네트워크에 연결되지 않습니다. 프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.
유동 프로젝트의 VPC 네트워크를 기본 VPC 네트워크 토폴로지와 별도로 유지하고 네트워크 간에 제한된 수의 엔드포인트를 노출하려는 경우가 있을 수 있습니다. 이럴 때 Private Service Connect를 사용하여 서비스를 게시하여 전체 네트워크를 노출하지 않고도 VPC 네트워크에서 개별 엔드포인트에 대한 네트워크 액세스를 공유합니다. |
example_floating_project.tf |
| 피어링 프로젝트 | 피어링 프로젝트는 자체 VPC 네트워크를 만들고 토폴로지의 다른 VPC 네트워크와 피어링합니다. 프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.
피어링 프로젝트를 만드는 경우 충돌하지 않는 IP 주소 범위를 할당하고 피어링 그룹 할당량을 계획해야 합니다. |
example_peering_project.tf |
IP 주소 할당
이 섹션에서는 청사진 아키텍처가 IP 주소 범위를 할당하는 방법을 소개합니다. 기존 하이브리드 환경의 IP 주소 가용성을 기준으로 사용되는 특정 IP 주소 범위를 변경해야 할 수 있습니다.
다음 표에서는 청사진에 할당된 IP 주소 공간의 분석을 제공합니다. 허브 환경은 허브 및 스포크 토폴로지에만 적용됩니다.
| 목적 | VPC 유형 | 리전 | 허브 환경 | 개발 환경 | 비프로덕션 환경 | 프로덕션 환경 |
|---|---|---|---|---|---|---|
| 기본 서브넷 범위 | 기본 | 리전 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
| 리전 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
| 할당되지 않음 | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| 제한됨 | 리전 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
| 리전 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
| 할당되지 않음 | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
| 비공개 서비스 액세스 | 기본 | 글로벌 | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
| 제한됨 | 글로벌 | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
| Private Service Connect 엔드포인트 | 기본 | 글로벌 | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
| 제한됨 | 글로벌 | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
| 프록시 전용 서브넷 | 기본 | 리전 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
| 리전 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
| 할당되지 않음 | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| 제한됨 | 리전 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
| 리전 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
| 할당되지 않음 | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
| 보조 서브넷 범위 | 기본 | 리전 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
| 리전 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
| 할당되지 않음 | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| 제한됨 | 리전 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
| 리전 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
| 할당되지 않음 | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
앞의 표는 IP 주소 범위 할당에 대한 다음의 개념을 보여줍니다.
- IP 주소 할당은 기본 공유 VPC, 제한된 공유 VPC, 리전, 환경의 각 조합에 대한 범위로 세분화됩니다.
- 일부 리소스는 전역이며 각 리전에 대해 하위 그룹이 필요하지 않습니다.
- 기본적으로 리전별 리소스의 경우 청사진이 두 리전에 배포됩니다. 또한 6개의 추가 리전으로 확장할 수 있도록 사용되지 않는 IP 주소 범위가 있습니다.
- 허브 네트워크는 허브 및 스포크 네트워크 토폴로지에서만 사용되고 개발, 비프로덕션, 프로덕션 환경은 두 네트워크 토폴로지 모두에서 사용됩니다.
다음 표에서는 각 유형의 IP 주소 범위 사용 방법을 소개합니다.
| 목적 | 설명 |
|---|---|
| 기본 서브넷 범위 | 가상 머신 인스턴스와 같이, VPC 네트워크에 배포하는 리소스는 이러한 범위의 내부 IP 주소를 사용합니다. |
| 비공개 서비스 액세스 | Cloud SQL과 같은 일부 Google Cloud 서비스에서는 비공개 서비스 액세스를 위해 서브넷 범위를 사전 할당해야 합니다. 청사진은 비공개 서비스 액세스가 필요한 서비스에 IP 주소를 할당하기 위해 각 공유 VPC 네트워크에 대해 전역적으로 /21 범위를 예약합니다. 비공개 서비스 액세스에 의존하는 서비스를 만들 때는 예약된 /21 범위에서 리전 /24 서브넷을 할당합니다. |
| Private Service Connect | 청사진은 각 VPC 네트워크를 Google Cloud API와 통신하기 위해 Private Service Connect 엔드포인트로 프로비저닝합니다. 이 엔드포인트를 사용하면 VPC 네트워크의 리소스가 인터넷 또는 공개적으로 공지된 인터넷 범위에 대한 아웃바운드 트래픽에 의존하지 않고 Google Cloud API에 연결할 수 있습니다. |
| 프록시 기반 부하 분산기 | 일부 유형의 애플리케이션 부하 분산기의 경우 프록시 전용 서브넷을 사전 할당해야 합니다. 청사진은 이 범위가 필요한 애플리케이션 부하 분산기를 배포하지 않지만 미리 범위를 할당하면 특정 부하 분산기 리소스를 사용 설정하기 위해 새 서브넷 범위를 요청해야 할 때 워크로드에서 발생하는 문제를 줄일 수 있습니다. |
| 보조 서브넷 범위 | 컨테이너 기반 워크로드와 같은 일부 사용 사례에는 보조 범위가 필요합니다. 청사진은 보조 범위에 대해 RFC 6598 IP 주소 공간의 범위를 할당합니다. |
중앙 집중식 DNS 설정
Google Cloud와 온프레미스 환경 간의 DNS 변환을 위해서는 권한 있는 DNS 시스템 2개로 하이브리드 접근법을 사용하는 것이 좋습니다. 이 방식에서는 Cloud DNS가 Google Cloud 환경에 대한 권한 있는 DNS 확인을 처리하고, 기존 온프레미스 DNS 서버는 온프레미스 리소스에 대한 권한 있는 DNS 확인을 처리합니다. 온프레미스 환경과 Google Cloud 환경은 전달 요청을 통해 환경 간에 DNS 조회를 수행합니다.
다음은 청사진에 사용된 여러 VPC 네트워크의 DNS 토폴로지를 보여주는 다이어그램입니다.
이 다이어그램은 청사진에 의해 배포된 DNS 설계의 다음 구성요소를 설명합니다.
- 공통 폴더에 있는 DNS 허브 프로젝트는 온프레미스 환경과 Google Cloud 환경 간의 DNS 교환의 중심 지점입니다. DNS 전달에는 네트워크 토폴로지에 이미 구성된 것과 동일한 Dedicated Interconnect 인스턴스와 Cloud Router가 사용됩니다.
- 이중 공유 VPC 토폴로지에서 DNS 허브는 기본 프로덕션 공유 VPC 네트워크를 사용합니다.
- 허브 및 스포크 토폴로지에서 DNS 허브는 기본 허브 공유 VPC 네트워크를 사용합니다.
- 각 공유 VPC 네트워크의 서버는 각 공유 VPC 호스트 프로젝트의 Cloud DNS와 DNS 허브 간에 구성된 DNS 전달을 통해 다른 공유 VPC 네트워크의 DNS 레코드를 확인할 수 있습니다.
- 온프레미스 서버는 온프레미스 서버의 쿼리를 허용하는 DNS 서버 정책을 사용하여 Google Cloud 환경의 DNS 레코드를 확인할 수 있습니다. 청사진은 IP 주소를 할당하도록 DNS 허브에서 인바운드 서버 정책을 구성하고 온프레미스 DNS 서버는 이러한 주소로 요청을 전달합니다. Google Cloud에 대한 모든 DNS 요청은 먼저 DNS 허브에 도달한 후 DNS 피어의 레코드를 확인합니다.
- Google Cloud의 서버는 온프레미스 서버를 쿼리하는 전달 영역을 사용하여 온프레미스 환경의 DNS 레코드를 확인할 수 있습니다. 온프레미스 환경에 대한 모든 DNS 요청은 DNS 허브에서 시작됩니다. DNS 요청 소스는 35.199.192.0/19입니다.
방화벽 정책
Google Cloud에는 여러 방화벽 정책 유형이 있습니다. 계층식 방화벽 정책은 계층 구조에서 모든 리소스 간에 일관되게 방화벽 정책 규칙을 상속하도록 조직 또는 폴더 수준에서 적용됩니다. 또한 각 VPC 네트워크의 네트워크 방화벽 정책을 구성할 수 있습니다. 청사진은 계층식 방화벽 정책을 사용하여 모든 환경에 공통 구성을 적용하고 이러한 방화벽 정책을 결합하여 네트워크 방화벽 정책을 사용하는 각 개별 VPC 네트워크에서 보다 구체적인 구성을 적용합니다.
청사진에는 기존 VPC 방화벽 규칙이 사용되지 않습니다. 방화벽 정책만 사용하고 이전 VPC 방화벽 규칙과 혼합하지 않는 것이 좋습니다.
계층식 방화벽 정책
청사진은 단일 계층식 방화벽 정책을 정의하고 정책을 각 프로덕션, 비프로덕션, 개발, 부트스트랩, 공통 폴더에 연결합니다. 이 계층식 방화벽 정책에는 모든 환경에 광범위하게 적용해야 하는 규칙이 포함되며, 개별 환경의 네트워크 방화벽 정책에 보다 세밀한 규칙 평가를 위임합니다.
다음 표에서는 청사진에서 배포하는 계층식 방화벽 정책 규칙을 설명합니다.
| 규칙 설명 | 트래픽 방향 | 필터(IPv4 범위) | 프로토콜 및 포트 | 작업 |
|---|---|---|---|---|
| RFC 1918에서 인바운드 트래픽 평가를 계층 구조의 하위 수준으로 위임합니다. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| 아웃바운드 트래픽 평가를 RFC 1918에 위임하여 계층 구조의 하위 수준으로 위임합니다. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| TCP 전달을 위한 IAP | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Windows Server 활성화 | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Cloud Load Balancing 상태 점검 | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
네트워크 방화벽 정책
청사진은 각 네트워크의 네트워크 방화벽 정책을 구성합니다. 각 네트워크 방화벽 정책은 Google Cloud 서비스에 대한 액세스를 허용하고 다른 모든 IP 주소에 대한 이그레스를 거부하는 최소 규칙 세트로 시작됩니다.
허브 및 스포크 모델에서 네트워크 방화벽 정책에는 스포크 간의 통신을 허용하는 추가 규칙이 포함되어 있습니다. 네트워크 방화벽 정책은 한 허브 또는 다른 스포크에서 아웃바운드 트래픽을 허용하고 허브 네트워크의 NVA에서 인바운드 트래픽을 허용합니다.
다음 표에서는 청사진에서 각 VPC 네트워크에 배포된 전역 네트워크 방화벽 정책의 규칙을 설명합니다.
| 규칙 설명 | 트래픽 방향 | 필터 | 프로토콜 및 포트 |
|---|---|---|---|
| Google Cloud API로 나가는 아웃바운드 트래픽을 허용합니다. | Egress |
각 개별 네트워크에 대해 구성된 Private Service Connect 엔드포인트입니다. Google API에 대한 비공개 액세스를 참조하세요. | tcp:443 |
| 다른 규칙과 일치하지 않는 아웃바운드 트래픽을 거부합니다. | Egress |
모두 | all |
한 스포크에서 다른 스포크로의 아웃바운드 트래픽을 허용합니다(허브 및 스포크 모델만 해당). |
Egress |
허브 및 스포크 토폴로지에 사용되는 모든 IP 주소의 집계입니다. 스포크 VPC에서 나가는 트래픽은 먼저 허브 네트워크의 NVA로 라우팅됩니다. | all |
허브 네트워크의 NVA에서 스포크로의 인바운드 트래픽을 허용합니다(허브 및 스포크 모델에만 해당). |
Ingress |
허브 네트워크의 NVA에서 발생한 트래픽 | all |
청사진을 처음 배포할 때 VPC 네트워크의 VM 인스턴스는 Google Cloud 서비스와 통신할 수 있지만 동일한 VPC 네트워크의 다른 인프라 리소스와는 통신할 수 없습니다. VM 인스턴스가 통신할 수 있도록 하려면 VM 인스턴스가 명시적으로 통신할 수 있도록 네트워크 방화벽 정책 및 태그에 추가 규칙을 추가해야 합니다. VM 인스턴스에 태그가 추가되고, 이러한 태그를 기준으로 트래픽이 평가됩니다. 태그에는 중앙에서 정의하고 다른 팀에 해당 사용 권한을 위임할 수 있도록 IAM 제어가 포함되어 있습니다.
다음 다이어그램은 워크로드가 VPC 네트워크 내에서 통신할 수 있도록 커스텀 태그 및 네트워크 방화벽 정책 규칙을 추가하는 방법의 예시를 보여줍니다.
다이어그램은 이 예시에서 다음과 같은 개념을 보여줍니다.
- 네트워크 방화벽 정책에는 우선순위가 65530인 모든 소스의 아웃바운드 트래픽을 거부하는 규칙 1이 포함됩니다.
- 네트워크 방화벽 정책에는
service=frontend태그가 있는 인스턴스에서service=backend태그가 있는 인스턴스로 우선순위가 999인 인스턴스로 들어오는 트래픽을 허용하는 규칙 2가 있습니다. - 트래픽이 규칙 2에서 허용되는 태그와 일치하므로 instance-2 VM은 instance-1에서 트래픽을 수신할 수 있습니다. 규칙 2는 우선순위 값을 기준으로 규칙 1이 평가되기 전에 일치합니다.
- instance-3 VM은 트래픽을 수신하지 않습니다. 이 트래픽과 일치하는 유일한 방화벽 정책 규칙은 규칙 1이므로 instance-1의 아웃바운드 트래픽이 거부됩니다.
Google Cloud API에 대한 비공개 액세스
VPC 네트워크 또는 온프레미스 환경의 리소스가 Google Cloud 서비스에 연결되도록 하려면 아웃바운드 인터넷 트래픽 대신 공개 API 엔드포인트로의 비공개 연결을 사용하는 것이 좋습니다. 청사진은 모든 서브넷에서 비공개 Google 액세스를 구성하고 Private Service Connect로 내부 엔드포인트를 만들어 Google Cloud 서비스와 통신합니다. 이러한 제어를 함께 사용하면 인터넷 아웃바운드 트래픽이나 공개적으로 공지된 인터넷 범위에 의존하지 않고도 Google Cloud 서비스에 대한 비공개 경로를 허용할 수 있습니다.
청사진은 API 번들으로 Private Service Connect 엔드포인트를 구성하여 어떤 네트워크에서 액세스할 수 있는지 구분합니다. 기본 네트워크에서는 all-apis 번들을 사용하여 모든 Google 서비스에 연결할 수 있으며, 제한된 네트워크는 vpcsc 번들을 사용하여, VPC 서비스 제어를 지원하는 제한된 서비스 집합에 액세스할 수 있습니다.
온프레미스 환경에 있는 호스트에서 액세스하려면 다음 표에 설명된 대로 각 엔드포인트에 커스텀 FQDN 규칙을 사용하는 것이 좋습니다. 청사진은 다양한 VPC 번들에 액세스하도록 구성된 각 VPC 네트워크의 고유한 Private Service Connect 엔드포인트를 사용합니다. 따라서 올바른 API 엔드포인트를 사용하여 온프레미스 환경에서 VPC 네트워크로 서비스 트래픽을 라우팅하는 방법을 고려해야 하고, VPC 서비스 제어를 사용하는 경우에는 Google Cloud 서비스로의 트래픽이 의도한 경계 내부의 엔드포인트에 도달하는지 확인해야 합니다. DNS, 방화벽, 라우터에 대한 온프레미스 제어를 구성하여 이러한 엔드포인트에 대한 액세스를 허용하고 온프레미스 호스트를 구성하여 적절한 엔드포인트를 사용합니다. 자세한 내용은 엔드포인트를 통해 Google API에 액세스를 참조하세요.
다음 표에서는 각 네트워크에 대해 생성된 Private Service Connect 엔드포인트를 설명합니다.
| VPC | 환경 | API 번들 | Private Service Connect 엔드포인트 IP 주소 | 커스텀 FQDN | ||||
|---|---|---|---|---|---|---|---|---|
| 기본 | 일반 | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
| 개발 | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
| 비프로덕션 | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
| 프로덕션 | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| 제한됨 | 일반 | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
| 개발 | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
| 비프로덕션 | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
| 프로덕션 | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Google Cloud 서비스의 트래픽에 올바른 엔드포인트에 대한 DNS 조회가 있는지 확인하기 위해 청사진은 각 VPC 네트워크의 비공개 DNS 영역을 구성합니다. 다음 표에서는 이러한 비공개 DNS 영역을 설명합니다.
| 비공개 영역 이름 | DNS 이름 | 레코드 유형 | 데이터 |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com.(기본 네트워크) 또는 restricted.googleapis.com.(제한된 네트워크) |
private.googleapis.com(기본 네트워크) 또는 restricted.googleapis.com(제한된 네트워크) |
A |
해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소 | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소 | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소 |
청사진에는 이러한 Private Service Connect 엔드포인트가 일관적으로 사용되도록 강제하는 추가 구성이 있습니다. 각 공유 VPC 네트워크도 다음을 구성을 적용합니다.
- 모든 소스에서 TCP:443으로 Private Service Connect 엔드포인트의 IP 주소로 아웃바운드 트래픽을 허용하는 네트워크 방화벽 정책 규칙
- Google Cloud 서비스에 액세스하는 데 사용되는 기본 도메인이 포함된 아웃바운드 트래픽을 0.0.0.0/0으로 거부하는 네트워크 방화벽 정책 규칙
인터넷 연결
청사진은 VPC 네트워크와 인터넷 간의 인바운드 또는 아웃바운드 트래픽을 허용하지 않습니다. 인터넷 연결이 필요한 워크로드의 경우 필요한 액세스 경로를 설계하기 위한 추가 단계를 수행해야 합니다.
인터넷으로 전송되는 아웃바운드 트래픽이 필요한 워크로드의 경우에는 원치 않는 인바운드 연결 없이 아웃바운드 트래픽을 허용하도록 Cloud NAT를 통해 아웃바운드 트래픽을 관리하거나, 더욱 안전한 제어가 가능한 보안 웹 프록시를 사용하여 신뢰할 수 있는 웹 서비스로 나가는 아웃바운드 트래픽만 허용하도록 관리하는 것이 좋습니다.
인터넷으로부터의 인바운드 트래픽이 필요한 워크로드의 경우에는 Cloud Load Balancing 및 Google Cloud Armor를 사용하여 DDoS 및 WAF 보호의 이점을 누리도록 워크로드를 설계하는 것이 좋습니다.
VM에서 외부 IP 주소를 사용하여 인터넷과 VM 간의 직접 연결을 허용하는 워크로드는 설계하지 않는 것을 권장합니다.
온프레미스 환경과 Google Cloud 간의 하이브리드 연결
온프레미스 환경과 Google Cloud 간의 연결을 설정하려면 보안 및 안정성을 극대화하기 위해 Dedicated Interconnect를 사용하는 것이 좋습니다. Dedicated Interconnect 연결은 온프레미스 네트워크와 Google Cloud 간의 직접 링크입니다.
다음 다이어그램은 온프레미스 환경과 Google Virtual Private Cloud 네트워크 간의 하이브리드 연결을 보여줍니다.
이 다이어그램은 Dedicated Interconnect를 위한 99.99% 의 가용성 패턴을 위한 다음 구성요소를 설명합니다.
- Dedicated Interconnect 4개(한 개 권역(metro)의 두 연결) 및 다른 권역 2개의 연결
- 이러한 연결은 두 쌍으로 나뉘며, 각 쌍은 별도의 온프레미스 데이터 센터에 연결됩니다.
- VLAN 연결은 각 Dedicated Interconnect 인스턴스를 공유 VPC 토폴로지에 연결된 Cloud Router에 연결하는 데 사용됩니다. 이러한 VLAN 연결은
prj-c-interconnect프로젝트에서 호스팅됩니다. - 각 공유 VPC 네트워크에는 리전당 2개의 동적 Cloud Router가 있으며, 동적 라우팅 모드가
global로 설정되어 모든 Cloud Router가 리전과 관계없이 모든 서브넷을 공지할 수 있습니다.
전역 동적 라우팅을 사용하면 Cloud Router가 VPC 네트워크의 모든 서브넷으로 연결되는 경로를 공지합니다. Cloud Router는 로컬 서브넷(Cloud Router가 있는 리전 내의 서브넷)에 비해 원격 서브넷(Cloud Router가 있는 리전의 외부 서브넷)으로 연결되는 경로를 보다 낮은 우선순위로 공지합니다. 필요한 경우 Cloud Router에 BGP 세션을 구성할 때 공지된 프리픽스 및 우선순위를 변경할 수 있습니다.
Google Cloud에서 온프레미스 환경으로의 트래픽은 클라우드 리소스와 가장 가까운 Cloud Router를 사용합니다. 단일 리전 내에서 온프레미스 네트워크로의 여러 경로는 동일한 멀티 종료 구분자(MED) 값을 가지며, Google Cloud는 등가 멀티 경로(ECMP) 라우팅을 사용하여 모든 가능한 경로 간에 아웃바운드 트래픽을 분산합니다.
온프레미스 구성 변경사항
온프레미스 환경과 Google Cloud 간의 연결을 구성하려면 온프레미스 환경에서 추가 변경사항을 구성해야 합니다. 청사진의 Terraform 코드는 Google Cloud 리소스를 자동으로 구성하지만 온프레미스 네트워크 리소스를 수정하지 않습니다.
온프레미스 환경에서 Google Cloud로의 하이브리드 연결을 위한 일부 구성요소는 다음을 포함하여 청사진에 의해 자동으로 사용 설정됩니다.
- DNS 설정에 설명된 대로 Cloud DNS는 모든 공유 VPC 네트워크 간에 단일 허브로의 DNS 전달을 통해 구성됩니다. Cloud DNS 서버 정책은 인바운드 전달자 IP 주소로 구성됩니다.
- Cloud Router는 Private Service Connect 엔드포인트에서 사용되는 IP 주소에 대해 모든 서브넷 및 커스텀 경로를 내보내도록 구성됩니다.
하이브리드 연결을 사용 설정하려면 다음 추가 단계를 수행해야 합니다.
- Dedicated Interconnect 연결을 주문합니다.
- IP 주소 공간 할당에 정의된 내부 IP 주소 공간에 대해 아웃바운드 트래픽을 허용하도록 온프레미스 라우터와 방화벽을 구성합니다.
- Google Cloud로 바인딩된 DNS 조회를 청사진에 의해 이미 구성된 인바운드 전달자 IP 주소로 전달하도록 온프레미스 DNS 서버를 구성합니다.
- Cloud DNS 전달 영역(35.199.192.0/19)의 DNS 쿼리를 수락하도록 온프레미스 DNS 서버, 방화벽, 라우터를 구성합니다.
- Cloud APIs에 대한 비공개 액세스에 정의된 IP 주소로 온프레미스 호스트에서 Google Cloud 서비스로의 쿼리에 응답하도록 온프레미스 DNS 서버를 구성합니다.
- Dedicated Interconnect 연결을 통한 전송 중인 데이터 암호화의 경우 Cloud Interconnect용 MACsec를 구성하거나 IPsec 암호화를 위해 Cloud Interconnect를 통한 HA VPN을 구성합니다.
자세한 내용은 온프레미스 호스트의 비공개 Google 액세스을 참조하세요.
다음 단계
- 감지 제어(이 시리즈의 다음 문서) 읽어보기