Edge와 함께 SNI 사용

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

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

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

Edge는 다음에 대한 SNI를 지원합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

클라우드용 Edge에서 기본 인증서/키 쌍 정의

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

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

프라이빗 클라우드용 Edge에서 기본 인증서/키 쌍 정의

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

orgName_envName_vhName

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

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

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

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

  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. user'로 변경합니다. 
    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는 클라우드 및 프라이빗 클라우드 배포를 위해 Apigee Edge의 엔드포인트를 타겟팅하는 데 메시지 프로세서의 SNI 사용을 지원합니다. 기본적으로 SNI는 클라우드의 에지 메시지 프로세서에서 사용 설정되고 프라이빗 클라우드에서는 사용 중지됩니다.

프라이빗 클라우드용 Edge의 백엔드에 SNI 사용

프라이빗 클라우드용 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. 나머지 모든 메시지 프로세서에서 이 단계를 반복합니다.