로드 밸런서가 SSL/TLS로 암호화된 데이터를 서버에 전달하도록 합니다. 클라이언트에 대한 새로운 HTTPS 연결이 설정되면 핸드셰이크가 어떻게 처리되는지 궁금합니다. 핸드셰이킹은 상태 저장 통신입니다. 예를 들어, 클라이언트의 완료된 메시지를 확인하기 위해서는 서버(팜)와 클라이언트 사이에 지금까지 교환된 모든 핸드셰이크 메시지를 서버가 알아야 합니다. 따라서 제가 보기에는 세 가지 가능성이 있습니다.
SSL/TLS 데이터는 모든 서버에서 공유되는 캐시에 보관됩니다.
핸드셰이크 메시지의 내용은 모든 서버에 복제됩니다.
로드 밸런서는 클라이언트의 모든 핸드셰이크 메시지를 동일한 서버로 전달합니다.
질문: 이러한 환경에서는 일반적으로 어떤 시나리오가 사용됩니까? 제가 놓친 악수 처리에 대한 추가 정책이 있습니까?
추가됨:내 질문이 중복되었다는 주장에 직면했고, 질문이 중복된 이유를 설명하기 위해 내 질문을 편집하라는 메시지가 표시됩니다.부하 분산 및 HTTPS 전략. 내 질문과 다른 질문을 비교하면 다음과 같습니다.
a) 로드 밸런싱 환경에서 https 상태를 처리하기 위한 세 가지 옵션을 찾아내고 실제로 어떤 옵션(또는 다른 옵션)이 사용되는지 물었습니다.
b) 다른 질문에서 OP는 옵션 3("동일 서버")을 사용합니다. 즉, 동일한 IP를 가진 모든 요청이 동일한 서버로 라우팅됩니다. 그러나 대부분의 클라이언트가 동일한 IP를 사용하기 때문에 lb는 제대로 작동하지 않으며 OP는 탈출구를 요청합니다. 5개 답변 중 4개 반은 실제로 위의 옵션 3을 유지하라는 제안을 제공합니다. 답변 중 한 부분("대상 서버용 DNS")을 이해하지 못했습니다.
따라서 문제는 옵션 1("ssl 캐시")과 2("ssl hanshake 데이터 복제")가 실제로 사용되는지 여부입니다. 기사http://wtarreau.blogspot.de/2006/11/making-applications-scalable-with-load.html옵션 1을 선호하는 것 같습니다("4. 전용 SSL-캐시 팜" 참조).
답변1
요구 사항이 설정의 모든 부분에 HTTPS를 포함하는 것이라면 클라이언트와 lb 간에 핸드셰이크를 수행한 다음 lb와 서버 간에 별도의 인증서 세트를 갖는 것이 더 쉽고 실현 가능합니다.
SSL 통과가 가능하며 일부 CDN에서는 이를 제공합니다. 내가 아는 한 모든 트래픽은 있는 그대로 전달되지만 로드 밸런싱은 허용되지 않습니다.
이 작업을 수행하려면 LB 수준에서 세션 고정성이 필요합니다.
답변2
Nginx에서 TCP 스트림 프록시를 통해 SSL 통과를 수행할 수 있습니다.
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/