Edge에서 SNI 사용

Apigee Edge 문서입니다.
Go to the Apigee X 문서로 이동합니다. info

서버 이름 표시 (SNI)를 사용하면 여러 HTTPS 대상을 동일한 IP 주소와 포트에서 제공할 수 있으며 이러한 대상에서 동일한 TLS 인증서를 사용할 필요가 없습니다. 클라이언트에서 SNI가 사용 설정되면 클라이언트는 초기 TLS 핸드셰이크의 일부로 대상 엔드포인트의 호스트 이름을 전달합니다. 이를 통해 TLS 서버는 요청을 검증하는 데 사용할 TLS 인증서를 결정할 수 있습니다.

예를 들어 요청 대상이 https://example.com/request/path, 인 경우 TLS 클라이언트는 아래와 같이 TLS 핸드셰이크 요청에 server_name 확장 프로그램을 추가합니다.

Edge는 다음을 위한 SNI를 지원합니다.

  • 클라이언트 앱에서 API 프록시로의 요청. 이 시나리오에서 Edge는 TLS 서버 역할을 합니다.
  • Edge에서 백엔드로의 요청. 이 시나리오에서 Edge는 TLS 클라이언트 역할을 합니다.

SNI에 대한 자세한 내용은 다음을 참고하세요.

Edge에서 API 프록시에 대한 요청에 SNI 지원

API 프록시에 대한 요청의 SNI 지원은 호스트 별칭 및 가상 호스트에 의해 제어됩니다.

가상 호스트 및 호스트 별칭 정보

Edge에서 가상 호스트는 API 프록시가 노출되는 IP 주소 및 포트 또는 DNS 이름 및 포트를 정의하고 더 나아가 앱에서 API 프록시에 액세스하는 데 사용하는 URL을 정의합니다. IP 주소/DNS 이름은 Edge 라우터에 해당하고 포트 번호는 라우터의 열린 포트입니다.

가상 호스트를 만들 때 가상 호스트의 호스트 별칭도 지정합니다. 일반적으로 이는 가상 호스트의 DNS 이름입니다. 요청을 처리하는 API 프록시를 결정하는 과정에서 라우터는 수신 요청의 Host 헤더를 모든 가상 호스트에 의해 정의된 사용 가능한 호스트 별칭 목록과 비교합니다.

가상 호스트의 호스트 별칭과 포트 번호의 조합은 Edge 설치의 모든 가상 호스트에서 고유해야 합니다. 즉, 여러 가상 호스트가 동일한 포트 번호를 사용할 수 있습니다 (호스트 별칭이 다른 경우).

또한 가상 호스트는 API 프록시에 액세스하는 데 HTTP 프로토콜을 사용할 것인지 또는 TLS를 사용하는 암호화된 HTTPS 프로토콜을 사용할 것인지 정의합니다. HTTPS를 사용하도록 가상 호스트를 구성할 때는 TLS 핸드셰이크 중에 가상 호스트에서 사용하는 인증서와 비공개 키가 포함된 키 저장소를 가상 호스트와 연결합니다.

가상 호스트에 대한 자세한 내용은 다음을 참고하세요.

SNI가 호스트 별칭과 함께 작동하는 방식

SNI를 사용하면 동일한 포트에 여러 가상 호스트를 정의할 수 있으며 각 가상 호스트에는 서로 다른 TLS 인증서와 키가 있습니다. 그런 다음 Edge는 TLS 핸드셰이크 요청의 server_name 확장 프로그램을 기반으로 가상 호스트와 TLS에서 사용하는 인증서/키 쌍을 결정합니다.

Edge 라우터는 TLS 핸드셰이크 요청에서 server_name 확장 프로그램을 읽은 다음 이를 사용하여 모든 가상 호스트의 호스트 별칭을 검색합니다. 라우터가 호스트 별칭과 일치하는 항목을 감지하면 라우터는 호스트 별칭과 연결된 가상 호스트의 TLS 인증서와 키를 사용합니다. 일치하는 항목이 없으면 TLS 핸드셰이크가 실패합니다.

TLS 핸드셰이크가 실패하는 대신 다음 섹션에 설명된 대로 기본 인증서/키 쌍을 정의할 수 있습니다.

Cloud용 Edge에서 기본 인증서/키 쌍 정의

Apigee는 HTTPS를 지원하기 위해 TLS 인증서와 비공개 키를 제공합니다. 많은 고객이 배포 시 자체 인증서와 비공개 키를 사용하는 것을 선호하지만 Apigee 인증서와 키를 사용하여 API를 배포할 수 있습니다.

Cloud용 Edge에서 라우터가 SNI 헤더를 호스트 별칭과 일치시킬 수 없거나 클라이언트가 SNI를 지원하지 않는 경우 라우터는 Apigee에서 제공한 기본 인증서( *.apigee.net)를 사용합니다.

Private Cloud용 Edge에서 기본 인증서/키 쌍 정의

Private Cloud용 Edge에서 server_name 확장 프로그램과 모든 가상 호스트의 호스트 별칭 간에 일치하는 항목이 없거나 요청 클라이언트가 SNI를 지원하지 않는 경우 포트의 기본 가상 호스트에서 인증서/키를 사용하도록 라우터 를 구성할 수 있습니다. 기본 가상 호스트는 조직 이름, 환경 이름, 가상 호스트 이름의 조합으로 다음과 같은 형식으로 정의됩니다.

orgName_envName_vhName

라우터는 알파벳순으로 먼저 오는 orgName_envName_vhName 조합의 인증서/키를 사용합니다. 예를 들어 요청이 포트 443에서 수신되고 환경 prod의 조직 example에 대해 두 개의 가상 호스트가 정의되어 있습니다.

  • 가상 호스트 이름 = default
  • 가상 호스트 이름 = test

이 예시에서 라우터는 example_prod_default가 example_prod_test보다 알파벳순으로 먼저 나오기 때문에 default 라는 가상 호스트의 인증서/키를 사용합니다.

기본 가상 호스트를 사용 설정하려면 다음 단계를 따르세요.

  1. 첫 번째 라우터 노드에서 /opt/apigee/customer/application/router.properties를 수정합니다. 해당 파일이 없으면 만듭니다.
  2. 기본 가상 호스트를 정의할 수 있도록 다음 속성을 파일에 추가합니다. 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. 라우터를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. 나머지 모든 라우터에서 이러한 단계를 반복합니다.

기본 가상 호스트의 인증서/키를 사용하는 대신 라우터에서 기본 인증서/키를 명시적으로 정의할 수 있습니다. 다음 절차에 따라 명시적 기본 인증서/키 쌍을 정의합니다.

  1. 첫 번째 라우터 노드에서 인증서와 비공개 키를 apigee 사용자가 액세스할 수 있는 라우터 노드의 위치 에 복사합니다. 예를 들어 /opt/apigee/customer/application입니다.
  2. 파일의 소유권을 'apigee' 사용자로 변경합니다. 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
     
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. /opt/apigee/customer/application/router.properties를 수정합니다. 해당 파일이 없으면 만듭니다.
  4. 기본 인증서/키를 지정할 수 있도록 다음 속성을 파일에 추가합니다.
    conf_load_balancing_load.balancing.driver.nginx.fallback.server.default.ssl.template.enabled=true
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  5. router.properties에서 다음 속성을 설정하여 인증서와 키의 위치를 지정합니다. 
    conf_load_balancing_load.balancing.driver.nginx.ssl.cert=/opt/apigee/customer/application/myCert.pem
conf_load_balancing_load.balancing.driver.nginx.ssl.key=/opt/apigee/customer/application/myKey.pem
  6. 라우터를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. 나머지 모든 라우터에서 이러한 단계를 반복합니다.

Edge에서 백엔드로의 요청에 SNI 지원

Edge는 Cloud용 Apigee Edge 및 Private Cloud 배포에서 메시지 프로세서에서 대상 엔드포인트로의 SNI 사용을 지원합니다. 기본적으로 SNI는 Cloud용 Edge 메시지 프로세서 에서 사용 설정되고 Private Cloud에서는 사용 중지됩니다.

Private Cloud용 Edge에서 백엔드에 SNI 사용

Private Cloud용 Edge의 경우 기존 대상 백엔드와의 이전 버전과의 호환성을 위해 Apigee는 기본적으로 SNI를 사용 중지했습니다. 대상 백엔드가 SNI를 지원하도록 구성된 경우 Edge 버전에 대해 아래 설명된 대로 이 기능을 사용 설정할 수 있습니다.

다른 Edge 관련 구성은 필요하지 않습니다. 대상 환경이 SNI용으로 구성된 경우 Edge는 이를 지원합니다. Edge는 요청 URL에서 호스트 이름을 자동으로 추출하여 TLS 핸드셰이크 요청에 추가합니다.

Edge 버전 4.15.07.0x의 Edge와 백엔드 간에 SNI 사용 설정

다음 절차에 따라 SNI를 사용 설정합니다.

  1. 첫 번째 메시지 프로세서 노드에서 편집기에서 파일을 엽니다. /opt/apigee4/conf/apigee/message-processor/system.properties
  2. system.properties에서 다음 속성을 true로 설정합니다. 
    jsse.enableSNIExtension=true
  3. 메시지 프로세서를 다시 시작합니다. 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. 나머지 모든 메시지 프로세서에서 이러한 단계를 반복합니다.

Edge 버전 4.16.01 이상의 Edge와 백엔드 간에 SNI 사용 설정

다음 절차에 따라 SNI를 사용 설정합니다.

  1. 첫 번째 메시지 프로세서 노드에서 /opt/apigee/customer/application/message-processor.properties를 수정합니다. 해당 파일이 없으면 만듭니다.
  2. 다음 속성을 파일에 추가합니다. 
    conf_system_jsse.enableSNIExtension=true
  3. 메시지 프로세서를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. 나머지 모든 메시지 프로세서에서 이러한 단계를 반복합니다.