InfoGrab Docs

TLS 라우팅

요약

TLS 라우팅 모드에서 Teleport proxy는 모든 클라이언트 연결을 단일 TLS 포트에서 멀티플렉싱합니다. TLS 라우팅을 통해 클러스터 관리자는 프록시가 하나의 포트에서만 수신 대기하므로 네트워크 구성을 단순화할 수 있습니다.

TLS 라우팅 모드에서 Teleport proxy는 모든 클라이언트 연결을 단일 TLS 포트에서 멀티플렉싱합니다.

TLS 라우팅을 통해 클러스터 관리자는 프록시가 하나의 포트에서만 수신 대기하므로 네트워크 구성을 단순화할 수 있습니다. 모든 연결은 상호 TLS로 인증되며 사용자는 SSH와 같이 네트워크에서 차단될 수 있는 프로토콜을 터널링할 수 있습니다.

TLS 라우팅을 구현하기 위해 Teleport는 SNI(Server Name Indication)와 ALPN(Application-Level Protocol Negotiation) TLS 확장을 사용합니다.

작동 방식#

Teleport Proxy Service는 기본적으로 web_listen_addr에서 모든 클라이언트 연결을 수신 대기합니다:

proxy_service:
  web_listen_addr: "0.0.0.0:443"

SSH, 웹 브라우저, kubectl, 데이터베이스 및 역방향 터널 클라이언트를 포함한 모든 Teleport 클라이언트는 프록시의 웹 포트에 TLS 터널을 설정하고 SNI 및 ALPN TLS 확장을 사용하여 요청하는 프로토콜을 나타냅니다.

새 연결을 수락할 때 프록시는 TLS 핸드셰이크의 SNI/ALPN 값을 검사하고 적절한 백엔드 서비스로 연결을 전달합니다.

로컬 프록시#

psql 또는 mysql과 같은 클라이언트는 프로토콜별 연결 협상 단계(일명 STARTTLS)의 일부로 TLS 핸드셰이크를 구현합니다.

이러한 클라이언트와 TLS를 지원하지만 사용자 정의 ALPN 값을 설정할 수 없는 클라이언트를 지원하기 위해, Teleport의 tsh 클라이언트는 로컬 TLS 라우팅 인식 프록시를 시작하는 기능을 포함합니다.

이러한 클라이언트는 Teleport 프록시에 직접 연결하는 대신 로컬 프록시에 연결합니다. 로컬 프록시는 적절한 SNI/ALPN 값이 설정된 Teleport 프록시에 TLS 연결을 설정하고 클라이언트의 연결을 그 위로 터널링합니다.

대부분의 경우 클라이언트는 연결을 설정할 때 TLS 라우팅을 투명하게 처리합니다. 예를 들어 tsh 클라이언트는 로컬 프록시를 시작하고 자동으로 적절한 SNI/ALPN 값을 설정합니다. tsh db connect 대신 네이티브/GUI 데이터베이스 클라이언트와 같은 일부 클라이언트의 경우, 사용자가 로컬 프록시를 시작하여 이러한 클라이언트가 연결할 수 있도록 해야 합니다.

다이어그램#

TLS routing

Teleport가 지원하는 각 프로토콜이 TLS 라우팅을 구현하는 방법을 살펴보겠습니다.

SSH#

Teleport 클라이언트 tsh는 SSH 노드에 연결할 때 먼저 TLS를 통해 Teleport 프록시에 접속하고 teleport-proxy-ssh ALPN 프로토콜을 요청합니다.

tsh는 SSH 연결을 설정하기 위한 전송으로 이 TLS 연결을 사용하므로 이 경우 로컬 프록시가 시작되지 않습니다.

OpenSSH#

표준 OpenSSH 클라이언트를 지원하기 위해, Teleport는 ProxyCommand로 사용할 수 있는 tsh proxy ssh 명령을 제공합니다.

tsh ssh와 유사하게, tsh proxy ssh는 teleport-proxy-ssh ALPN 프로토콜을 사용하여 Teleport 프록시에 TLS 터널을 설정하고, ssh가 그 위로 연결합니다.

구성 방법에 대한 자세한 내용은 OpenSSH 클라이언트 가이드를 참조하십시오.

역방향 터널#

Teleport SSH, Application 및 Database Service 내의 역방향 터널 워커와 신뢰할 수 있는 클러스터에 대한 워커는 teleport-reversetunnel ALPN 프로토콜을 사용하여 클러스터의 Proxy Service에 TLS 터널을 엽니다. 그런 다음 워커는 터널을 통해 SSH를 다이얼하여 보안 연결을 설정합니다.

Kubernetes#

Kubernetes 클라이언트 kubectl은 HTTPS API와 TLS 핸드셰이크를 사용하여 API 서버와 통신합니다.

따라서 kubectl을 사용하여 사용자 정의 ALPN 프로토콜을 요청하는 것이 불가능합니다. 대신 Teleport는 SNI를 활용하고 tsh kube login 중에 kubeconfig 파일을 생성할 때 kube-teleport-proxy-alpn. 접두사가 붙은 ServerName을 설정합니다:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: ...
    server: https://proxy.example.com:443
    tls-server-name: kube-teleport-proxy-alpn.proxy.example.com
  name: example

데이터베이스#

tsh db connect 명령은 연결하는 데이터베이스에 적합한 데이터베이스 클라이언트를 실행합니다.

TLS 라우팅 모드에서 tsh는 데이터베이스 클라이언트 연결이 터널링되는 로컬 프록시를 시작합니다. 로컬 프록시는 데이터베이스에 따라 teleport-mysql과 같은 ALPN 값을 사용합니다. 프록시는 데이터베이스 세션이 종료될 때 종료됩니다.

네이티브 및 GUI 클라이언트#

네이티브 또는 그래픽 데이터베이스 클라이언트가 TLS 라우팅에서 작동하려면 Teleport 프록시에 직접 연결하는 대신 로컬 프록시에 연결해야 합니다.

Teleport는 로컬 데이터베이스 프록시를 시작하는 tsh proxy db 명령을 제공합니다:

$ tsh proxy db example-db

사용 예시는 GUI 클라이언트 가이드를 참조하십시오.

웹 UI, 앱 및 데스크톱#

Application access, desktop access 및 Teleport 웹 UI는 Teleport 프록시의 웹 리스너에 의해 제공되며 로컬 프록시나 특별한 ALPN/SNI 협상이 필요하지 않습니다. 이러한 웹 연결은 ALPN에 표준 http1.1 및 h2 프로토콜을 사용합니다.

레이어 7 로드 밸런서 또는 역방향 프록시와 함께 사용#

TLS 라우팅을 통해 Teleport Proxy Service는 레이어 7 로드 밸런서 또는 역방향 프록시 뒤에서 단일 포트를 서비스할 수 있습니다.

Layer 7 load balancer setup

레이어 7 로드 밸런서 또는 역방향 프록시는 AWS ALB에 ACM을 사용하는 것과 같이 공개 인증서로 TLS를 종료할 것으로 예상됩니다. 이는 Proxy Service가 http_keypair 또는 acme를 사용하는 웹 TLS 인증서를 필요로 하지 않는다는 것을 의미합니다.

Teleport 클라이언트는 Teleport Proxy Service가 레이어 7 로드 밸런서 또는 역방향 프록시 뒤에 있는지 자동으로 감지합니다. 이러한 경우 클라이언트는 연결 업그레이드를 시작한 다음 업그레이드된 연결을 통해 TLS 라우팅 요청을 전송합니다. Teleport 클라이언트는 로드 밸런서 및 역방향 프록시와의 호환성을 위해 네이티브 WebSocket 업그레이드를 사용합니다.

Connection upgrade

비-Teleport 클라이언트는 특수한 연결 업그레이드를 수행할 수 있는 로컬 프록시가 필요합니다.

이 구성에서 각 프로토콜이 어떻게 작동하는지 자세히 살펴보겠습니다.

SSH#

TLS 라우팅을 통해 SSH 프로토콜을 전송할 때 tsh는 연결 업그레이드를 원활하게 수행합니다. 이는 tsh ssh/scp 명령뿐만 아니라 OpenSSH 클라이언트를 사용하는 ProxyCommand를 통해 연결할 때의 tsh proxy ssh에도 적용됩니다.

Kubernetes#

tsh proxy kube 명령은 kubectl과 같은 Kubernetes 클라이언트를 위한 로컬 프록시와 임시 kubeconfig를 생성합니다. 로컬 프록시는 Kubernetes 클라이언트와의 로컬 통신을 보호하기 위해 자체 서명 인증서를 생성합니다.

Proxy Service로 요청을 전달할 때 로컬 프록시는 필요한 연결 업그레이드를 수행하고 TLS 핸드셰이크에 필요한 SNI를 설정합니다.

tsh kubectl 및 tsh kube exec 명령도 연결 업그레이드가 필요할 때 로컬 프록시를 자동으로 시작합니다.

데이터베이스#

TLS 라우팅 모드에서 tsh db connect는 데이터베이스 클라이언트 연결이 터널링되는 로컬 프록시를 시작합니다. 로컬 프록시는 연결 업그레이드와 함께 Proxy Service에 대한 연결을 시작한 다음 TLS 핸드셰이크에 데이터베이스별 ALPN 값을 사용합니다.

유사하게, 네이티브 및 GUI 클라이언트는 연결 업그레이드를 처리하는 로컬 프록시를 시작하는 tsh proxy db를 통해 연결할 수 있습니다.

웹 UI 및 데스크톱#

Teleport 웹 UI는 특별한 ALPN/SNI 값이나 연결 업그레이드 없이 표준 브라우저에서 완전히 작동합니다.

앱#

HTTP 및 TCP 앱 모두에 대해 tsh proxy app은 연결 업그레이드를 처리하고 TLS 라우팅에 적합한 ALPN 값을 설정하는 로컬 프록시를 시작할 수 있습니다.

Cloud API 접근을 위한 tsh CLI 명령(예: tsh aws)은 TLS 라우팅을 위한 연결 업그레이드를 수행하는 로컬 프록시를 투명하게 시작합니다. 네이티브 애플리케이션을 위한 로컬 프록시를 시작하려면 tsh proxy aws를 사용할 수 있습니다.

클라이언트 소스 IP#

proxy_service.trust_x_forwarded_for가 true로 설정되면, Proxy 서비스는 로드 밸런서 또는 역방향 프록시에 의해 설정된 "X-Forwarded-For" 헤더에서 클라이언트 소스 IP를 가져옵니다. 연결 업그레이드를 활용하는 TLS 라우팅 요청은 본질적으로 HTTP 요청이므로 이에도 적용됩니다.

IP 스푸핑을 방지하기 위해 요청당 "X-Forwarded-For" 헤더에 단일 IP 주소만 예상됩니다. 여러 IP 주소가 있는 모든 요청은 거부됩니다.

FAQ#

TLS를 종료하는 레이어 4 로드 밸런서 뒤에서 TLS 라우팅이 작동합니까?#

예. Teleport Proxy Service가 TLS를 종료하는 레이어 4 로드 밸런서 뒤에 있을 때, Teleport 클라이언트는 레이어 7 로드 밸런서가 있을 때와 유사하게 연결 업그레이드를 수행하여 상황을 처리합니다.

로드 밸런서는 TLS 레이어를 Teleport Proxy Service로 전달해야 합니다. 예를 들어, AWS Network Load Balancer(NLB)는 대상 그룹에 "TLS" 프로토콜을 사용해야 합니다.

역방향 프록시 뒤에서 TLS 라우팅이 작동합니까?#

TLS 라우팅은 WebSocket을 지원하는 모든 역방향 프록시와 호환됩니다.

역방향 프록시 뒤에 Teleport Proxy Service를 설정하고 다음 명령을 실행하여 연결을 테스트할 수 있습니다. 을 Proxy Service의 도메인 이름으로 지정하십시오:

$ curl --no-alpn -i -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" -H "Sec-WebSocket-Version: 13" \
  https:///webapi/connectionupgrade

업그레이드가 성공하면 서버는 빈 응답과 함께 "101 Switching Protocols"를 반환해야 합니다:

HTTP/1.1 101 Switching Protocols
Date: Thu, 27 Feb 2025 14:26:49 GMT
Connection: upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

curl: (52) Empty reply from server

tsh proxy kube를 사용하지 않고 Kubernetes 클러스터에 접근하려면 어떻게 해야 합니까?#

Teleport Proxy Service가 레이어 7 로드 밸런서 또는 역방향 프록시 뒤에 있을 때는 로컬 프록시가 필요합니다.

tsh proxy kube의 대안 중 하나는 연결 업그레이드가 필요할 때 로컬 프록시를 자동으로 시작하는 tsh kubectl을 사용하는 것입니다.

로컬 프록시를 완전히 피하려면 레이어 7 로드 밸런서 대신 TCP 모드의 레이어 4 로드 밸런서를 사용하거나, separate 포트 모드로 Teleport Proxy Service를 구성하고 레이어 7 로드 밸런서 뒤에 있지 않은 별도의 Kubernetes 포트를 사용하십시오.

다음 단계#

  • TLS 라우팅을 사용하도록 기존 클러스터를 업그레이드하는 방법은 마이그레이션 가이드를 참조하십시오.
  • TLS 라우팅 설계 문서 RFD를 읽어보십시오.

TLS 라우팅

원문 보기
요약

TLS 라우팅 모드에서 Teleport proxy는 모든 클라이언트 연결을 단일 TLS 포트에서 멀티플렉싱합니다. TLS 라우팅을 통해 클러스터 관리자는 프록시가 하나의 포트에서만 수신 대기하므로 네트워크 구성을 단순화할 수 있습니다.

TLS 라우팅 모드에서 Teleport proxy는 모든 클라이언트 연결을 단일 TLS 포트에서 멀티플렉싱합니다.

TLS 라우팅을 통해 클러스터 관리자는 프록시가 하나의 포트에서만 수신 대기하므로 네트워크 구성을 단순화할 수 있습니다. 모든 연결은 상호 TLS로 인증되며 사용자는 SSH와 같이 네트워크에서 차단될 수 있는 프로토콜을 터널링할 수 있습니다.

TLS 라우팅을 구현하기 위해 Teleport는 SNI(Server Name Indication)와 ALPN(Application-Level Protocol Negotiation) TLS 확장을 사용합니다.

작동 방식#

Teleport Proxy Service는 기본적으로 web_listen_addr에서 모든 클라이언트 연결을 수신 대기합니다:

proxy_service:
  web_listen_addr: "0.0.0.0:443"

SSH, 웹 브라우저, kubectl, 데이터베이스 및 역방향 터널 클라이언트를 포함한 모든 Teleport 클라이언트는 프록시의 웹 포트에 TLS 터널을 설정하고 SNI 및 ALPN TLS 확장을 사용하여 요청하는 프로토콜을 나타냅니다.

새 연결을 수락할 때 프록시는 TLS 핸드셰이크의 SNI/ALPN 값을 검사하고 적절한 백엔드 서비스로 연결을 전달합니다.

로컬 프록시#

psql 또는 mysql과 같은 클라이언트는 프로토콜별 연결 협상 단계(일명 STARTTLS)의 일부로 TLS 핸드셰이크를 구현합니다.

이러한 클라이언트와 TLS를 지원하지만 사용자 정의 ALPN 값을 설정할 수 없는 클라이언트를 지원하기 위해, Teleport의 tsh 클라이언트는 로컬 TLS 라우팅 인식 프록시를 시작하는 기능을 포함합니다.

이러한 클라이언트는 Teleport 프록시에 직접 연결하는 대신 로컬 프록시에 연결합니다. 로컬 프록시는 적절한 SNI/ALPN 값이 설정된 Teleport 프록시에 TLS 연결을 설정하고 클라이언트의 연결을 그 위로 터널링합니다.

대부분의 경우 클라이언트는 연결을 설정할 때 TLS 라우팅을 투명하게 처리합니다. 예를 들어 tsh 클라이언트는 로컬 프록시를 시작하고 자동으로 적절한 SNI/ALPN 값을 설정합니다. tsh db connect 대신 네이티브/GUI 데이터베이스 클라이언트와 같은 일부 클라이언트의 경우, 사용자가 로컬 프록시를 시작하여 이러한 클라이언트가 연결할 수 있도록 해야 합니다.

다이어그램#

TLS routing

Teleport가 지원하는 각 프로토콜이 TLS 라우팅을 구현하는 방법을 살펴보겠습니다.

SSH#

Teleport 클라이언트 tsh는 SSH 노드에 연결할 때 먼저 TLS를 통해 Teleport 프록시에 접속하고 teleport-proxy-ssh ALPN 프로토콜을 요청합니다.

tsh는 SSH 연결을 설정하기 위한 전송으로 이 TLS 연결을 사용하므로 이 경우 로컬 프록시가 시작되지 않습니다.

OpenSSH#

표준 OpenSSH 클라이언트를 지원하기 위해, Teleport는 ProxyCommand로 사용할 수 있는 tsh proxy ssh 명령을 제공합니다.

tsh ssh와 유사하게, tsh proxy ssh는 teleport-proxy-ssh ALPN 프로토콜을 사용하여 Teleport 프록시에 TLS 터널을 설정하고, ssh가 그 위로 연결합니다.

구성 방법에 대한 자세한 내용은 OpenSSH 클라이언트 가이드를 참조하십시오.

역방향 터널#

Teleport SSH, Application 및 Database Service 내의 역방향 터널 워커와 신뢰할 수 있는 클러스터에 대한 워커는 teleport-reversetunnel ALPN 프로토콜을 사용하여 클러스터의 Proxy Service에 TLS 터널을 엽니다. 그런 다음 워커는 터널을 통해 SSH를 다이얼하여 보안 연결을 설정합니다.

Kubernetes#

Kubernetes 클라이언트 kubectl은 HTTPS API와 TLS 핸드셰이크를 사용하여 API 서버와 통신합니다.

따라서 kubectl을 사용하여 사용자 정의 ALPN 프로토콜을 요청하는 것이 불가능합니다. 대신 Teleport는 SNI를 활용하고 tsh kube login 중에 kubeconfig 파일을 생성할 때 kube-teleport-proxy-alpn. 접두사가 붙은 ServerName을 설정합니다:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: ...
    server: https://proxy.example.com:443
    tls-server-name: kube-teleport-proxy-alpn.proxy.example.com
  name: example

데이터베이스#

tsh db connect 명령은 연결하는 데이터베이스에 적합한 데이터베이스 클라이언트를 실행합니다.

TLS 라우팅 모드에서 tsh는 데이터베이스 클라이언트 연결이 터널링되는 로컬 프록시를 시작합니다. 로컬 프록시는 데이터베이스에 따라 teleport-mysql과 같은 ALPN 값을 사용합니다. 프록시는 데이터베이스 세션이 종료될 때 종료됩니다.

네이티브 및 GUI 클라이언트#

네이티브 또는 그래픽 데이터베이스 클라이언트가 TLS 라우팅에서 작동하려면 Teleport 프록시에 직접 연결하는 대신 로컬 프록시에 연결해야 합니다.

Teleport는 로컬 데이터베이스 프록시를 시작하는 tsh proxy db 명령을 제공합니다:

$ tsh proxy db example-db

사용 예시는 GUI 클라이언트 가이드를 참조하십시오.

웹 UI, 앱 및 데스크톱#

Application access, desktop access 및 Teleport 웹 UI는 Teleport 프록시의 웹 리스너에 의해 제공되며 로컬 프록시나 특별한 ALPN/SNI 협상이 필요하지 않습니다. 이러한 웹 연결은 ALPN에 표준 http1.1 및 h2 프로토콜을 사용합니다.

레이어 7 로드 밸런서 또는 역방향 프록시와 함께 사용#

TLS 라우팅을 통해 Teleport Proxy Service는 레이어 7 로드 밸런서 또는 역방향 프록시 뒤에서 단일 포트를 서비스할 수 있습니다.

Layer 7 load balancer setup

레이어 7 로드 밸런서 또는 역방향 프록시는 AWS ALB에 ACM을 사용하는 것과 같이 공개 인증서로 TLS를 종료할 것으로 예상됩니다. 이는 Proxy Service가 http_keypair 또는 acme를 사용하는 웹 TLS 인증서를 필요로 하지 않는다는 것을 의미합니다.

Teleport 클라이언트는 Teleport Proxy Service가 레이어 7 로드 밸런서 또는 역방향 프록시 뒤에 있는지 자동으로 감지합니다. 이러한 경우 클라이언트는 연결 업그레이드를 시작한 다음 업그레이드된 연결을 통해 TLS 라우팅 요청을 전송합니다. Teleport 클라이언트는 로드 밸런서 및 역방향 프록시와의 호환성을 위해 네이티브 WebSocket 업그레이드를 사용합니다.

Connection upgrade

비-Teleport 클라이언트는 특수한 연결 업그레이드를 수행할 수 있는 로컬 프록시가 필요합니다.

이 구성에서 각 프로토콜이 어떻게 작동하는지 자세히 살펴보겠습니다.

SSH#

TLS 라우팅을 통해 SSH 프로토콜을 전송할 때 tsh는 연결 업그레이드를 원활하게 수행합니다. 이는 tsh ssh/scp 명령뿐만 아니라 OpenSSH 클라이언트를 사용하는 ProxyCommand를 통해 연결할 때의 tsh proxy ssh에도 적용됩니다.

Kubernetes#

tsh proxy kube 명령은 kubectl과 같은 Kubernetes 클라이언트를 위한 로컬 프록시와 임시 kubeconfig를 생성합니다. 로컬 프록시는 Kubernetes 클라이언트와의 로컬 통신을 보호하기 위해 자체 서명 인증서를 생성합니다.

Proxy Service로 요청을 전달할 때 로컬 프록시는 필요한 연결 업그레이드를 수행하고 TLS 핸드셰이크에 필요한 SNI를 설정합니다.

tsh kubectl 및 tsh kube exec 명령도 연결 업그레이드가 필요할 때 로컬 프록시를 자동으로 시작합니다.

데이터베이스#

TLS 라우팅 모드에서 tsh db connect는 데이터베이스 클라이언트 연결이 터널링되는 로컬 프록시를 시작합니다. 로컬 프록시는 연결 업그레이드와 함께 Proxy Service에 대한 연결을 시작한 다음 TLS 핸드셰이크에 데이터베이스별 ALPN 값을 사용합니다.

유사하게, 네이티브 및 GUI 클라이언트는 연결 업그레이드를 처리하는 로컬 프록시를 시작하는 tsh proxy db를 통해 연결할 수 있습니다.

웹 UI 및 데스크톱#

Teleport 웹 UI는 특별한 ALPN/SNI 값이나 연결 업그레이드 없이 표준 브라우저에서 완전히 작동합니다.

앱#

HTTP 및 TCP 앱 모두에 대해 tsh proxy app은 연결 업그레이드를 처리하고 TLS 라우팅에 적합한 ALPN 값을 설정하는 로컬 프록시를 시작할 수 있습니다.

Cloud API 접근을 위한 tsh CLI 명령(예: tsh aws)은 TLS 라우팅을 위한 연결 업그레이드를 수행하는 로컬 프록시를 투명하게 시작합니다. 네이티브 애플리케이션을 위한 로컬 프록시를 시작하려면 tsh proxy aws를 사용할 수 있습니다.

클라이언트 소스 IP#

proxy_service.trust_x_forwarded_for가 true로 설정되면, Proxy 서비스는 로드 밸런서 또는 역방향 프록시에 의해 설정된 "X-Forwarded-For" 헤더에서 클라이언트 소스 IP를 가져옵니다. 연결 업그레이드를 활용하는 TLS 라우팅 요청은 본질적으로 HTTP 요청이므로 이에도 적용됩니다.

IP 스푸핑을 방지하기 위해 요청당 "X-Forwarded-For" 헤더에 단일 IP 주소만 예상됩니다. 여러 IP 주소가 있는 모든 요청은 거부됩니다.

FAQ#

TLS를 종료하는 레이어 4 로드 밸런서 뒤에서 TLS 라우팅이 작동합니까?#

예. Teleport Proxy Service가 TLS를 종료하는 레이어 4 로드 밸런서 뒤에 있을 때, Teleport 클라이언트는 레이어 7 로드 밸런서가 있을 때와 유사하게 연결 업그레이드를 수행하여 상황을 처리합니다.

로드 밸런서는 TLS 레이어를 Teleport Proxy Service로 전달해야 합니다. 예를 들어, AWS Network Load Balancer(NLB)는 대상 그룹에 "TLS" 프로토콜을 사용해야 합니다.

역방향 프록시 뒤에서 TLS 라우팅이 작동합니까?#

TLS 라우팅은 WebSocket을 지원하는 모든 역방향 프록시와 호환됩니다.

역방향 프록시 뒤에 Teleport Proxy Service를 설정하고 다음 명령을 실행하여 연결을 테스트할 수 있습니다. 을 Proxy Service의 도메인 이름으로 지정하십시오:

$ curl --no-alpn -i -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" -H "Sec-WebSocket-Version: 13" \
  https:///webapi/connectionupgrade

업그레이드가 성공하면 서버는 빈 응답과 함께 "101 Switching Protocols"를 반환해야 합니다:

HTTP/1.1 101 Switching Protocols
Date: Thu, 27 Feb 2025 14:26:49 GMT
Connection: upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

curl: (52) Empty reply from server

tsh proxy kube를 사용하지 않고 Kubernetes 클러스터에 접근하려면 어떻게 해야 합니까?#

Teleport Proxy Service가 레이어 7 로드 밸런서 또는 역방향 프록시 뒤에 있을 때는 로컬 프록시가 필요합니다.

tsh proxy kube의 대안 중 하나는 연결 업그레이드가 필요할 때 로컬 프록시를 자동으로 시작하는 tsh kubectl을 사용하는 것입니다.

로컬 프록시를 완전히 피하려면 레이어 7 로드 밸런서 대신 TCP 모드의 레이어 4 로드 밸런서를 사용하거나, separate 포트 모드로 Teleport Proxy Service를 구성하고 레이어 7 로드 밸런서 뒤에 있지 않은 별도의 Kubernetes 포트를 사용하십시오.

다음 단계#

  • TLS 라우팅을 사용하도록 기존 클러스터를 업그레이드하는 방법은 마이그레이션 가이드를 참조하십시오.
  • TLS 라우팅 설계 문서 RFD를 읽어보십시오.