내부 HTTP(S) 부하 분산기의 HTTP에서 HTTPS로 리디렉션 설정

이 예시에서는 포트 80에 대한 모든 요청이 각 HTTPS 서비스로 리디렉션되는 방식을 보여줍니다.

외부 부하 분산을 위해 HTTP에서 HTTPS로의 리디렉션을 설정하는 방법을 알아보려면 외부 HTTP(S) 부하 분산기의 HTTP에서 HTTPS로 리디렉션 설정을 참조하세요.

공유 IP 주소를 통해 HTTP에서 HTTPS로 리디렉션을 사용하려면 HTTPS 트래픽용 부하 분산기와 HTTP 트래픽용 부하 분산기를 하나씩 만들어야 합니다. 각 부하 분산기에는 자체 전달 규칙과 URL 맵이 있지만 동일한 IP 주소를 공유합니다. HTTP 부하 분산기의 경우 프런트엔드가 트래픽을 HTTPS 부하 분산기의 백엔드로 리디렉션하므로 백엔드를 구성할 필요가 없습니다.

이 예시에서는 포트 80에서 포트 443으로 모든 요청을 리디렉션하는 방법을 보여줍니다.

대략적으로 HTTP 트래픽을 HTTPS로 리디렉션하려면 다음을 수행해야 합니다.

  1. 예약된 공유 내부 IP 주소를 통해 일반 내부 HTTPS 부하 분산기를 만듭니다.
  2. 내부 HTTPS 부하 분산기를 테스트하여 작동하는지 확인합니다.
  3. 내부 HTTPS 부하 분산기로 트래픽을 리디렉션합니다.
    이렇게 하려면 프런트엔드는 있지만 백엔드가 없는 일부 내부 HTTP 부하 분산기를 추가해야 합니다. 프런트엔드는 요청을 수신한 다음 내부 HTTPS 부하 분산기로 리디렉션합니다. 이 작업은 다음을 사용하여 수행합니다.
    • HTTPS 부하 분산기에서 사용하는 주소와 동일한 예약된 내부 IP 주소가 있는 전달 규칙(1단계 참조)
    • 대상 HTTP 프록시
    • HTTPS 부하 분산기로 트래픽을 리디렉션하는 URL 맵

다음 다이어그램과 같이 내부 HTTPS 부하 분산기는 예상 부하 분산기 구성요소가 있는 일반 부하 분산기입니다.

HTTP 부하 분산기에는 HTTPS 부하 분산기와 동일한 IP 주소, URL 맵의 리디렉션 안내가 있으나 벡엔드는 없습니다.

내부 HTTP에서 HTTPS로 리디렉션 구성(확대하려면 클릭)
내부 HTTP에서 HTTPS로 리디렉션 구성

내부 HTTPS 부하 분산기 만들기

이 프로세스는 내부 HTTP(S) 부하 분산기 설정과 비슷합니다.

내부 HTTP(S) 부하 분산 설정은 다음 두 부분으로 구성됩니다.

  • 필요한 계정에 올바른 권한이 있는지 확인하고 Virtual Private Cloud(VPC) 네트워크를 준비하는 등의 필수 작업을 수행합니다.
  • 부하 분산기 리소스 설정

이 가이드를 진행하기 전에 다음 사항을 숙지하세요.

권한

이 가이드를 진행하려면 프로젝트에서 인스턴스를 만들고 네트워크를 수정할 수 있어야 합니다. 이렇게 하려면 프로젝트 소유자 또는 편집자이거나 다음 Compute Engine IAM 역할을 모두 보유해야 합니다.

작업 필요한 역할
네트워크, 서브넷, 부하 분산기 구성요소 만들기 네트워크 관리자
방화벽 규칙 추가 및 삭제 보안 관리자
인스턴스 만들기 인스턴스 관리자

자세한 내용은 다음 가이드를 참조하세요.

네트워크 및 서브넷 구성하기

부하 분산기의 백엔드를 위한 서브넷 한 개와 부하 분산기의 프록시를 위한 서브넷 한 개, 총 두 개 서브넷이 있는 VPC 네트워크가 필요합니다. 내부 HTTP(S) 부하 분산기는 리전 기준입니다. 트래픽 소스가 부하 분산기와 동일한 리전의 서브넷에 있는 경우 VPC 네트워크 내의 트래픽이 부하 분산기로 라우팅됩니다.

이 예시에서는 다음 VPC 네트워크, 리전 및 서브넷을 사용합니다.

  • 네트워크. 네트워크는 커스텀 모드 VPC 네트워크이며 이름은 lb-network입니다.

  • 백엔드 서브넷. us-west1 리전에 있는 backend-subnet이라는 이름의 서브넷은 기본 IP 범위로 10.1.2.0/24를 사용합니다.

  • 프록시 서브넷. us-west1 리전에 있는 proxy-only-subnet이라는 이름의 서브넷은 기본 IP 범위로 10.129.0.0/23을 사용합니다.

백엔드 네트워크 및 서브넷 구성

Console

  1. Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.
    VPC 네트워크 페이지로 이동
  2. VPC 네트워크 만들기를 클릭합니다.
  3. 이름lb-network를 입력합니다.
  4. 서브넷 섹션에서 다음을 수행합니다.
    • 서브넷 생성 모드커스텀으로 설정합니다.
    • 새 서브넷 섹션에 다음 정보를 입력합니다.
      • 이름: backend-subnet
      • 리전: us-west1
      • IP 주소 범위: 10.1.2.0/24
    • 완료를 클릭합니다.
  5. 만들기를 클릭합니다.

gcloud

  1. gcloud compute networks create 명령어를 사용하여 커스텀 VPC 네트워크를 만듭니다.

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. gcloud compute networks subnets create 명령어를 사용하여 us-west1 리전의 lb-network 네트워크에 서브넷을 만듭니다.

    gcloud compute networks subnets create backend-subnet \
        --network=lb-network \
        --range=10.1.2.0/24 \
        --region=us-west1
    

API

networks.insert 메서드에 대해 POST 요청을 수행합니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

subnetworks.insert 메서드에 대해 POST 요청을 수행합니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "backend-subnet",
  "network": "projects/project-id/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "region": "projects/project-id/regions/us-west1",
}

프록시 전용 서브넷 구성

프록시 전용 서브넷은 us-west1 리전의 모든 내부 HTTP(S) 부하 분산기에 사용됩니다.

Console

Google Cloud Console을 사용하는 경우에는 기다렸다가 나중에 부하 분산 페이지에서 프록시 전용 서브넷을 만들 수 있습니다.

gcloud

gcloud compute networks subnets create 명령어로 프록시 전용 서브넷을 만듭니다.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

subnetworks.insert 메서드로 프록시 전용 서브넷을 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

방화벽 규칙 구성

이 예시에서는 다음과 같은 방화벽 규칙을 사용합니다.

  • fw-allow-ssh. 부하 분산되는 인스턴스에 적용되는 인그레스 규칙으로 TCP 포트 22에 임의의 주소로부터 수신되는 SSH 연결을 허용합니다. 이 규칙에 더 제한적인 소스 IP 범위를 선택할 수 있습니다. 예를 들어 SSH 세션을 시작할 시스템의 IP 범위만 지정할 수도 있습니다. 이 예시에서는 대상 태그 allow-ssh를 사용합니다.

  • fw-allow-health-check. 부하 분산되는 인스턴스에 적용되는 인그레스 규칙으로, 130.211.0.0/2235.191.0.0/16에서 Google Cloud 상태 확인 시스템의 모든 TCP 트래픽을 허용합니다. 이 예시에서는 대상 태그 load-balanced-backend를 사용합니다.

  • fw-allow-proxies: 부하 분산되는 인스턴스에 적용되는 인그레스 규칙으로 내부 HTTP(S) 부하 분산기의 관리형 프록시로부터 포트 80, 443, 8080로의 TCP 트래픽을 허용합니다. 이 예시에서는 대상 태그 load-balanced-backend를 사용합니다.

이러한 방화벽 규칙이 없으면 기본 거부 인그레스 규칙은 백엔드 인스턴스로 들어오는 트래픽을 차단합니다.

대상 태그는 백엔드 인스턴스를 정의합니다. 대상 태그가 없으면 방화벽 규칙은 VPC 네트워크의 모든 백엔드 인스턴스에 적용됩니다. 백엔드 VM을 만들 때는 관리형 인스턴스 그룹 만들기에 나온 대로 지정된 대상 태그를 포함해야 합니다.

Console

  1. Google Cloud Console에서 방화벽 규칙 페이지로 이동합니다.
    방화벽 규칙 페이지로 이동
  2. 방화벽 규칙 만들기를 클릭하여 수신 SSH 연결을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-ssh
    • 네트워크: lb-network
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 타겟: 지정된 타겟 태그
    • 대상 태그: allow-ssh
    • 소스 필터: IP 범위
    • 소스 IP 범위: 0.0.0.0/0
    • 프로토콜 및 포트:
      • 지정된 프로토콜 및 포트를 선택합니다.
      • tcp 체크박스를 선택한 다음 포트 번호로 22를 입력합니다.
  3. 만들기를 클릭합니다.
  4. 방화벽 규칙 만들기를 다시 한 번 클릭하여 Google Cloud 상태 확인을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-health-check
    • 네트워크: lb-network
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 타겟: 지정된 타겟 태그
    • 대상 태그: load-balanced-backend
    • 소스 필터: IP 범위
    • 소스 IP 범위: 130.211.0.0/2235.191.0.0/16
    • 프로토콜 및 포트:
      • 지정된 프로토콜 및 포트를 선택합니다.
      • tcp 체크박스를 선택한 다음 포트 번호로 80를 입력합니다.
        권장사항에 따라서 상태 확인에 사용되는 것과 일치하는 프로토콜 및 포트로 이러한 규칙을 제한합니다. 프로토콜 및 포트에 tcp:80을 사용하면 Google Cloud가 포트 80에서 HTTP를 사용하여 VM에 연결할 수 있지만 포트 443에서 HTTPS를 사용하여 연결할 수는 없습니다.
  5. 만들기를 클릭합니다.
  6. 방화벽 규칙 만들기를 세 번째로 클릭하여 부하 분산기의 프록시 서버를 백엔드에 연결하도록 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-proxies
    • 네트워크: lb-network
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 타겟: 지정된 타겟 태그
    • 대상 태그: load-balanced-backend
    • 소스 필터: IP 범위
    • 소스 IP 범위: 10.129.0.0/23
    • 프로토콜 및 포트:
      • 지정된 프로토콜 및 포트를 선택합니다.
      • tcp 체크박스를 선택한 다음 포트 번호로 80, 443, 8080을 입력합니다.
  7. 만들기를 클릭합니다.

gcloud

  1. allow-ssh 네트워크 태그를 사용해 VM으로 가는 SSH 연결을 허용하는 fw-allow-ssh 방화벽 규칙을 만듭니다. source-ranges를 생략하면 Google Cloud가 모든 소스를 의미하는 것으로 규칙을 해석합니다.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. fw-allow-health-check 규칙을 만들어 Google Cloud 상태 확인을 허용합니다. 이 예시에서는 상태 확인 프로버의 모든 TCP 트래픽을 허용합니다. 그러나 필요에 따라 더 좁은 포트 집합을 구성할 수 있습니다.

    gcloud compute firewall-rules create fw-allow-health-check \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. 내부 HTTP(S) 부하 분산기의 프록시를 백엔드에 연결하도록 허용하는 fw-allow-proxies 규칙을 만듭니다.

    gcloud compute firewall-rules create fw-allow-proxies \
      --network=lb-network \
      --action=allow \
      --direction=ingress \
      --source-ranges=10.129.0.0/23 \
      --target-tags=load-balanced-backend \
      --rules=tcp:80,tcp:443,tcp:8080
    

API

firewalls.insert 메서드에 POST 요청을 수행하여 fw-allow-ssh 방화벽 규칙을 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

firewalls.insert 메서드에 POST 요청을 수행하여 fw-allow-health-check 방화벽 규칙을 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

firewalls.insert 메서드에 대해 프록시 서브넷 내에서 TCP 트래픽을 허용하도록 fw-allow-proxies 방화벽 규칙을 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/{project}/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8080"
      ]
    }
  ],
  "direction": "INGRESS"
}

내부 HTTPS 부하 분산기 리소스 만들기

이 예시에서는 관리형 인스턴스 그룹의 Compute Engine에서 가상 머신 백엔드를 사용합니다. 대신 다른 지원되는 백엔드 유형을 사용할 수 있습니다.

HTTP 서버로 인스턴스 템플릿 만들기

gcloud

gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

영역에 관리형 인스턴스 그룹 만들기

gcloud

gcloud compute instance-groups managed create l7-ilb-backend \
    --zone=us-west1-a \
    --size=2 \
    --template=l7-ilb-backend-template

HTTP 상태 확인 만들기

gcloud

gcloud compute health-checks create http l7-ilb-basic-check \
     --region=us-west1 \
     --use-serving-port

백엔드 서비스 만들기

gcloud

gcloud compute backend-services create l7-ilb-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region=us-west1 \
    --region=us-west1

백엔드 서비스에 백엔드 추가

gcloud

gcloud compute backend-services add-backend l7-ilb-backend-service \
    --balancing-mode=UTILIZATION \
    --instance-group=l7-ilb-backend \
    --instance-group-zone=us-west1-a \
    --region=us-west1

URL 맵 만들기

gcloud

gcloud compute url-maps create l7-ilb-service-url-map \
    --default-service=l7-ilb-backend-service \
    --region=us-west1

리전 SSL 인증서 만들기

다음 예시에서는 gcloud를 사용하여 자체 관리 SSL 인증서를 만드는 방법을 보여줍니다. 자세한 내용은 자체 관리 SSL 인증서 사용Google 관리 SSL 인증서 사용을 참조하세요.

gcloud

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=us-west1

리전 SSL 인증서를 사용하여 대상 프록시 만들기

gcloud

gcloud compute target-https-proxies create l7-ilb-https-proxy \
    --url-map=l7-ilb-service-url-map \
    --region=us-west1 \
    --ssl-certificates=l7-ilb-cert

전달 규칙의 공유 IP 주소 예약

gcloud

gcloud beta compute addresses create \
    --addresses=10.1.2.99 \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

HTTPS 전달 규칙 만들기

gcloud

gcloud compute forwarding-rules create l7-ilb-https-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=443 \
    --region=us-west1 \
    --target-https-proxy=l7-ilb-https-proxy \
    --target-https-proxy-region=us-west1

HTTPS 부하 분산기 테스트

이제 부하 분산기(백엔드 서비스, URL 맵, 전달 규칙 포함)가 준비되었습니다. 이 부하 분산기를 테스트하여 예상대로 작동하는지 확인합니다.

클라이언트 VM 인스턴스를 생성하여 연결을 테스트합니다.

gcloud

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

SSH를 통해 클라이언트 VM에 연결합니다.

gcloud

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Curl을 사용하여 HTTPS 부하 분산기에 연결합니다.

curl -k -s 'https://10.1.2.99:443' --connect-to 10.1.2.99:443

샘플 결과:

Page served from: l7-ilb-backend-850t

100개의 요청을 보내고 모두 부하 분산되었는지 확인합니다.

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

샘플 결과:

***
*** Results of load-balancing to 10.1.2.99:
***
     51  l7-ilb-backend-https-850t
     49  l7-ilb-backend-https-w11t
    100 Page served from

HTTPS 부하 분산기로 트래픽 리디렉션

HTTP 부하 분산기에는 포트 80에서 443으로 트래픽을 리디렉션하는 공유 IP 주소가 있습니다.

트래픽 리디렉션을 위한 새 URL 맵 만들기

트래픽 리디렉션 구성으로 YAML 파일을 만듭니다.

echo "defaultService: regions/us-west1/backendServices/l7-ilb-backend-service
kind: compute#urlMap
name: l7-ilb-redirect-url-map
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- name: matcher1
  defaultUrlRedirect:
        hostRedirect: 10.1.2.99:443
        pathRedirect: /
        redirectResponseCode: PERMANENT_REDIRECT
        httpsRedirect: True
        stripQuery: True" > /tmp/url_map.yaml

YAML 파일을 새 URL 맵으로 가져옵니다.

gcloud

gcloud compute url-maps import l7-ilb-redirect-url-map \
    --source /tmp/url_map.yaml \
    --region us-west1

HTTP 부하 분산기의 대상 프록시 만들기

gcloud

gcloud compute target-http-proxies create l7-ilb-http-proxy \
    --url-map=l7-ilb-redirect-url-map \
    --url-map-region=us-west1 \
    --region=us-west1

새 전달 규칙 및 공유 IP 주소 만들기

gcloud

gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=80 \
    --region=us-west1 \
    --target-http-proxy=l7-ilb-http-proxy \
    --target-http-proxy-region=us-west1

트래픽 리디렉션 테스트

클라이언트 VM에 연결합니다.

gcloud

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

포트 80에서 http 요청을 10.1.2.99로 전송하고 트래픽 리디렉션을 기다립니다.

curl -L -k 10.1.2.99

샘플 결과:

Page served from: l7-ilb-backend-w11t

-vvv를 추가하여 세부정보를 확인할 수 있습니다.

curl -L -k 10.1.2.99 -vvv

* Rebuilt URL to: 10.1.2.99/
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< location: https://10.1.2.99:443/
< date: Fri, 07 Aug 2020 05:07:18 GMT
< via: 1.1 google
< content-length: 0
<
* Curl_http_done: called premature == 0
* Connection #0 to host 10.1.2.99 left intact
* Issue another request to this URL: 'https://10.1.2.99:443/'
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
...
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=Google TESTING; CN=test_cert_1
*  start date: Jan  1 00:00:00 2015 GMT
*  expire date: Jan  1 00:00:00 2025 GMT
*  issuer: O=Google TESTING; CN=Intermediate CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561a6b0e3ea0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Fri, 07 Aug 2020 05:07:18 GMT
< server: Apache/2.4.25 (Debian)
< last-modified: Thu, 06 Aug 2020 13:30:21 GMT
< etag: "2c-5ac357d7a47ec"
< accept-ranges: bytes
< content-length: 44
< content-type: text/html
< via: 1.1 google
<
Page served from: l7-ilb-backend-https-w11t
* Curl_http_done: called premature == 0
* Connection #1 to host 10.1.2.99 left intact

다음 단계