SaaS HTTPS 백엔드 서버에서 바니시 사용 하시겠습니까?

Question

HTTPS (!) 서비스를 백엔드 서비스로 사용하도록 Varnish를 구성하고 싶습니다. 여기서 핵심은 백엔드 서비스에 대한 SSL 연결 부분입니다! 나는 HTTPS 백엔드 서비스 (클라우드에서 호스팅되는 SaaS 서비스로 생각)를 제한적으로 관리하고 있습니다.

이

그것은이 같은 설정 것 : 사용자 에이전트 -> AWS ELB는 SSL 종결로 - AWS에서> 니스 -> 클라우드에서 SaaS는 서비스를

이유를 그것에 대해 다음과 같다 HTTPS 같이 - 내가 원하는 Varnish ESI를 사용하여 내 사용자 지정 페이지 헤더 & 바닥 글을 사용하여 SaaS 서비스 UI를 꾸미십시오. - 모든 요청이 바니시를 통과하면 SaaS 서비스에 대한 추가 분석 데이터를 얻을 수 있습니다. - 바니시를 사용하여 SaaS 서비스의 URL을 효과적으로 다시 작성하여 SaaS 서비스 URL을 효과적으로 숨길 수 있습니다. -users

AWS ELB를 사용자 에이전트에 대한 SSL 터미네이터로 사용할 수 있습니까?하지만 Varnish가 HTTPS SaaS 서비스를 원본 서버로 액세스하려면 어떻게해야합니까?

배경 : Google은 고객에게 다양한 서비스 (모든 서비스에는 자체 UI가 있습니다. 즉, 헤드리스 RESP API가 없습니다)를 제공하는 웹 포털에서 작업합니다. 모든 서비스를 하나로 묶는 가장 큰 장점은 일반적인 페이지 머리글과 바닥 글 (페이지 머리글은 최상위 탐색 및 로그인/사용자 이름 로그 아웃을 보여줍니다)입니다.

우리가 가지고있는 서비스 유형은 다음과 같습니다. 모두 복제하지 않으려는 자체 UI 레이어가 있습니다. - 흰색 라벨링 된 타사 SaaS 서비스 (예 : Zendesk 또는 Salesforce)는 구름 - 사내는 AWS 에서 호스팅되는 JavaEE 어플/봄 서비스 개발 - 우리 회사에서 다른 팀이 개발 한 서비스,하지만 그들은 우리 자신의 데이터 센터에서 호스팅되는

ESI가 포함되어 추가하면 이러한 서비스의 각 괜찮습니다 ,하지만 각 서비스에 대해 페이지 머리글/바닥 글을 여러 번 다시 구현하는 작업을 복제해야하는 것은 아닙니다.

Answer 1

바니시에서 HTTPS 백엔드 액세스는 지원되지 않습니다. 바니시는 HTTP를 백엔드에 알려줍니다.

HTTPS 백엔드 컨텐츠에 액세스하려면 HTTPS를 추가/제거하는 다른 데몬/프록시를 통해 프록시해야합니다. 이것에 대한 몇 가지 선택이 있는데 그 중 하나는 시도되어 테스트 된 stunnel입니다.

당신이 묘사하고있는 것 (내용 재 작성)에서 당신은 틀린 망치를 사용하는 것에 아주 가깝다고 말하고 싶습니다. Varnish가 이것을위한 최상의 도구가 아닐 수도 있습니다. 대신에 mod_rewrite/mod_substitude와 함께 붙이는 것을 고려 했습니까?

Answer 2

최근에 https를 사용하여 원하는 백엔드에 액세스해야하는 비슷한 요구 사항이 발생했습니다.

왜 이것이 잘못된 방법인지에 관해 제기 될 수있는 많은 반대 의견이 있습니다. 그러나이 경우에는 암호화 된 데이터가 필요하다는 사실 때문에 제약을 받았습니다. 백엔드, 중요한 지리적 인 거리, 그리고 다양한 시스템의 소유권과 제어로 인해 VPN이 불가능하다는 사실을 알게되었습니다.

제한된 테스트에서 stunnel4을 사용하여이 문제를 해결할 수있는 해결책이 있습니다.구성에서

샘플 라인 :

이제

client = yes 
[mysslconnect] 
accept = 8888 
connect = dest.in.ation.host.or.ip:443 

는 stunnel4 내 로컬 (니스) 시스템에서 포트 8888을 듣고 있으며, 들어오는 연결이 도착할 때마다, 그것은 포트 443에 대한 SSL 연결을 설정 원격 시스템에서.

로컬 서버의 127.0.0.1 포트 8888에 연결하면 대상 백엔드 서버에 일반 텍스트 HTTP를 말할 수 있으며 실제로 stunnel4에서 관리하는 SSL 연결을 통해 발생합니다 ... 이렇게 와니스를 다음과 같이 구성합니다. starnnel4가 무엇을 대신하는지에 대해 알지 못하기 때문에 varnish가 일반적인 http 서버에 대해 말하고 있다고 생각하기 때문에 백엔드에서 127.0.0.1:8888을 사용하십시오.

방금 ​​작동하지 않았기 때문에 확장 성 또는 신뢰성을 보장 할 수는 없지만 지금까지는 바니시에서이 제한 사항에 대한 실행 가능한 해결 방법 인 것으로 보입니다.