리버스 프록시는 홈 서버 컨테이너의 TLS를 어떻게 처리하나요?

리버스 프록시는 홈 서버 컨테이너의 TLS를 처리하며, 브라우저의 암호화된 연결을 수락하고 요청된 호스트명에 대한 인증서를 제시하며 HTTP 요청을 복호화하고 일치하는 컨테이너를 선택한 후 해당 서비스에 별도의 업스트림 연결을 생성합니다.

브라우저-프록시 연결과 프록시-컨테이너 연결은 서로 다른 보안 경계입니다. 첫 번째는 일반적으로 공개 또는 비공개 신뢰 인증서를 사용하며, 두 번째는 격리된 HTTP 네트워크, 별도의 HTTPS 연결 또는 백엔드가 개인 키를 유지해야 할 때 TLS 패스스루를 사용할 수 있습니다.

브라우저 TLS 연결은 어디서 종료되나요?

TLS 종료 시, 리버스 프록시가 클라이언트 TLS를 종료합니다. 브라우저는 애플리케이션 컨테이너와 직접 암호화 협상하는 대신 프록시 엔드포인트를 인증하고 암호화를 협상합니다.

따라서 프록시는 인증서 개인 키를 보유하며 복호화된 HTTP 메서드, 호스트명, 경로, 헤더, 쿠키, 본문을 읽을 수 있습니다. 이 가시성 덕분에 라우팅, 인증, 필터링, 압축, 캐싱 또는 보안 헤더 추가가 가능합니다.

종료(Termination)는 백엔드가 공개 인증서를 소유한다는 의미가 아닙니다. 브라우저 관점에서 리버스 프록시는 HTTPS 서버이고, 컨테이너 관점에서 프록시는 별도의 요청을 하는 새로운 클라이언트입니다.

하나의 HTTPS 포트가 여러 컨테이너에 어떻게 도달하나요?

공개 DNS 이름은 클라이언트를 리버스 프록시로 안내하며, 호스트명이 일치하는 컨테이너 경로를 선택합니다. 각 호스트명은 자체 인증서와 업스트림 대상지를 가질 수 있으며 포트 443을 공유합니다.

TLS 핸드셰이크 동안 클라이언트는 일반적으로 의도된 서버 이름을 제공하여 프록시가 일치하는 인증서를 선택할 수 있게 합니다. 복호화 후 HTTP Host 헤더와 구성된 경로에 따라 요청이 Jellyfin, Home Assistant, Vaultwarden 또는 다른 컨테이너로 전달됩니다.

기본 경로는 임의의 대시보드로 전달하기보다는 알 수 없는 호스트명을 거부해야 합니다. 진입점을 중앙 집중화한다고 해서 모든 내부 서비스가 공개 프록시를 통해 접근 가능해질 필요는 없습니다.

인증서는 어떻게 발급되고 갱신되나요?

리버스 프록시는 ACME 클라이언트 역할을 할 수 있으며, DNS 챌린지는 요청된 도메인 제어를 증명하는 임시 DNS 레코드를 생성하여 인증서 갱신을 자동화합니다.

HTTP 챌린지는 웹 엔드포인트를 통한 제어를 증명하며, DNS 챌린지는 각 컨테이너를 직접 공개하지 않고 내부 서비스나 와일드카드 이름에 대한 인증서를 발급할 수 있습니다. 검증 방법은 노출과 자격 증명 요구 사항을 변경합니다.

자동화는 인증서 만료를 수동 달력 작업에서 인프라 상태로 이동시킵니다. 또한 프록시의 DNS API 토큰, ACME 계정 데이터 및 인증서 저장소를 좁은 권한과 백업이 필요한 민감한 자산으로 만듭니다.

프록시와 컨테이너 간 트래픽은 암호화되나요?

업스트림은 독립적으로 구성되므로 업스트림 링크는 HTTP 또는 HTTPS를 사용할 수 있습니다. 공개 TLS 종료가 내부 연결의 암호화 여부를 자동으로 결정하지는 않습니다.

단일 신뢰 호스트에 제한된 개인 컨테이너 네트워크에서는 일반 HTTP가 합리적일 수 있지만, 프록시는 해당 트래픽을 읽고 수정할 수 있습니다. 업스트림이 호스트, 신뢰할 수 없는 네트워크 또는 더 강한 신뢰 경계를 넘는 경우, 별도의 검증된 HTTPS 연결이 노출을 줄입니다.

재암호화는 두 개의 TLS 세션과 두 개의 인증서 결정을 만듭니다. 프록시는 백엔드 인증서와 예상 이름을 검증해야 하며, 검증을 건너뛰고 HTTPS만 활성화하면 암호화가 인증되지 않은 터널로 대체됩니다.

컨테이너는 어떻게 원래 클라이언트 컨텍스트를 알게 되나요?

업스트림 TCP 연결은 프록시에서 시작되므로 프록시 연결은 원래 클라이언트 주소를 숨깁니다. 전달된 헤더는 애플리케이션에 필요한 클라이언트 IP, 원래 스킴, 호스트명 및 포트를 전달합니다.

원래 HTTPS 스킴이 없으면 애플리케이션이 HTTP 리디렉션을 생성하거나, 보안 쿠키를 잘못 표시하거나, 잘못된 콜백 URL을 만들 수 있습니다. 신뢰할 수 있는 클라이언트 주소가 없으면 로그, 속도 제한 및 접근 정책이 프록시만 식별할 수 있습니다.

프록시는 이러한 값을 일관되게 설정해야 하며, 컨테이너 프레임워크는 올바른 홉 수 또는 프록시 네트워크를 신뢰하도록 구성되어야 합니다. 헤더를 전달하고 안전하게 해석하는 것은 별개의 작업입니다.

TLS 종료가 새로 만드는 신뢰 경계는 무엇인가요?

클라이언트가 위조된 전달 헤더를 직접 보낼 수 있으므로, 신뢰할 수 있는 프록시는 백엔드가 보안 결정을 내리기 전에 전달된 헤더를 정제해야 합니다.

앱이 프록시 제공 신원을 신뢰할 때는 컨테이너에 대한 직접 접근을 차단해야 합니다. 그렇지 않으면 클라이언트가 프록시를 우회해 자체 X-Forwarded-For 또는 스킴 값을 제출하고, 애플리케이션이 신뢰하는 인그레스에서 온 것으로 가정하는 컨텍스트를 가장할 수 있습니다.

컨테이너 인그레스는 보이는 클라이언트 경로를 재작성합니다. 프록시의 개인 키를 보호하고, 관리 인터페이스를 제한하며, 의도된 경로만 노출하고, 인증서 갱신과 업스트림 상태를 모니터링하세요. 프록시는 이제 공유 보안 의존성이기 때문입니다.

자주 묻는 질문

모든 컨테이너가 자체 공개 TLS 인증서를 가져야 하나요?

TLS를 리버스 프록시가 종료할 때는 그렇지 않습니다. 프록시는 여러 호스트명에 대한 인증서를 보유하고 복호화된 요청을 별도의 내부 컨테이너로 전달할 수 있습니다.

프록시에서 컨테이너로 가는 HTTP는 항상 안전하지 않은가요?

신뢰 경계에 따라 다릅니다. 격리된 동일 호스트 네트워크는 라우팅되거나 공유된 네트워크와 노출 정도가 다릅니다. 인증서 검증이 포함된 HTTPS는 신뢰할 수 없는 구간에서 더 강력한 보호를 제공합니다.

리버스 프록시가 HTTPS를 복호화하지 않고 라우팅할 수 있나요?

네. TLS 패스스루는 SNI와 같은 핸드셰이크 정보를 사용해 라우팅할 수 있지만 백엔드가 TLS를 종료하는 경우, 프록시는 일반적인 HTTP 계층의 가시성과 필터링 기능을 잃게 됩니다.

컨테이너가 직접 외부 접근을 거부해야 하는 이유는 무엇인가요?

앱이 전달된 헤더를 신뢰할 때, 직접 접근은 클라이언트가 프록시 정제를 우회하고 위조된 신원, 스킴, 또는 호스트명 값을 제출할 수 있게 합니다.

최종 요점

리버스 프록시는 공개 암호화 엔드포인트가 되어 TLS를 처리하고 각 컨테이너와 별도로 관리되는 두 번째 연결을 생성합니다. 신뢰할 수 있는 보안은 올바른 호스트명 라우팅, 자동화되었지만 보호된 인증서 갱신, 의도적인 업스트림 암호화, 정제된 전달 헤더, 그리고 신뢰할 수 있는 프록시를 우회하는 경로 차단에 달려 있습니다.