ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • NSX-V LB https Guide
    VMware/NSX 2019. 2. 26. 18:54

    1 Preview

    1.1 테스트 목적

    NSX 환경에서 https의 Load Balancing 시 아래 각 방식에 대한 이해와 wire shark를
    통한 Packet 분석을 통해 메커니즘을 이해한다.

    1) https offload
    2) https passthrough
    3) https end-to-end
    4) client authentication

    1.2 테스트 환경

    LAB 환경 및 https 동작 방식에 따른 차이점은 아래와 같다.

    1) https-offload
    LB Server에서 https terminated하여 client – LB Sever에서만 https 통신이며
    LB Server- Back Server에서는 http 통신을 맺는다.

    << https-offload>>

    2) https-passthough
    LB Server에서 https를 terminated 하지 않고 Back Server까지 통과시킨다.
    Client – Back Server에서 https 통신을 맺기 때문에 Back Server에 https 통신을
    위한 인증서 설정이 필요하다.

    << https-passthough >>

    3) https-end-to-end
    LB Server에서 client에 대한 https를 terminated 후 Back Server와 새로운 https 통신을 맺는다.
    offload 방식의 단점인 LB Sever – Back Server에서의 보안 취약성을 보장 시켜주며 일반적으로 LB Server에서 양방향 암,복호화에 따른 부하가 증가되기 때문에 client side에서의 암호화는 2048, server side에서의 암호화는 1024로 설정하도 한다.

    << https-end-to-end >>

    4) Client, Server Authentication
    LB Server에서는 Client 및 Server의 인증서가 유효한지 확인 할 수 있다.
    이 옵션을 위해서는 인증 대상이 되는 Client 및 Server에 인증서가 설치되어야 하며 LB Server에는 Client 및 Server의 인증서의 RootCA 인증서가 설정되어 있어야 한다.

    << Authentication >>

    2 https offload

    2.1 Configuration

    https LB를 위해 Certification 먼저 설정을 하도록 한다.
    CA 인증서 메뉴는 Root 인증서 및 중간 인증서 추가가 가능하다.

    << 인증서 추가 >>

    LB – Application Profile에서 아래와 같이 설정 하도록 한다.

    << application profile 설정 >>

    LB – Service Monitoring에서 아래와 같이 설정하도록 한다.
    https-offload 방식은 SSL 통신이 LB Server에서 terminated되기 때문에
    Back Server와는 http 통신만 하게 된다.

    << Service Monitoring 설정 >>

    LB – Pools – Member에서 아래와 같이 설정하도록 한다.
    참고로 Port 항목을 비우면 LB Server – Back Server의 http session이 되지 않는다.

    << Pools Member 설정 >>

    LB – Pools에서 아래와 같이 설정하도록 한다.

    << Pools 설정 >>

    LB – Virtual Server에서 아래와 같이 설정하도록 한다.
    Acceleration 설정은 L4 Performance 방식이기 때문에 Disable 한다.

    << Virtual Server 설정 >>

    Edge SSH 접속 후 아래 Command로 Engine 및 Pool status 확인하도록 한다.
    ‘show service loadbalancer virtual’

    << SSH Command >>

    2.2 Check

    VIP로 접속하여 LB 작동을 확인한다.

    << VIP 접속 >>

    아래와 같이 LB Server에서 Client와 Back Server간 패킷을 캡처한다.

    << LB Packet Capture >>

    Client – LB Server 패킷을 Wire Shark로 확인한 결과 아래와 같이 SSL 핸드쉐이킹이 확인된다.

    << Server – LB Server Packet >>

    LB Server – Back Server 패킷 확인 결과 ssl offload 방식이기 때문에 Back Server는 http를 이용하여 세션을 맺는다.

    << LB Server – Back Server Packet >>

    3 https Passthrough

    3.1 Configuration

    LB – Application Profile에서 아래와 같이 설정 하도록 한다.

    << application profile 설정 >>

    LB – Pools – Member에서 아래와 같이 설정하도록 한다.
    Passthrough 방식이기 때문에 http가 아닌 https에 대한 모니터링을 설정한다.

    << Pool Member 설정 >>

    LB – Pools에서 아래와 같이 설정하도록 한다.

    << Pools 설정 >>

    LB – Virtual Server에서 아래와 같이 설정하도록 한다.

    << Virtual Server 설정 >>

    3.2 Check

    VIP로 접속하여 LB 작동을 확인한다.

    << VIP 접속 >>

    Client – LB Server 패킷을 Wire Shark로 확인한 결과 아래와 같이 SSL 핸드쉐이킹이 확인되며 아래 인증서 패킷을 확인해보면 기존의 LB Server 인증서가 아닌
    web-server의 인증서를 이용한 통신이 확인된다.

    << Client – LB Server Packet >>

    LB Server – Back Server 패킷 확인 결과 ssl passthrough 방식이기 때문에
    offload 방식과는 다르게 Back Server가 https를 이용하여 세션을 맺으며 Server Hello 패킷을 확인해보면 동일한 인증서를 확인 할 수 있다.

    << LB Server – Back Server Packet >>

    또한 Client Hello 패킷에서 공통키 생성을 위한 Random 값을 보면
    Client – LB Server – Back Server 모두 동일하다는 것을 알 수 있다.

    << Client – LB Server – Back Server Random 값 비교 >>

    4 https End-to-End

    4.1 Configuration

    End-to-End 방식도 passthrough 방식과 마찬가지로 pool member들이 https로 구성되기 때문에 Application Profile에서 아래와 같이 수정만 하면 된다.

    << Application Profile 설정 >>

    4.2 Check

    Client Hello 패킷에서 공통키 생성을 위한 Random 값을 보면 Passthrough 방식과 다르게 Client – LB Server – Back Server Random 값이 서로 다른 걸 확인 할 수 있다.
    다만 Wire Shark에서 LB Server – Back Server 패킷 분석 시 Server Side의 인증서에 대한 내용이 패킷에서 확인되지 않는데 이 부분은 좀 더 확인이 필요하다.

    << Client – LB Server – Back Server Random 값 비교 >>

    5 Client Authentication

    5.1 Configuration

    Client Authentication은 LB Server에서 Client의 신원 확인을 위해 인증서를 확인하는 옵션이다.
    Client에는 LB Server의 등록되어 있는 CA 인증서의 서명을 받은 하위 인증서가 설치되어야 한다.
    Client side에서 사용 할 인증서와 Client 인증서를 인증 할 CA 인증서를 생성한다.

    << CA인증서, pfx 인증서 >>

    LB – Application Profile에서 아래와 같이 Client Authentication을 설정하며
    Client 인증서의 Root가 되는 CA 인증서를 등록한다.

    << Application Profile 설정 >>

    5.2 Check

    Client에 인증서 미 설치시에는 아래와 같이 접근이 거부된다.

    << 인증서 없이 접속 >>

    Client에 Root CA의 인증을 받은 인증서를 설치 후 다시 시도하면
    아래와 같이 Client 인증을 받을 수 있다.

    << 인증서 설치 후 접속 >>

    Wire Shark를 통해 Client – LB Server Packet을 확인한 결과 아래와 같이 기본적인
    ssl 핸드쉐이크 외에 Client의 인증서를 전송하는 내용이 있으며 새로 생성한 sds 이름의 인증서를 전송하는 것을 확인 할 수 있다.


    << Client – LB Server Packet >>

    6 Server Authentication

    6.1 Configuration

    Server Authentication은 LB Server에서 Back Server의 인증서를 확인하는 옵션이다.
    Back Server에는 LB Server의 등록되어 있는 CA 인증서의 서명을 받은 하위 인증서가 설치되어야 한다

    Application Profile에서 아래와 같이 Pool Certificates에서 Server Authentication을 활성화 후 Root CA
    인증서를 설정한다.


    << Application Profile >>

    6.2 Check

    Back Server에는 LB Server에 있는 CA 인증서의 서명을 받은 하위 인증서가 설치되어 있다.

    << Back Server 인증서 >>

    먼저 LB Server의 CA 인증서를 잘못 된 인증서로 설정 후 패킷을 분석해보면 아래와 같이
    잘못 된 인증서라는 내용이 확인된다.


    << 잘못 된 CA 인증서 설정 >>

    << 잘못 된 CA 인증서 설정 후 패킷 >>

    LB Server의 CA 인증서를 다시 설정 한 후 패킷을 확인해 보면 아래와 같이 정상 통신을 확인 할 수 있다.

    << 정상적인 CA 인증서 설정 후 패킷 >>

    댓글

Designed by Tistory.