Infograb logo
TLS 라우팅

TLS 라우팅 모드에서는 Teleport 프록시가 모든 클라이언트 연결을 단일 TLS 포트에서 다중화합니다.

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

TLS 라우팅을 구현하기 위해 Teleport는 SNI (서버 이름 표시)와 ALPN (애플리케이션 레벨 프로토콜 협상) TLS 확장을 사용합니다.

레이어 7 (HTTP/HTTPS) 로드 밸런서와 리버스 프록시 뒤에서의 TLS 라우팅 지원은 Teleport 13.0 버전부터 가능합니다.

작동 방식

Teleport 프록시 서비스는 기본적으로 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 대신 기본/native GUI 데이터베이스 클라이언트의 경우 사용자가 로컬 프록시를 시작해야 하며, 이렇게 하면 이러한 클라이언트가 연결할 수 있습니다.

다이어그램

TLS 라우팅

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

SSH

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

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

OpenSSH

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

tsh ssh와 마찬가지로 tsh proxy sshteleport-proxy-ssh ALPN 프로토콜을 사용하여 Teleport 프록시로 TLS 터널을 설정하며, 이후 ssh가 그 위에서 연결합니다.

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

리버스 터널

리버스 터널 작업자는 Teleport SSH, 애플리케이션 및 데이터베이스 서비스 내에서, 또한 신뢰할 수 있는 클러스터를 위해 TLS 터널을 클러스터의 프록시 서비스로 열며 teleport-reversetunnel ALPN 프로토콜을 사용합니다. 작업자는 터널을 통해 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 클라이언트

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

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

tsh proxy db example-db

사용 예에 대한 가이드는 GUI 클라이언트 를 참조하세요.

웹 UI, 애플리케이션 및 데스크탑

애플리케이션 액세스, 데스크탑 액세스 및 Teleport 웹 UI는 Teleport 프록시의 웹 리스너에 의해 제공되며 로컬 프록시나 특별한 ALPN/SNI 협상이 필요하지 않습니다. 이 웹 연결은 ALPN을 위해 표준 http1.1h2 프로토콜을 사용합니다.

레이어 7 로드 밸런서 또는 리버스 프록시와 작업하기

13.0 버전부터 TLS 라우팅을 사용하여 Teleport 프록시 서비스가 레이어 7 로드 밸런서나 리버스 프록시 뒤에서 단일 포트를 제공할 수 있습니다.

레이어 7 로드 밸런서 또는 리버스 프록시가 공개 인증서로 TLS를 종료할 것으로 예상됩니다. 즉, 프록시 서비스는 http_keypair 또는 acme를 사용하여 웹 TLS 인증서를 필요로 하지 않습니다.

Teleport 클라이언트는 Teleport 프록시 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에 있는지를 자동으로 감지합니다. 이러한 경우 클라이언트는 연결 업그레이드를 시작한 후 업그레이드된 연결을 통해 TLS 라우팅 요청을 보냅니다.

초기 클라이언트 구현에서는 Teleport 맞춤형 업그레이드 'alpn'을 보내며, 이는 WebSockets와 동일한 연결 업그레이드 원칙을 사용합니다. 15.1 버전부터 Teleport 클라이언트는 더 많은 로드 밸런서와 리버스 프록시와의 호환성을 확대하기 위해 네이티브 WebSocket 업그레이드를 보냅니다.

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

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

SSH

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

Kubernetes

tsh proxy kube 명령은 Kubernetes 클라이언트와의 로컬 프록시 및 임시 kubeconfig를 생성합니다. 로컬 프록시는 Kubernetes 클라이언트와의 로컬 통신을 안전하게 하기 위해 자체 서명된 인증서를 생성합니다.

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

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

데이터베이스

TLS 라우팅 모드에서 tsh db connect는 데이터베이스 클라이언트 연결이 터널링되는 로컬 프록시를 시작합니다. 로컬 프록시는 연결 업그레이드 후 프록시 서비스에 연결을 시작하고 TLS 핸드셰이크에서 데이터베이스 전용 ALPN 값을 사용합니다.

마찬가지로, 네이티브 및 GUI 클라이언트는 tsh proxy db를 통해 연결할 수 있으며, 이것이 로컬 프록시를 시작하여 연결 업그레이드를 처리합니다.

웹 UI 및 데스크탑

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

애플리케이션

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

Cloud API에 액세스하는 위한 tsh CLI 명령, 예를 들어 tsh aws는 연결 업그레이드를 수행하는 로컬 프록시를 투명하게 시작합니다. 네이티브 애플리케이션을 위한 로컬 프록시를 시작하려면 tsh proxy aws를 사용하십시오.

클라이언트 소스 IP

proxy_service.trust_x_forwarded_fortrue로 설정되면 프록시 서비스는 로드 밸런서나 리버스 프록시가 설정한 "X-Forwarded-For" 헤더에서 클라이언트 소스 IP를 가져옵니다. 이는 연결 업그레이드를 사용하는 TLS 라우팅 요청에도 적용됩니다. 이는 본질적으로 HTTP 요청이기 때문입니다.

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

FAQ

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

네, Teleport 프록시 서비스가 TLS를 종료하는 레이어 4 로드 밸런서 뒤에 있을 때, Teleport 클라이언트는 레이어 7 로드 밸런서가 존재하는 경우와 유사하게 상황을 처리하며 연결 업그레이드를 수행합니다.

로드 밸런서는 반드시 TLS 계층을 Teleport 프록시 서비스로 전달해야 합니다. 예를 들어, AWS 네트워크 로드 밸런서(NLB)는 대상 그룹에 대해 "TLS" 프로토콜을 사용해야 합니다.

TLS 라우팅이 내 리버스 프록시 뒤에서 작동합니까?

15.1 버전부터 TLS 라우팅은 WebSocket을 지원하는 모든 리버스 프록시와 호환됩니다.

15.1 이전의 Telport 버전의 경우, 리버스 프록시는 사용자 정의 연결 업그레이드 와 장기 연결을 지원해야 합니다.

리버스 프록시 뒤에 Teleport 프록시 서비스를 설정하고 연결을 테스트하기 위해 다음 명령을 실행할 수 있습니다:

curl -v https://teleport.example.com/webapi/connectionupgrade
-H "Connection: Upgrade" -H "Upgrade: alpn-ping" --no-alpn

성공적인 업그레이드를 위해 서버는 요청된 업그레이드 유형과 함께 "101 Switching Protocols"를 반환해야 하며, curl 명령을 실행할 때 약 30초 후에 이진 출력도 얻어야 합니다:

< HTTP/1.1 101 Switching Protocols  
< Connection: Upgrade  
< Upgrade: alpn-ping  
< X-Teleport-Upgrade: alpn-ping  
<  
Warning: Binary output can mess up your terminal.  

tsh proxy kube를 사용하지 않고 Kubernetes 클러스터에 어떻게 액세스할 수 있습니까?

Teleport 프록시 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에 있을 때 로컬 프록시가 필요합니다.

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

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

다음 단계

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