Zimbra 프록시 서버에서 HTTPS 리디렉션을 활성화하는 방법

Zimbra 프록시 속성을 사용하여 zimbraReverseProxyMailMode웹 요청을 HTTP에서 HTTPS로 리디렉션할 수 있습니다. 모든 Zimbra 프록시 노드에서 이 속성을 활성화한 redirect다음 프록시 서비스를 재시작하고 HTTP 응답에 Location: https://...헤더가 있는지 확인하십시오. 이 작업을 수행하기 전에 공개 HTTPS 호스트 이름이 프록시 또는 로드 밸런서로 확인되고 유효한 인증서를 제공하는지 확인하십시오.

이 설정은 Zimbra 프록시를 통한 웹 액세스를 위한 것입니다. 이 설정 자체만으로는 메일 저장소의 HTTPS를 구성하거나, 인증서를 설치하거나, 모든 메일 애플리케이션이 리디렉션을 따르도록 보장하지 않습니다. HTTP 요청을 완전히 차단해야 하는 경우 리디렉션 대신 HTTPS 전용 프록시 모드를 고려하십시오.

mail.example.com이 두 개의 Zimbra 프록시 노드를 가리키고, 이 프록시 노드들이 다시 메일함 서버에 연결되는 방식을 보여주는 다이어그램입니다. — 예시 토폴로지: 공용 메일 호스트 이름은 요청이 메일함 서버로 전달되기 전에 프록시 계층에 도달합니다.

배포 환경에 맞는 동작을 선택하세요.

프록시 메일 모드	HTTP에는 무슨 일이 일어날까요?	언제 사용해야 할까요?
`redirect`	프록시는 클라이언트를 HTTPS로 연결하는 HTTP 302 응답을 반환합니다.	사용자가 여전히 HTTP URL을 입력하고 보안 웹 주소로 이동해야 할 때 유용합니다.
`https`	프록시 서버는 웹 클라이언트에게 HTTPS를 통해 서비스를 제공하며, HTTP에서 HTTPS로의 리디렉션 흐름은 제공하지 않습니다.	클라이언트가 HTTP를 통해 세션을 시작해서는 안 되는 경우에 이 방법을 사용하는 것이 좋습니다.
`both`또는`mixed`	이것들은 서로 다른 HTTP/HTTPS 동작을 가진 별개의 프록시 모드입니다.	배포 환경에서 문서화된 동작이 특별히 필요한 경우에만 사용하십시오. HTTP 리디렉션이 강제된다고 가정하지 마십시오.

Zimbra의 보안 지침에 따르면 ActiveSync 클라이언트를 포함한 일부 클라이언트는 HTTP 리디렉션을 제대로 처리하지 못하고 암호화되지 않은 초기 요청에 자격 증명을 전송할 수 있습니다. 따라서 리디렉션은 브라우저 편의성을 위해 유용하지만, 모든 클라이언트가 HTTP를 사용하지 않아야 하는 경우 HTTPS 전용 액세스를 대체할 수는 없습니다. 리디렉션 모드를 선택하는 경우 네트워크 경계에서 HTTP 리스너를 적절하게 보호하고 사용자에게 HTTPS URL을 알려주십시오.

자물쇠 아이콘과 함께 https://mail.example.com의 Zimbra 웹 클라이언트 로그인 페이지가 표시된 브라우저 창. — 프록시 동작을 변경하기 전에 공용 웹메일 호스트 이름이 HTTPS를 통해 열리고 신뢰 자물쇠 표시기가 나타나는지 확인하십시오.

프록시를 변경하기 전에

적용 범위를 확인하십시오. 이 절차는 Zimbra Proxy에서 처리하는 웹 트래픽을 변경합니다. 배포 환경에 프록시 서비스가 이미 활성화되어 작동 중이어야 합니다.
공용 엔드포인트를 확인하십시오. 사용자가 방문하는 호스트 이름(예: mail.example.com)은 공용 프록시 또는 로드 밸런서로 확인되어야 합니다. 예상되는 호스트 이름과 포트에서 HTTPS가 이미 작동하고 있어야 합니다.
인증서를 확인하십시오. 사용자를 리디렉션하기 전에 공개 호스트 이름에 대한 인증서 체인을 설치하고 유효성을 검사하십시오. 손상되었거나 일치하지 않는 인증서로 HTTPS로 리디렉션하면 오류가 다음 요청으로 넘어갈 뿐입니다.
모든 프록시 노드를 식별하십시오. 로드 밸런싱 환경에서는 각 프록시 서버의 Zimbra 서버 이름을 기록해 두십시오. 한 프록시에 적용된 변경 사항은 다른 프록시에 자동으로 적용되지 않습니다.
필요한 경우 유지 관리 시간을 계획하십시오. 프록시 서비스를 재시작하면 해당 노드를 통한 연결이 일시적으로 중단될 수 있습니다. 이중화된 배포 환경에서는 변경 사항을 한 번에 하나의 노드에 적용하고 서비스 상태를 모니터링하십시오.

아래 관리 명령에는 Zimbra 계정을 사용하십시오. proxy1.example.com<프록시 노드의 정확한 Zimbra 서버 이름>과 mail.example.com<공개 웹메일 호스트 이름>을 바꿔주세요. 예시 이름을 실제 운영 시스템에 그대로 붙여넣지 마십시오.

HTTP에서 HTTPS로의 리디렉션을 활성화합니다.

1. 현재 프록시 모드를 기록합니다.

명령줄 도구를 사용할 수 있는 Zimbra 호스트에서 프록시의 현재 설정을 조회합니다.

zmprov gs proxy1.example.com zimbraReverseProxyMailMode

변경 후 결과를 비교하거나 필요한 경우 이전 모드로 복원할 수 있도록 출력 내용을 기록해 두십시오. 아래 gs명령어는 서버 속성을 읽고 ms, 수정합니다.

예시 터미널 창에서 proxy1.example.com에 대한 zimbraReverseProxyMailMode를 쿼리하고 현재 값으로 https를 표시하는 모습입니다. — 이 예시 명령은 하나의 프록시 노드에서 현재 메일 모드를 읽습니다. 실제 서버에는 다른 값이 표시될 수 있습니다.

2. 프록시 모드를 리디렉션으로 설정합니다.

프록시 서버 객체에 속성을 설정합니다.

zmprov ms proxy1.example.com zimbraReverseProxyMailMode redirect

Zimbra Proxy 구성 문서에서는 redirectHTTP 요청을 HTTPS로 리디렉션하는 모드를 설명합니다. 공용 웹 트래픽을 처리하는 각 프록시 노드에 동일한 명령을 적용하십시오. 로드 밸런서가 여러 프록시로 HTTP 요청을 보낼 수 있는 경우, 모든 프록시는 일관된 동작을 보여야 합니다.

이 설정을 Zimbra 문서에서 메일함 서버 연결에 대한 속성을 별도로 설명하는 것과 혼동하지 마십시오 zimbraMailMode. 메일 저장소 모드를 변경하는 것은 프록시에서 브라우저에 대한 HTTP 리디렉션을 활성화하는 단계가 아닙니다.

예시로 보여주는 터미널 명령어 설정입니다. zimbraReverseProxyMailMode를 proxy1.example.com으로 리디렉션하도록 설정합니다. — 프록시의 메일 모드를 설정합니다 `redirect`. 다중 노드 배포 환경에서는 각 프록시 서버 이름에 대해 이 과정을 반복합니다.

3. 각 프록시에 변경 사항을 적용합니다.

설정을 변경한 노드에서 프록시 서비스를 다시 시작하십시오.

zmproxyctl restart

그런 다음 서비스 상태를 확인하십시오.

zmproxyctl status

이중화 계층을 사용하는 경우 각 프록시 노드에서 재시작을 한 번에 하나씩 실행하십시오. 환경에 구성 캐시 새로 고침 또는 서비스 오케스트레이션 프로세스가 규정되어 있는 경우 설치된 Zimbra 버전의 운영 지침을 따르십시오. 생성된 Nginx 파일을 직접 편집하지 마십시오. Zimbra는 서버 설정에서 프록시 구성을 관리하므로 수동으로 편집하면 덮어쓰여질 수 있습니다.

이 예제들은 Zimbra Daffodil v10 관리자 가이드와 Zimbra에서 제공하는 프록시/보안 문서를 기반으로 합니다. 이전 버전의 ZCS 릴리스는 패키징이나 지원되는 절차가 다를 수 있으므로, 변경 사항을 적용하기 전에 사용 환경에 설치된 정확한 릴리스 버전의 관리자 가이드를 확인하십시오.

Zimbra 구성 캐시 새로 고침 후 zmproxyctl 재시작이 실행되는 과정을 보여주는 예시 터미널 시퀀스입니다. — 다음은 구성 데이터를 새로 고치고 프록시를 다시 시작하는 일련의 작업 순서입니다. 설치된 릴리스에서 지원하는 절차를 따르십시오.

리디렉션 및 HTTPS 응답을 확인하십시오.

4. HTTP 응답 헤더를 확인하세요

공용 엔드포인트에 접근할 수 있는 시스템에서 리디렉션을 거치지 않고 HTTP URL을 요청합니다.

curl -sS -D - -o /dev/null http://mail.example.com/

리디렉션 모드에서는 302 응답과 Location값이 로 시작하는 헤더를 찾으세요 https://mail.example.com/. 정확한 헤더 및 상태 처리는 Zimbra 릴리스, 경로, 프록시 앞에 있는 로드 밸런서 또는 웹 게이트웨이에 따라 다를 수 있습니다. 다음 화면은 예상되는 헤더 패턴의 예시이며, 실제 서버에서 캡처한 테스트 결과가 아닙니다.

HTTP 요청에 대한 터미널 출력 예시입니다. 응답 코드는 302 Found이고, Location 헤더는 https://mail.example.com/을 가리킵니다. — 예상되는 리디렉션 패턴: HTTP는 302 응답을 반환하고 브라우저를 HTTPS 호스트 이름으로 연결합니다. 실제 응답 헤더 및 날짜는 다를 수 있습니다.

5. HTTPS 및 인증서를 확인합니다.

보안 URL에 별도의 요청을 보내십시오.

curl -sS -D - -o /dev/null https://mail.example.com/

TLS 인증서가 호스트 이름에 대해 유효한지, 그리고 응답이 예상되는 웹메일 페이지 또는 애플리케이션 리디렉션인지 확인하십시오. curl -k인증서 검증을 우회하는 데 사용하지 마십시오. 그렇게 하면 사용자가 보게 될 인증서 문제를 숨길 수 있습니다. 로그인 페이지는 제품 버전 및 인증 흐름에 따라 리디렉션되거나 200 이외의 상태 코드를 반환할 수 있으므로 브라우저 검사와 함께 응답을 판단하십시오.

mail.example.com에 대한 HTTPS 요청 시 성공적인 HTTP 응답 및 인증서 확인이 표시되는 터미널 출력 예시입니다. — 예시에서는 호스트 이름과 일치하는 인증서를 사용하여 HTTPS로 서비스에 접속하는 방법을 보여줍니다. 실제 엔드포인트에서 인증서 체인을 확인하십시오.

6. 브라우저에서 테스트

새 브라우저 세션에서 해당 페이지 를 엽니다 http://mail.example.com. 자격 증명을 입력하기 전에 주소가 HTTPS URL로 변경되어야 합니다. 그런 다음 HTTPS URL을 직접 열고 인증서 경고 없이 로그인 페이지가 로드되는지 확인합니다. 공용 DNS, 방화벽 규칙 또는 로드 밸런싱으로 인해 결과가 달라질 수 있는 경우 내부 네트워크 외부에서 동일한 작업을 반복합니다.

주소 표시줄에 HTTP가 표시된 상태에서 실제 비밀번호를 입력하여 테스트하지 마십시오. 리디렉션이 실패하면 먼저 프록시, 엣지 또는 인증서 구성을 중지하고 수정하십시오.

Zimbra 웹 클라이언트 로그인 페이지가 브라우저에 표시되고 주소 표시줄에 자물쇠 아이콘이 나타납니다. — 최종 브라우저 확인: 리디렉션 후 로그인 페이지가 HTTPS 호스트 이름으로 제공됩니다.

문제 해결 빠른 참조

징후	확인해야 할 사항
HTTP는 동일한 URL을 유지합니다.	요청을 처리한 프록시에 쿼리를 실행 `zimbraReverseProxyMailMode`하여 모든 로드 밸런싱 노드가 의도한 값을 가지고 있고 재시작되었는지 확인합니다.
Location 헤더에 잘못된 호스트 이름 또는 포트가 사용되었습니다.	공개 링크 생성에 사용된 공개 URL, 리버스 프록시 또는 로드 밸런싱 규칙, 그리고 Zimbra 공개 서비스 호스트 이름/프로토콜/포트 설정을 확인하십시오.
브라우저에서 인증서 경고를 표시합니다.	TLS 종료 지점에 인증서가 설치되어 있는지, 공개 호스트 이름을 포함하는지, 그리고 필요한 인증서 체인이 모두 포함되어 있는지 확인하십시오.
사용자는 리디렉션 루프를 보게 됩니다.	프런트엔드 로드 밸런서가 TLS는 종료하지만 HTTP는 Zimbra로 포워딩하는지 검토하고, 프록시가 외부 요청 프로토콜을 올바르게 식별할 수 있는지 확인하십시오. 네트워크 에지에서 TLS 및 포워딩 구성을 일치시키십시오.
메일 클라이언트는 여전히 HTTP를 사용합니다.	클라이언트가 302 리디렉션을 따른다고 가정하지 마십시오. HTTP를 통해 자격 증명을 절대 전송해서는 안 되는 클라이언트의 경우 HTTPS 전용 액세스를 권장하고, 각 클라이언트에 HTTPS 서버 URL을 구성하십시오.

배포 체크리스트

공개 HTTPS URL은 의도된 프록시 또는 로드 밸런서로 연결됩니다.
TLS 인증서는 공개 호스트 이름에 대해 유효하며 클라이언트에서 신뢰받습니다.
zimbraReverseProxyMailModeredirect해당 프록시 노드마다 설정되어 있습니다 .
프록시 서비스가 설치된 Zimbra 릴리스의 절차에 따라 재시작되었습니다.
HTTP 요청은 HTTPS Location헤더를 반환하고, 직접적인 HTTPS 요청은 인증서를 검증합니다.
사용자와 메일 클라이언트가 HTTPS로 설정되어 있는 경우, 리디렉션 모드는 모든 클라이언트가 첫 번째 요청을 보호한다는 보장을 의미하지 않습니다.