GSP016

개요

이 실습에서는 Google Cloud(Compute Engine 인스턴스 포함)에서 기본 네트워킹 작업을 수행하는 방법과 Google Cloud와 온프레미스 설정의 차이점에 대해 알아봅니다. 하나의 네트워크와 3개의 서브네트워크를 구축하면 다음과 같은 환경이 만들어집니다.

실습은 다음과 같은 순서로 일반 클라우드 개발자 환경을 반영하여 진행됩니다.

1. 실습 환경을 설정하고 Google Cloud 환경에서 작업하는 방법을 알아봅니다.
2. 일반 오픈소스 도구를 사용하여 서브넷 및 여러 리전이 포함된 일반 네트워크를 배포하여 전 세계의 네트워크를 탐색합니다.
3. 네트워크 및 인스턴스를 테스트하고 모니터링합니다.

학습할 내용

• Google Cloud 네트워킹의 기본 개념 및 구성
• 기본 네트워크 및 사용자 생성 네트워크의 구성 방법
• 성능 및 지연 시간 특성 측정 방법
• 액세스, 방화벽 및 라우팅의 기본 보안 구성

기본 요건

• Compute Engine에 관한 기본 지식
• 기본 네트워킹 및 TCP/IP 지식
• 기본 Unix/Linux 명령줄 지식

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머에는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지 표시됩니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 직접 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학생 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간---실습을 시작하고 나면 일시중지할 수 없습니다.

참고: 계정에 추가 요금이 발생하지 않도록 하려면 개인용 Google Cloud 계정이나 프로젝트가 이미 있어도 이 실습에서는 사용하지 마세요.

실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법

1. 실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 팝업이 열립니다. 왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 패널이 있습니다.

   • Google 콘솔 열기 버튼
   • 남은 시간
   • 이 실습에 사용해야 하는 임시 사용자 인증 정보
   • 필요한 경우 실습 진행을 위한 기타 정보

2. Google 콘솔 열기를 클릭합니다. 실습에서 리소스가 가동된 후 로그인 페이지가 표시된 다른 탭이 열립니다.

   팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.

   참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.

3. 필요한 경우 실습 세부정보 패널에서 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다. 다음을 클릭합니다.

4. 실습 세부정보 패널에서 비밀번호를 복사하여 시작 대화상자에 붙여넣습니다. 다음을 클릭합니다.

   중요: 왼쪽 패널에 표시된 사용자 인증 정보를 사용해야 합니다. Google Cloud Skills Boost 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

5. 이후에 표시되는 페이지를 클릭하여 넘깁니다.

   • 이용약관에 동의합니다.
   • 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
   • 무료 평가판을 신청하지 않습니다.

잠시 후 Cloud 콘솔이 이 탭에서 열립니다.

참고: 왼쪽 상단에 있는 탐색 메뉴를 클릭하면 Google Cloud 제품 및 서비스 목록이 있는 메뉴를 볼 수 있습니다.

Cloud Shell 활성화

Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Google Cloud 콘솔 상단에서 Cloud Shell 활성화 를 클릭합니다.

연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 PROJECT_ID로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

2. (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.

gcloud auth list

3. 승인을 클릭합니다.

4. 다음과 비슷한 결과가 출력됩니다.

출력:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.

gcloud config list project

출력:

[core] project = <project_ID>

출력 예시:

[core] project = qwiklabs-gcp-44776a13dea667a6 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참조하세요.

리전 및 영역의 이해

일부 Compute Engine 리소스는 리전이나 영역(zone)에 있습니다. 리전은 리소스를 실행할 수 있는 특정 지리적 위치입니다. 각 리전에는 하나 이상의 영역이 있습니다. 예를 들어 us-central1 리전은 us-central1-a, us-central1-b, us-central1-c 및 us-central1-f 영역이 있는 미국 중부의 리전을 나타냅니다.

리전	영역
미국 서부	us-west1-a, us-west1-b
미국 중부	us-central1-a, us-central1-b, us-central1-d, us-central1-f
미국 동부	us-east1-b, us-east1-c, us-east1-d
서유럽	europe-west1-b, europe-west1-c, europe-west1-d
동아시아	asia-east1-a, asia-east1-b, asia-east1-c

영역 내에 상주하는 리소스를 영역별 리소스라고 합니다. 가상 머신 인스턴스와 영구 디스크는 영역에 상주합니다. 영구 디스크를 가상 머신 인스턴스에 연결하려면 두 리소스가 모두 같은 영역에 있어야 합니다. 마찬가지로 인스턴스에 정적 IP 주소를 할당하려는 경우 인스턴스가 정적 IP와 같은 리전에 있어야 합니다.

Compute Engine 페이지, 리전 및 영역 문서에서 리전 및 영역에 관해 자세히 알아보고 전체 목록을 확인하세요.

Google Cloud 네트워크 개념

Google Cloud Platform에서 네트워크는 클라우드 리소스(대부분 Compute Engine 인스턴스)와의 양방향 데이터 연결을 제공합니다. 데이터를 보호하고 리소스에 대한 액세스를 제어하기 위해서는 네트워크 보안이 중요합니다.

Google Cloud Platform은 프로젝트, 네트워크 및 서브네트워크를 지원하며, 관련 없는 리소스를 유연하고 논리적인 방식으로 격리합니다.

프로젝트는 가장 바깥쪽에 있는 컨테이너이며 동일한 신뢰 경계를 공유하는 리소스를 그룹화하는 데 사용됩니다. 프로젝트마다 자체 액세스 정책(IAM) 및 구성원 목록이 있으므로 많은 개발자가 프로젝트를 팀에 매핑합니다. 프로젝트는 리소스 사용량을 반영하는 청구 및 할당량 세부정보 수집기의 역할도 합니다. 프로젝트에는 서브네트워크, 방화벽 규칙 및 경로를 포함하는 네트워크가 포함됩니다(자세한 내용은 아래 아키텍처 다이어그램 참조).

네트워크는 리소스를 서로 간에 직접 연결하며 외부 네트워크에도 연결합니다. 네트워크는 들어오고 나가는 연결에 대한 액세스 정책도 관리하는데, 이 때 방화벽을 사용합니다. 네트워크에는 전역 네트워크(여러 리전에 걸쳐 수평 확장 가능)와 리전 네트워크(단일 리전 내 지연 시간이 짧음)가 있습니다.

서브네트워크를 사용하면 관련 리소스(Compute Engine 인스턴스)를 RFC1918 비공개 주소 공간으로 그룹화할 수 있습니다. 서브네트워크는 리전 네트워크만 가능합니다. 서브네트워크는 자동 모드 또는 커스텀 모드가 가능합니다.

• 자동 모드 네트워크에는 리전별로 하나의 서브넷이 있으며 각각 사전 정의된 IP 범위 및 게이트웨이를 포함합니다. 이러한 서브넷은 자동 모드 네트워크를 만들 때 자동으로 만들어지며 각 서브넷은 전체 네트워크와 동일한 이름을 갖습니다.
• 커스텀 모드 네트워크는 생성 시에 서브넷을 포함하지 않습니다. 커스텀 모드 네트워크에서 인스턴스를 만들려면 먼저 해당 리전에 서브네트워크를 만들고 해당 IP 범위를 지정해야 합니다. 커스텀 모드 네트워크에는 리전마다 서브넷이 하나도 없거나 하나 또는 여러 개가 있을 수 있습니다.

리전 및 영역 설정

특정 Compute Engine 리소스는 여러 리전과 영역에 상주합니다. 리전은 리소스를 실행할 수 있는 특정한 지리적 위치로, 각 리전에는 영역이 하나 이상 있습니다.

Cloud 콘솔에서 다음 gcloud 명령어를 실행하여 실습의 기본 리전과 영역을 설정합니다.

gcloud config set compute/zone "{{{project_0.startup_script.primary_zone | Zone}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.startup_script.primary_region | Region}}}" export REGION=$(gcloud config get compute/region)

작업 1. 기본 네트워크 검토

새 프로젝트가 만들어지면 기본 네트워크 구성을 통해 각 리전에 자동 서브넷 네트워크가 제공됩니다. 한 프로젝트에 최대 4개의 추가 네트워크를 만들 수 있습니다. 추가 네트워크는 자동 서브넷 네트워크, 커스텀 서브넷 네트워크 또는 레거시 네트워크일 수 있습니다.

서브네트워크 내에 만들어진 각 인스턴스에 해당 서브네트워크 범위의 IPv4 주소가 할당됩니다.

• 네트워크를 검토합니다. 탐색 메뉴 > VPC 네트워크를 클릭합니다.

방화벽

방화벽 규칙을 사용하여 서브네트워크를 격리하는 방법에 관한 자세한 내용은 서브네트워크 및 방화벽 규칙을 참조하세요.

각 네트워크에는 인스턴스에 대한 모든 인바운드 트래픽을 차단하는 기본 방화벽이 있습니다. 인스턴스로 들어오는 트래픽을 허용하려면 방화벽에 '허용' 규칙을 만들어야 합니다. 또한 '이그레스' 방화벽 구성을 사용하여 아웃바운드 연결을 차단하도록 구성하지 않으면 기본 방화벽에서 인스턴스의 트래픽을 허용합니다. 따라서 기본적으로 인그레스를 전달할 트래픽에 대한 '허용' 규칙과 이그레스를 제한할 트래픽에 대한 '거부' 규칙을 만들 수 있습니다. 또한 이그레스에 대한 기본 거부 규칙을 만들어 외부 연결을 완전히 금지할 수도 있습니다.

일반적으로 전달하려는 트래픽 종류를 지원하는 최소 허용 방화벽 규칙을 구성하는 것이 좋습니다. 예를 들어 일부 인스턴스에 연결되는 트래픽을 허용하고 다른 인스턴스에 연결되는 트래픽을 제한해야 하는 경우 원하는 인스턴스에 대한 트래픽만 허용하는 규칙을 만듭니다. 보다 제한적인 이 구성은 모든 인스턴스에 대한 트래픽을 허용하는 광범위한 방화벽 규칙보다 예측 가능합니다. '거부' 규칙으로 특정 '허용' 규칙을 재정의하려는 경우 각 규칙에 대한 우선순위 등급을 설정할 수 있으며 우선순위가 제일 낮은 규칙이 제일 먼저 평가됩니다. 크고 복잡한 재정의 규칙 집합을 만들면 의도하지 않은 트래픽을 허용하거나 차단하게 될 수 있습니다.

기본 네트워크에는 다음과 같이 자동으로 만들어진 방화벽 규칙이 있습니다. 수동으로 만들어진 모든 유형의 네트워크에는 자동으로 만들어진 방화벽 규칙이 없습니다. 기본 네트워크를 제외한 모든 네트워크에는 필요한 방화벽 규칙을 만들어야 합니다.

기본 네트워크에 자동으로 만들어진 인그레스 방화벽 규칙은 다음과 같습니다.

default-allow-internal	네트워크상의 인스턴스 간에 모든 프로토콜 및 포트의 네트워크 연결을 허용합니다.
default-allow-ssh	모든 소스에서 TCP 포트 22를 사용하여 네트워크의 모든 인스턴스에 SSH로 연결할 수 있도록 허용합니다.
default-allow-rdp	모든 소스에서 TCP 포트 3389를 사용하여 네트워크의 모든 인스턴스에 RDP로 연결할 수 있도록 허용합니다.
default-allow-icmp	모든 소스에서 네트워크의 모든 인스턴스에 이르는 ICMP 트래픽을 허용합니다.

• 기본 방화벽 규칙을 검토하려면 콘솔에서 탐색 메뉴 > VPC 네트워크 > 방화벽을 클릭합니다.

네트워크 경로

모든 네트워크에는 인터넷(기본 경로)과 네트워크의 IP 범위로 연결되는 자동 생성 경로가 있습니다. 경로 이름은 자동으로 생성되며 프로젝트별로 다릅니다.

• 기본 경로를 검토하려면 탐색 메뉴 > VPC 네트워크 > 경로를 클릭합니다.

작업 2. 커스텀 네트워크 만들기

커스텀 서브넷 범위가 있는 새 네트워크 만들기

서브네트워크 범위를 수동으로 할당할 경우 먼저 커스텀 서브넷 네트워크를 만든 다음 리전 내에 원하는 서브네트워크를 만듭니다. 모든 리전에 즉시 서브넷을 지정하지 않거나 전혀 지정하지 않아도 되지만, 서브네트워크가 정의되지 않은 리전에 인스턴스를 만들 수는 없습니다.

새 서브네트워크를 만드는 경우 이름은 해당 리전의 프로젝트에서 고유해야 하며 네트워크에서도 마찬가지입니다. 각 이름이 다른 리전에 있을 경우에는 프로젝트에 동일한 이름이 두 번 나타날 수 있습니다. 이 네트워크는 서브네트워크이므로 네트워크 수준 IPv4 범위 또는 게이트웨이 IP가 없고 따라서 아무것도 표시되지 않습니다.

콘솔 또는 Cloud Shell을 사용하여 커스텀 네트워크를 만들 수 있습니다. 둘 다 가능하지만 실습에서 어떤 방법을 사용할지 결정해야 합니다. 예를 들어 콘솔 지침을 사용하여 섹션을 진행한 후 gcloud 명령줄을 사용하여 동일한 섹션을 진행할 수는 없습니다.

작업 3. 콘솔을 사용하여 커스텀 네트워크 만들기

참고: 명령줄을 사용하려면 이 섹션을 건너뛰고 Cloud Shell을 사용하여 커스텀 네트워크 만들기를 진행합니다.

1. 커스텀 네트워크를 만들려면 탐색 메뉴 > VPC 네트워크를 클릭합니다.

2. VPC 네트워크 만들기를 클릭하고 이름을 taw-custom-network로 지정합니다.

3. 커스텀 탭에서 다음을 만듭니다.

   • 서브넷 이름: subnet-
   • 리전:
   • IP 주소 범위: 10.0.0.0/16

4. 완료를 클릭합니다.

   

5. 이제 서브넷 추가를 클릭하고 각 리전에 2개의 서브넷을 추가합니다.

   • subnet-, , 10.1.0.0/16
   • subnet-, , 10.2.0.0/16

6. 만들기를 클릭하여 완료합니다.

현재 네트워크에는 인터넷 및 만들 수 있는 모든 인스턴스로의 경로가 있습니다. 그러나 인스턴스에 대한 액세스는 물론 다른 인스턴스에서의 액세스를 허용하는 방화벽 규칙은 없습니다. 액세스를 허용하려면 방화벽 규칙을 만들어야 합니다.

계속해서 방화벽 규칙 추가 섹션을 진행합니다.

작업 4. Cloud Shell을 사용하여 커스텀 네트워크 만들기

참고: 방금 콘솔을 사용하여 네트워크를 만든 경우에는 Cloud Shell을 사용하여 동일한 실습을 수행하지 않습니다. 대신 gcloud 명령줄을 사용하는 실습을 다시 진행합니다.

• 커스텀 네트워크를 만들려면 Cloud Shell에 다음 명령어를 입력합니다.

gcloud compute networks create taw-custom-network --subnet-mode custom

출력:

NAME MODE IPV4_RANGE GATEWAY_IPV4 taw-custom-network custom Instances on this network will not be reachable until firewall rules are created. As an example, you can allow all internal traffic between instances as well as SSH, RDP, and ICMP by running: $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp,udp,icmp --source-ranges $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp:22,tcp:3389,icmp

이제 새 커스텀 네트워크에 대한 서브넷을 만듭니다. 3개의 서브넷을 만듭니다.

1. IP 프리픽스를 사용하여 subnet-을(를) 만듭니다.

gcloud compute networks subnets create subnet-{{{project_0.startup_script.primary_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.primary_region | Region}}} \ --range 10.0.0.0/16

출력:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.primary_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.primary_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.primary_region | Region}}} {{{project_0.startup_script.primary_region | Region}}} taw-custom-network 10.0.0.0/16

2. IP 프리픽스를 사용하여 subnet-을(를) 만듭니다.

gcloud compute networks subnets create subnet-{{{project_0.startup_script.secondary_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.secondary_region | Region}}} \ --range 10.1.0.0/16

출력:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.secondary_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.secondary_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.1.0.0/16

3. IP 프리픽스를 사용하여 subnet-을(를) 만듭니다.

gcloud compute networks subnets create subnet-{{{project_0.startup_script.third_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.startup_script.third_region | Region}}} \ --range 10.2.0.0/16

출력:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.startup_script.third_region | Region}}}/subnetworks/subnet-{{{project_0.startup_script.third_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.2.0.0/16

4. 네트워크를 나열합니다.

gcloud compute networks subnets list \ --network taw-custom-network

이전 섹션에서 자동 서브넷 네트워크를 만든 경우 해당 서브넷도 나열됩니다.

출력:

NAME REGION NETWORK RANGE subnet-{{{project_0.startup_script.third_region | Region}}} {{{project_0.startup_script.third_region | Region}}} taw-custom-network 10.1.0.0/16 subnet-{{{project_0.startup_script.secondary_region | Region}}} {{{project_0.startup_script.secondary_region | Region}}} taw-custom-network 10.2.0.0/16 subnet-{{{project_0.startup_script.primary_region | Region}}} {{{project_0.startup_script.primary_region | Region}}} taw-custom-network 10.0.0.0/16

현재 네트워크에는 인터넷 및 만들 수 있는 모든 인스턴스로의 경로가 있습니다. 그러나 인스턴스에 대한 액세스는 물론 다른 인스턴스에서의 액세스를 허용하는 방화벽 규칙은 없습니다. 액세스를 허용하려면 방화벽 규칙을 만들어야 합니다.

작업 5. 방화벽 규칙 추가

VM 인스턴스에 대한 액세스를 허용하려면 방화벽 규칙을 적용해야 합니다. 인스턴스 태그를 사용하여 VM 인스턴스에 방화벽 규칙을 적용합니다. 방화벽 규칙은 동일한 인스턴스 태그를 사용하는 모든 VM에 적용됩니다.

참고: 네트워크 및 방화벽에서 인스턴스 태그를 사용하여 태그된 VM 인스턴스에 특정 방화벽 규칙을 적용합니다. 예를 들어 대규모 웹사이트에서와 같이 동일한 작업을 수행하는 인스턴스가 여러 개 있는 경우 공유된 단어나 용어를 사용하여 이러한 인스턴스에 태그를 지정한 다음 해당 태그를 사용하여 방화벽 규칙으로 해당 인스턴스에 대한 HTTP 액세스를 허용할 수 있습니다.

태그는 메타데이터 서버에도 반영되므로 인스턴스에서 실행되는 애플리케이션에 사용할 수 있습니다.

• 방화벽을 열고 HTTP 인터넷 요청을 허용하면 더 많은 방화벽 규칙이 추가됩니다. 방화벽 규칙은 Console또는 Cloud Shell을 사용하여 추가할 수 있습니다.

콘솔을 통해 방화벽 규칙 추가하기

1. 콘솔에서 메뉴를 통해 VPC 네트워크로 이동하고 taw-custom-networking 네트워크를 클릭합니다.

2. 방화벽 탭을 클릭한 다음 방화벽 규칙 추가를 클릭합니다.

3. 다음 정보를 입력합니다.

필드	값	설명
이름	nw101-allow-http	새 규칙 이름
대상	지정된 대상 태그	방화벽 규칙이 적용되는 인스턴스입니다.
대상 태그	http	생성한 태그
소스 필터	IPv4 범위	인터넷의 모든 IP 주소에 대한 방화벽을 엽니다.
소스 IPv4 범위	0.0.0.0/0	인터넷의 모든 IP 주소에 대한 방화벽을 엽니다.
프로토콜 및 포트	지정된 프로토콜 및 포트를 선택한 다음 tcp 상자를 선택하고 80을 입력합니다.	HTTP 전용

화면이 다음과 같이 표시됩니다.

4. 만들기를 클릭하고 명령어가 성공할 때까지 기다립니다. 다음으로 필요한 추가 방화벽 규칙을 만듭니다.

Cloud Shell을 사용하여 방화벽 규칙 추가하기

참고: 방금 콘솔을 사용하여 네트워크를 만든 경우에는 Cloud Shell을 사용하여 동일한 실습을 수행하지 않습니다. 대신 gcloud 명령줄을 사용하는 실습을 다시 진행합니다.

• Cloud Shell에서 방화벽 규칙을 만들려면 다음을 실행합니다.

gcloud compute firewall-rules create nw101-allow-http \ --allow tcp:80 --network taw-custom-network --source-ranges 0.0.0.0/0 \ --target-tags http

출력:

추가 방화벽 규칙 만들기

이러한 추가 방화벽 규칙은 ICMP, 내부 통신, SSH, RDP를 허용합니다. 콘솔(또는 Cloud Shell)을 사용하여 해당 규칙을 만들 수 있습니다. 각 방화벽 규칙 유형에 한 가지 방법만 사용해야 하며 둘 다 사용할 수는 없습니다.

• ICMP

필드	값	설명
이름	nw101-allow-icmp	새 규칙 이름
대상	지정된 대상 태그	대상 드롭다운에서 선택
대상 태그	규칙	태그
소스 필터	IPv4 범위	이 목록의 모든 IP 주소에 대한 방화벽을 엽니다.
소스 IPv4 범위	0.0.0.0/0	인터넷의 모든 IP 주소에 대한 방화벽을 엽니다.
프로토콜 및 포트	지정된 프로토콜 및 포트, 기타 프로토콜을 선택한 다음 icmp를 입력합니다.	방화벽이 적용될 프로토콜 및 포트

(Cloud Shell 명령어)

gcloud compute firewall-rules create "nw101-allow-icmp" --allow icmp --network "taw-custom-network" --target-tags rules

• 내부 통신

필드	값	설명
이름	nw101-allow-internal	새 규칙 이름
대상	네트워크의 모든 인스턴스	대상 드롭다운에서 선택
소스 필터	IPv4 범위	특정 트래픽 소스에 규칙을 적용하는 데 사용되는 필터
소스 IPv4 범위	10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16	인터넷의 모든 IP 주소에 대한 방화벽을 엽니다.
프로토콜 및 포트	지정된 프로토콜 및 포트를 선택한 다음 tcp를 선택하여 0-65535를 입력하고, udp를 선택하여 0-65535를 입력하고,기타 프로토콜을 선택하여 icmp를 입력합니다.	Tcp:0-65535, udp:0-65535, icmp를 허용합니다.

(Cloud Shell 명령어)

gcloud compute firewall-rules create "nw101-allow-internal" --allow tcp:0-65535,udp:0-65535,icmp --network "taw-custom-network" --source-ranges "10.0.0.0/16","10.2.0.0/16","10.1.0.0/16"

• SSH

필드	값	설명
이름	nw101-allow-ssh	새 규칙 이름
대상	지정된 대상 태그	ssh
대상 태그	ssh	방화벽 규칙을 적용할 인스턴스
소스 필터	IPv4 범위	특정 트래픽 소스에 규칙을 적용하는 데 사용되는 필터
소스 IPv4 범위	0.0.0.0/0	인터넷의 모든 IP 주소에 대한 방화벽을 엽니다.
프로토콜 및 포트	지정된 프로토콜 및 포트를 선택하고 tcp 상자를 선택한 다음 22를 입력합니다.	tcp:22 허용

(Cloud Shell 명령어)

gcloud compute firewall-rules create "nw101-allow-ssh" --allow tcp:22 --network "taw-custom-network" --target-tags "ssh"

• RDP

필드	값	설명
이름	nw101-allow-rdp	새 규칙 이름
대상	네트워크의 모든 인스턴스	대상 드롭다운에서 선택
소스 필터	IPv4 범위	필터 IP 주소
소스 IPv4 범위	0.0.0.0/0	인터넷의 모든 IP 주소에 대한 방화벽을 엽니다.
프로토콜 및 포트	지정된 프로토콜 및 포트를 선택하고 tcp를 선택한 다음 3389를 입력합니다.	tcp:3389 허용

(Cloud Shell 명령어)

gcloud compute firewall-rules create "nw101-allow-rdp" --allow tcp:3389 --network "taw-custom-network"

• 콘솔을 사용하여 네트워크의 방화벽 규칙을 검토합니다. 예를 들면 다음과 같습니다.

참고: 네트워크 콘솔에 표시되는 경로는 어떤가요?

Google Cloud 네트워킹에서는 경로를 사용해 패킷을 서브네트워크 간에 전달하고 인터넷으로도 전달합니다. 네트워크에서 서브네트워크가 미리 만들어져 있거나 만들어질 때마다 서브네트워크 간 경로에 패킷을 허용하도록 각 리전에 경로가 자동으로 만들어집니다. 이러한 경로는 수정할 수 없습니다.

추가 경로를 만들어 인스턴스, VPN 게이트웨이 또는 기본 인터넷 게이트웨이에 트래픽을 보낼 수 있습니다. 이러한 경로는 원하는 네트워크 아키텍처에 맞게 수정할 수 있습니다. 트래픽이 원하는 목적지에 도달하도록 경로와 방화벽이 함께 작동합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.

커스텀 네트워크, 서브네트워크 및 방화벽 규칙을 만듭니다.

작업 6. 실습 VM에 연결 및 지연 시간 확인

• 왼쪽 메뉴에서 VPC 네트워크를 클릭하면 전체 네트워크가 표시됩니다. taw-custom-network에는 세 개의 서브네트워크가 있고 방화벽 규칙이 적용되어 있습니다.

다음과 같이 표시됩니다.

다음 단계에서 각 서브넷에 VM을 만들고 연결할 수 있는지 확인해 보겠습니다.

각 영역에 VM 만들기

이 섹션에서는 Cloud Shell에서 작업합니다.

1. 다음 명령어를 실행하여 subnet- 서브넷에 us-test-01이라는 인스턴스를 만듭니다.

gcloud compute instances create us-test-01 \ --subnet subnet-{{{project_0.startup_script.primary_region | Region}}} \ --zone {{{project_0.startup_script.primary_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

실습 후반부에 사용할 수 있도록 외부 IP를 기록해 둡니다.

출력:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/zones/{{{project_0.startup_script.primary_zone | ZONE}}}/instances/us-test-01]. NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS us-test-01 {{{project_0.startup_script.primary_zone | ZONE}}} e2-standard-2 10.0.0.2 104.198.230.22 RUNNING

2. 이제 상호 연관된 서브넷에 us-test-02 및 us-test-03 VM을 만듭니다.

gcloud compute instances create us-test-02 \ --subnet subnet-{{{project_0.startup_script.secondary_region | REGION}}} \ --zone {{{project_0.startup_script.secondary_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules gcloud compute instances create us-test-03 \ --subnet subnet-{{{project_0.startup_script.third_region | REGION}}} \ --zone {{{project_0.startup_script.third_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.

Traceroute 및 성능 테스트를 위해 지정된 영역에 세 개의 인스턴스를 만듭니다.

VM을 연결할 수 있는지 확인하기

이제 VM 연결 테스트를 위해 몇 가지 연습을 수행합니다.

1. 콘솔로 다시 전환하고 Compute Engine으로 이동합니다.

2. us-test-01 인스턴스에 해당하는 SSH 버튼을 클릭합니다. 그러면 새 창에서 인스턴스에 대한 SSH 연결이 열립니다.

3. us-test-01의 SSH 창에서 다음 명령어를 입력하여 us-test-02에 대해 ICMP 에코를 사용하고 VM 인라인에 외부 IP 주소를 추가합니다.

ping -c 3 <us-test-02-external-ip-address> 참고: 가상 머신의 외부 IP는 Compute Engine 브라우저 탭의 외부 IP 필드에서 찾을 수 있습니다.

사용자의 IP 주소는 그림과 다릅니다.

4. 다음 명령어를 실행하여 us-test-03에 대해 ICMP 에코를 사용하고 VM 인라인에 외부 IP 주소를 추가합니다.

ping -c 3 <us-test-03-external-ip-address>

출력 예시:

PING 35.187.149.67 (35.187.149.67) 56(84) bytes of data. 64 bytes from 35.187.149.67: icmp_seq=1 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=2 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=3 ttl=76 time=152 ms

5. 이제 us-test-02 및 us-test-03 인스턴스에서도 SSH가 작동하는지 확인합니다. us-test-01에 대해 ICMP 에코를 사용해 봅니다.

핑을 사용하여 지연 시간 측정하기

핑을 사용하여 인스턴스와 모든 리전 간 지연 시간을 측정합니다.

• 미국 중부 리전에서 서유럽 리전까지의 지연 시간을 알아보려면 us-test-01에서 SSH 창을 연 후 다음 명령어를 실행합니다.

ping -c 3 us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}

명령어 결과:

PING us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2) 56(84) bytes of data. 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=1 ttl=64 time=105 ms 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=2 ttl=64 time=104 ms 64 bytes from us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=3 ttl=64 time=104 ms

반환된 지연 시간은 '왕복 시간'(RTT)으로 패킷이 us-test-01에서 us-test-02까지 도달하는 데 걸리는 시간입니다.

연결을 테스트하기 위해 핑에서 ICMP 에코 요청 및 에코 응답 메시지를 사용합니다.

참고: 고려사항

리전 간 지연 시간이 얼마나 되나요? 이상적인 조건에서는 어떨 것 같나요? 'us-test-02'에서 'us-test-03'으로의 연결이 특별한 이유는 무엇인가요? 참고: 내부 DNS: DNS는 VM 인스턴스에 어떻게 제공되나요?

각 인스턴스에는 해당 인스턴스의 DNS 리졸버로 작동하는 메타데이터 서버가 있습니다. DNS 조회는 인스턴스 이름별로 수행됩니다. 메타데이터 서버 자체에서 로컬 네트워크의 모든 DNS 정보를 저장하고 로컬 네트워크 외부의 주소에 대해서는 Google의 공개 DNS 서버를 쿼리합니다.

인스턴스에 대한 내부의 정규화된 도메인 이름(FQDN)은 hostName.[ZONE].c.[PROJECT_ID].internal과 같이 표시됩니다.

이 FQDN을 사용하여 한 인스턴스에서 다른 인스턴스로 항상 연결할 수 있습니다. 예를 들어 hostName만 사용하여 인스턴스에 연결하려면 Compute Engine의 일부로 제공되는 내부 DNS 리졸버의 정보가 필요합니다.

작업 7. Traceroute 및 성능 테스트

연습(선택사항)

Traceroute는 두 호스트 간 경로를 추적하는 도구입니다. Traceroute는 다양한 유형의 네트워크 문제 파악에 있어 유용한 첫 번째 단계가 될 수 있습니다. 지원팀이나 네트워크 엔지니어가 네트워크 문제를 진단할 때 Traceroute를 요청하는 경우가 많습니다.

참고: 기능

Traceroute에 호스트 간의 모든 레이어 3(라우팅 레이어) 홉이 표시됩니다. 이는 TTL(수명) 값을 1부터 증가시켜 패킷을 원격 대상에 전송하는 방식으로 이루어집니다. TTL 필드는 라우터마다 하나씩 줄어드는 IP 패킷의 필드입니다. TTL이 0이 되면 패킷은 삭제되고 발송자에게 'TTL 초과' ICMP 메시지가 반환됩니다. 이 방법은 라우팅 루프를 방지하는 데 사용되며 TTL 필드가 결국 0까지 감소하기 때문에 패킷이 무한하게 루프로 돌지 않습니다. 기본적으로 OS는 TTL 값을 높은 값(64, 128, 255 등)으로 설정하므로 이 현상은 비정상적인 상황에서만 발생합니다.

Traceroute는 TTL 값이 1인 패킷을 먼저 보낸 다음 2, 3 등의 순서로 보내므로 이러한 패킷은 경로의 첫 번째, 두 번째 등의 라우터에서 만료됩니다. 그런 다음 반환되는 ICMP TTL 초과 메시지의 소스 IP/호스트를 가져오면 중간 홉의 이름/IP가 표시됩니다. TTL이 충분히 높아지면 패킷이 대상에 도달하고 대상에서 응답합니다.

전송되는 패킷 유형은 구현 방식에 따라 다릅니다. Linux에서 UDP 패킷은 사용되지 않는 높은 포트로 전송됩니다. 따라서 최종 대상에서는 'ICMP 포트 연결할 수 없음'으로 응답합니다. Windows 및 MTR 도구는 ICMP 에코 요청(예: 핑)을 기본으로 사용하므로 최종 대상에서 ICMP 에코 응답으로 응답합니다.

이제 가상 머신 중 하나에 Traceroute를 설정해 보겠습니다.

1. 이 단계에서는 us-test-01 VM 및 us-test-02 VM을 사용하는 단계로 돌아가서 두 VM 모두 SSH를 통해 연결합니다.

2. us-test-01의 SSH 창에서 다음 성능 도구를 설치합니다.

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege traceroute www.icann.org

3. 이제 몇 개의 다른 대상과 소스에서도 시도해 봅니다.

   • 동일한 리전 또는 기타 리전의 VM(eu1-vm, asia1-vm, w2-vm)
   • www.wikipedia.org
   • www.adcash.com
   • bad.horse(최대 TTL이 증가하면 가장 잘 작동하므로 traceroute -m 255 bad.horse로 설정)
   • 기타 사항

4. Traceroute를 중지하려면 SSH 창에서 Ctrl-c를 눌러 명령줄로 돌아갑니다.

참고: 고려사항

다른 Traceroute는 어떤가요?

작업 8. iPerf를 사용하여 성능 테스트

두 호스트 간

연습(선택사항)

iperf를 사용하여 두 호스트 간 성능을 테스트할 때 연결을 수락하려면 한 쪽을 iPerf 서버로 설정해야 합니다.

참고: 다음 명령어는 리전 간에 기가바이트 규모의 트래픽을 전송하며 인터넷 이그레스 요금이 부과됩니다. 사용 시 이 점에 유의하세요. 허용 목록 프로젝트 또는 무료 체험판이 아닌 경우 이 섹션을 건너뛰거나 훑어보기만 해도 됩니다. (비용은 $1(USD) 미만이어야 합니다.)

아주 간단하게 테스트해 보겠습니다.

1. SSH를 통해 us-test-02에 연결하고 성능 도구를 설치합니다.

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

2. SSH를 통해 us-test-01에 연결하고 다음을 실행합니다.

iperf -s #run in server mode

3. us-test-02 SSH에서 이 iperf를 실행합니다.

iperf -c us-test-01.{{{project_0.startup_script.primary_zone | ZONE}}} #run in client mode

일부 결과는 다음과 같습니다.

Client connecting to eu-vm, TCP port 5001 TCP window size: 45.0 KByte (default) [ 3] local 10.20.0.2 port 35923 connected with 10.30.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 298 MBytes 249 Mbits/sec

4. 완료되면 us-test-01에서 Ctrl + C를 사용하여 서버 측을 종료합니다.

리전 내 VM 간

연습(선택사항)

이제 다른 영역에 us-test-01이 아닌 다른 인스턴스(us-test-04)를 배포하겠습니다. 리전 내에 해당 인스턴스가 표시되며 대역폭은 이그레스 상한 코어당 2Gbit/초로 제한됩니다.

1. Cloud Shell에서 us-test-04를 만듭니다.

gcloud compute instances create us-test-04 \ --subnet subnet-{{{project_0.startup_script.primary_region | REGION}}} \ --zone {{{project_0.startup_script.primary_zone_1 | ZONE}}} \ --tags ssh,http

2. SSH를 통해 us-test-04에 연결하고 성능 도구를 설치합니다.

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

리전 간에는 대부분 TCP 창 크기 및 단일 스트림 성능 제한으로 인해 훨씬 낮은 제한이 적용됩니다. UDP 등 다른 매개변수를 사용하여 호스트 간 대역폭을 늘릴 수 있습니다.

3. us-test-02 SSH에서 다음을 실행합니다.

iperf -s -u #iperf server side

4. us-test-01 SSH에서 다음을 실행합니다.

iperf -c us-test-02.{{{project_0.startup_script.secondary_zone | ZONE}}} -u -b 2G #iperf client side - send 2 Gbits/s

이렇게 하면 EU와 US 간에 속도가 더 빨라집니다. 다수의 TCP iperfs를 병렬로 실행하면 속도가 훨씬 빨라질 수 있습니다. 한 번 테스트해 보겠습니다.

5. us-test-01에 대한 SSH 창에서 다음을 실행합니다.

iperf -s

6. us-test-02에 대한 SSH 창에서 다음을 실행합니다.

iperf -c us-test-01.{{{project_0.startup_script.primary_zone | ZONE}}} -P 20

결합된 대역폭은 최대로 달성할 수 있는 대역폭에 매우 가깝습니다.

7. 몇 가지 조합을 더 테스트합니다. 노트북에서 Linux를 사용하는 경우 노트북에 대해서도 테스트할 수 있습니다. (여러 OS에 사용할 수 있는 iperf3도 테스트해 볼 수 있지만 실습에는 포함되어 있지 않습니다.)

여기서 볼 수 있듯이 최대 대역폭에 도달하기 위해서는 단일 TCP 스트림(예: 파일 복사)을 실행하는 것만으로는 부족하고 여러 TCP 세션을 병렬로 실행해야 합니다. 원인은 Window Size와 같은 TCP 매개변수와 Slow Start와 같은 함수입니다.

이 주제와 다른 모든 TCP/IP 주제에 대한 자세한 내용은 TCP/IP 설명을 참조하세요.

bbcp와 같은 도구를 사용하면 전송을 병렬화하고 구성 가능한 창 크기를 사용하여 최대한 빨리 파일을 복사할 수 있습니다.

작업 9. 학습한 내용 테스트

실습 종료하기

실습을 완료하면 실습 종료를 클릭합니다. 사용한 계정과 리소스가 실습 플랫폼에서 삭제됩니다.

실습 경험을 평가할 수 있습니다. 해당하는 별표 수를 선택하고 의견을 입력한 후 제출을 클릭합니다.

별점의 의미는 다음과 같습니다.

• 별표 1개 = 매우 불만족
• 별표 2개 = 불만족
• 별표 3개 = 중간
• 별표 4개 = 만족
• 별표 5개 = 매우 만족

의견을 제공하고 싶지 않다면 대화상자를 닫으면 됩니다.

의견이나 제안 또는 수정할 사항이 있다면 지원 탭을 사용하세요.

다음 실습 참여하기

다중 VPC 네트워크로 Cloud의 네트워킹에 대해 계속 알아보거나 다음 추천 항목을 확인하세요.

• Cloud KMS 시작하기
• Kubernetes로 클라우드 조정하기

준비가 되면 Google Cloud 네트워킹의 기초 퀘스트에도 참여해 보세요.

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2023년 9월 11일

실습 최종 테스트: 2023년 9월 11일

Copyright 2024 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.