AWS Network Load Balancer에 SSL을 적용한 후 IP 통신 문제

들어가며

요즘들어 OO비교 서비스를 제공하는 업체들을 자주 접하게 되었다. 타 기관의 인프라 조건을 사전에 모두 파악할 수 없기에 연동 기관이 추가될 때마다 고려해야할 사항이 늘어났다. 

 

이번 케이스는 기존 연동 기관과 신동 연동 기관의 api 호출 방법이 다른 것에서 시작됐다. 

기존에 연동중인 협력사들은 NLB의 고정 Private IP를 사용해 NLB에 접근하고 있었다. 새로 연동하는 B 은행은 내부 정책상 도메인을 사용해 NLB로 요청을 보내야했다. 도메인 통신을 위해서는 NLB의 리스너에 SSL/TLS인증서(이하 SSL 인증서)를 적용해야하는데, 이렇게 되면 기존의 IP 통신에 문제가 생긴다. 

 

NLB에 SSL 인증서를 적용하면 IP 통신을 할 수 없는 이유 

SSL 인증서의 작용 원리를 생각해보면 당연한 일 

 

클라이언트가 서버와 보안 연결을 설정할 때 SSL인증서의 도메인 이름이 연결하려는 도메인 이름과 일치하는지 확인하는데, 이때 도메인 이름 대신 IP 주소로 연결을 시도하면 인증서 도메인 이름과 IP 주소가 일치하지 않아 SSL/TLS 핸드셰이크가 실패하게 된다. 

즉 인증서의 도메인 이름과 연결에 사용된 IP 주소 간의 불일치로 인해 문제가 발생하고, 443 포트 리스너에 SSL 인증서를 적용했다면 해당 포트로는 IP 주소를 사용하여 통신할 수 없게 된다. 

NLB의 리스너에 SSL 인증서를 적용하고 테스트했을 때 다음과 같은 결과를 확인했다. 

 

SSL 인증서 미적용

1. HTTP IP 통신 O 
2. HTTP 도메인 통신 O

SSL 인증서 적용

1. HTTP IP 통신 X
2. HTTP 도메인 통신 X 
3. HTTPS 도메인 통신 O 

 

꼭 IP 통신을 해야한다면 ? 

유연성과 보안을 고려하면 도메인 통신을 하는 것이 바람직하지만, 반드시 IP 를 사용해서 액세스해야한다면 몇 가지 대안을 생각해볼 수 있다. 

1. NLB의 SSL 인증서가 적용되지 않은 포트로 접근 → 백엔드 인스턴스에서 신규 포트를 열어주는 작업이 필요할수도 

2. IP 통신을 위한 NLB 생성 → 도메인 수신용 NLB와 IP 수신용 NLB 2개를 관리해야하므로 비용, 운영 부담 증가

3. NLB 뒷단의 백엔드 인스턴스 IP로 직접 접근  → 트래픽 부하 분산 불가, 확장성 X 

 

이번 사례에서는 1번을 채택하여 진행하기로 했다. 기존에 IP 통신을 하던 협력사들도 도메인 통신을 하는 쪽으로 변경할 예정이다. 

 

테스트 환경

• NLB 유형: Internal
• NLB IP: 10.100.128.100

1. SSL 인증서 적용 전

 

SSL 인증서 미적용

대상 인스턴스 상태 확인

SSL 인증서 적용 전 HTTPS 통신 불가

 

2. SSL 인증서 적용 후 

 

IP를 사용해 SSL 인증서가 적용된 443 포트로 요청

도메인을 사용해 SSL 인증서가 적용된 443 포트로 요청

 

3. 최종 구성 및 확인

기존에 IP 통신을 하던 곳들은 우선 80포트를 통해 접근하고, 도메인을 사용하는 경우 443 포트를 통해 https 통신을 하도록 설정했다.

IP를 사용해 SSL 인증서가 적용되지 않은 80포트로 요청

도메인을 사용해 SSL 인증서가 적용된 443 포트로 요청

 

 

마치며 

이 기술을 왜 사용하는지 본질에 대해 생각하면 대부분의 문제를 해결 할 수 있다. 작동원리를 생각하면 문제의 원인을 빠르게 파악할 수 있다. 인프라를 설계할 때도 이 점을 염두에 두고 설계한다면 예상되는 문제들을 미리 차단할 수 있다. 5why까지는 아니더라도 3why정도는 해보자.