InfoGrab Docs

Teleport 네트워킹 참조

요약

Teleport 클러스터는 여러 네트워크로 구성될 수 있는 분산 시스템입니다. 이 참조 가이드는 Teleport 클러스터의 네트워킹 요구 사항을 설명합니다. Teleport 클러스터는 공용 네트워크와 사설 네트워크 모두에서 실행할 수 있는 구성 요소로 이루어진 분산 시스템입니다.

Teleport 클러스터는 여러 네트워크로 구성될 수 있는 분산 시스템입니다. 예를 들어, Teleport Enterprise (Cloud)에서 Auth Service와 Proxy Service는 Teleport 관리 인프라에서 실행되고, Teleport 사용자는 에이전트와 tbot 인스턴스를 관리합니다.

이 참조 가이드는 Teleport 클러스터의 네트워킹 요구 사항을 설명합니다.

아키텍처 개요#

Teleport 클러스터는 공용 네트워크와 사설 네트워크 모두에서 실행할 수 있는 구성 요소로 이루어진 분산 시스템입니다. Teleport는 완전히 에어갭 환경도 지원합니다.

백엔드 데이터를 관리하고 인증서를 발급하는 Teleport Auth Service는 일반적으로 사설 네트워크에서 실행됩니다. Teleport Proxy Service는 공용 인터넷에서 주소 지정 가능한 Teleport 클러스터의 유일한 구성 요소여야 하며, 최종 사용자가 접속할 수 있는 한 사설 네트워크에서도 실행할 수 있습니다.

Teleport Agent와 Machine & Workload ID Bot을 포함한 다른 모든 구성 요소는 사설 네트워크에서 실행될 것으로 예상됩니다. 사설 네트워크의 구성 요소는 Teleport Proxy Service에 연결하고 역방향 터널을 설정하며, Proxy Service는 이를 통해 구성 요소와 통신합니다.

Teleport 클러스터의 작동 방식에 대한 포괄적인 설명은 Teleport 아키텍처를 참조하세요. 용어 설명은 핵심 개념을 참조하세요.

Mermaid 다이어그램 (115줄)
소스 코드 보기
architecture-beta

%%%%%%%%%%% %% Groups % %%%%%%%%%%%

group public_net(carbon-network-public)[Public Internet] group dmz_net(carbon-network-public)[DMZ or Public Subnet] group private_net2(carbon-virtual-private-cloud)[Private Network]

%% private_net contains Teleport Agents and protected resources. group private_net(carbon-virtual-private-cloud)[Private Network] group k8s_net(logos-kubernetes)[Kubernetes Cluster] in private_net group k8s_net2(logos-kubernetes)[Kubernetes Cluster] in private_net

%%%%%%%%%%%%% %% Services % %%%%%%%%%%%%%

service user(carbon-user)[User] in public_net

%% Teleport control plane service proxy(teleport-logo-purple)[Proxy Service] in dmz_net service auth(teleport-logo-purple)[Auth Service] in private_net2

%% Agents and a protected server in the private network service agent(teleport-logo-purple)[Teleport Agents] in private_net service ssh_node(teleport-logo-purple)[Protected Server] in private_net

%% Resources that Teleport Agents protect service db(carbon-db2-database)[Databases] in private_net service windows(carbon-virtual-desktop)[Desktops] in private_net service webapp(carbon-code)[Web Apps] in private_net

%% Protected Kubernetes clusters representing two enrollment methods: %% running in the same cluster as the protected API server and using a %% kubeconfig to protect a remote cluster. %% k8s_agent runs as a Pod inside the cluster it manages %% k8s_agent_external runs outside its target cluster and connects via kubeconfig service k8s_agent(teleport-logo-purple)[Teleport Agent Pod] in k8s_net service k8s_pods(logos-kubernetes)[Kubernetes API Server] in k8s_net service k8s_agent_external(teleport-logo-purple)[External Teleport Agent with Kubeconfig] in private_net service k8s_pods2(logos-kubernetes)[Kubernetes API Server] in k8s_net2

%%%%%%%%%%%%%% %% Junctions % %%%%%%%%%%%%%%

%% p_conn: collects the external Kubernetes agent's reverse-tunnel wire %% connection routing it into the Proxy Service from below. junction p_conn in private_net

%% j_mid / j_top / j_bot form a vertical spine for connections from the Teleport %% Agents service: %% j_mid is the center junction, and connects to Desktops and branches to j_top/j_bot %% j_top sits above j_mid and connects to Databases %% j_bot sits below j_mid and connects to Web Apps junction j_mid in private_net junction j_top in private_net junction j_bot in private_net

%% j_proxy_auth_bend: L-bend that routes the User connection above the %% Proxy Service so that the Public Internet group appears at the top of %% the diagram. junction j_proxy_auth_bend

%% j_ssh_proxy / j_ssh_proxy_buf: connects Protected Server reverse-tunnel to %% the Proxy Service. j_ssh_proxy also serves as part of the connection between %% Teleport Agents and Proxy Service. junction j_ssh_proxy junction j_ssh_proxy_buf

%% j_agents_buf1 / j_agents_buf2: extend the Teleport Agents reverse tunnel %% %% vertically until it meets j_ssh_proxy at the private_net boundary. junction j_agents_buf1 junction j_agents_buf2

%%%%%%%%%%%%%%%% %% Connections % %%%%%%%%%%%%%%%%

%% Proxy Service to Auth Service proxy:L --> R:auth j_proxy_auth_bend:L -- R:user j_proxy_auth_bend:B --> T:proxy

%% Kubernetes Agent Pod to Proxy Service and Kubernetes API server k8s_agent:L --> R:proxy k8s_agent:R --> L:k8s_pods

%% External Kubernetes agent to Proxy Service and the remote Kubernetes %% cluster's API server k8s_agent_external:L -- R:p_conn k8s_agent_external:R --> L:k8s_pods2 p_conn:L --> B:proxy

%% Protected Server and Teleport Agents to the Proxy Service via reverse %% tunnel ssh_node:L -- R:j_ssh_proxy j_ssh_proxy:T -- B:j_ssh_proxy_buf j_ssh_proxy_buf:T --> B:proxy

%% Vertical spine connecting the Proxy Service to Teleport Agents in the private %% network j_ssh_proxy:B -- T:j_agents_buf1 j_agents_buf1:B -- T:j_agents_buf2 j_agents_buf2:R -- L:agent agent:R -- L:j_mid j_mid:B -- T:j_top j_mid:T -- B:j_bot

%% Agents to protected databases, desktops, and web apps j_top:R --> L:db j_mid:R --> L:windows j_bot:R --> L:webapp

공용 주소#

모든 Teleport 서비스(예: Proxy Service, Auth Service 및 에이전트)에는 각 서비스의 구성 파일에서 수정할 수 있는 선택적 public_addr 속성이 있습니다. 공용 주소는 IP 또는 DNS 이름을 사용할 수 있습니다. 값의 목록일 수도 있습니다:

public_addr: ["service1.example.com", "service2.example.com"]
Note

단일 Proxy Service public_addr만 구성해야 합니다. 여러 주소를 갖도록 시도하면 클라이언트에서 사용할 수 없는 첫 번째 나열된 주소로 리다이렉션이 발생할 수 있습니다.

Teleport 서비스의 공용 주소를 지정하면 다음과 같은 사용 사례에서 유용할 수 있습니다:

  • 로드 밸런서 뒤에 여러 동일한 서비스(예: Proxy Service 인스턴스)가 있는 경우.
  • Teleport가 추가 주체(예: 호스트 이름)로 서비스에 대한 SSH 인증서를 발급하기를 원하는 경우.

Teleport Enterprise (Cloud)에서 Teleport 에이전트 서비스는 항상 역방향 터널을 사용하여 연결하므로 에이전트의 공용 주소를 설정할 필요가 없습니다.

HTTP CONNECT 프록시#

일부 네트워크는 모든 연결을 감사하고 액세스 제어 규칙을 적용할 수 있는 프록시 서버를 통해 모든 연결을 필터링합니다. 이러한 시나리오를 위해 Teleport는 HTTP CONNECT 터널링을 지원합니다. HTTP CONNECT는 다음에 적용됩니다:

  • 모든 경우의 tsh.
  • Teleport Proxy Service로 다시 전화를 거는 SSH Service 및 Database Service와 같은 Teleport 서비스.

HTTP CONNECT 터널링을 사용하려면 Teleport를 실행할 때 HTTPS_PROXYHTTP_PROXY 환경 변수를 설정합니다. 지정된 호스트/넷마스크/포트에 액세스할 때 프록시 사용을 피하기 위해 선택적으로 NO_PROXY 환경 변수를 설정할 수도 있습니다.

기본적으로 패키지 관리자(aptyum 등)를 기반으로 한 Teleport 설치는 EnvironmentFile 필드를 사용하여 /etc/default/teleport 파일에서 환경 변수를 읽도록 teleport systemd 유닛을 구성합니다:

<div class="admonition note"><div class="admonition-title">Note</div><p>이 섹션의 내용은 원문 문서를 참조하세요. (<code>teleport.service</code>)</p></div>

HTTP CONNECT 터널링을 구성하려면 Teleport 바이너리를 실행하는 머신의 /etc/default/teleport에 이러한 환경 변수를 할당할 수 있습니다. proxy.example.com을 프록시 주소로 바꾸어 다음 예시를 사용하세요:

HTTP_PROXY=http://proxy.example.com:8080/
HTTPS_PROXY=http://proxy.example.com:8080/
NO_PROXY=localhost,127.0.0.1,192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

Teleport가 메인 클러스터로의 역방향 터널을 구축하고 설정할 때, 모든 트래픽을 프록시를 통해 전달합니다. 특히, 기본 구성을 사용하는 경우 Teleport는 포트 3024(SSH, 역방향 터널)와 3080(HTTPS, 신뢰 설정)을 프록시를 통해 터널링합니다. 이 트래픽의 일부를 프록시하지 않으려면(예: SSH는 프록시하지 않고 HTTPS만 프록시), NO_PROXYhost:port 형식으로 HTTP_CONNECT 터널링에서 제외하려는 Teleport Proxy Service 엔드포인트 주소로 할당합니다.

예를 들어, Teleport 바이너리를 실행하는 각 머신의 /etc/default/teleport 환경 파일을 다음과 유사하게 수정할 수 있습니다:

HTTP_PROXY=http://httpproxy.example.com:8080/
HTTPS_PROXY=http://httpproxy.example.com:8080/
NO_PROXY=teleportproxy.example.com:3024

HTTPS_PROXY 또는 HTTP_PROXY의 값은 scheme://[user[:password]@]host:port 형식이어야 하며 여기서 scheme은 https 또는 http입니다. 값이 host:port인 경우 Teleport는 http를 앞에 추가합니다.

Note

localhost127.0.0.1은 프록시 호스트에 유효하지 않은 값입니다. 어떤 이유로 프록시가 로컬에서 실행되는 경우 다른 DNS 이름이나 개인 IP 주소를 제공해야 합니다.

Note

Proxy Service도 로컬 Kubernetes 클러스터에 연결할 때 HTTPS_PROXYHTTP_PROXY를 존중하며, 이것이 작동하지 않을 수 있습니다. 이를 수정하려면 kube.teleport.cluster.localNO_PROXY에 추가하세요.

포트#

이 섹션은 Teleport 인스턴스에서 열어야 하는 포트를 설명합니다.

Proxy Service 포트#

Note

Teleport Proxy Service 인스턴스에 할당된 포트 목록을 얻으려면 다음 명령을 사용하세요:

$ curl https://teleport.example.com:443/webapi/ping | jq

Teleport 구성에서 auth_service.proxy_listener_modemultiplex로 설정된 경우, 이는 프록시를 통한 여러 서비스에 단일 포트만 사용된다는 의미입니다.

TLS 라우팅이 있는 포트#

TLS 라우팅은 기본적으로 활성화되어 있습니다. 이 모드에서 Teleport 서비스(예: Teleport SSH Service 또는 Kubernetes)에 대한 모든 연결은 Proxy Service의 공개 웹 주소를 통해 라우팅됩니다.

자세한 내용은 TLS 라우팅 가이드를 참조하세요.

포트 다운스트림 서비스 설명
443 Proxy Service TLS 라우팅 모드에서 프록시는 단일 포트에서 Web UI, HTTPS, Kubernetes, SSH 및 모든 데이터베이스를 포함한 모든 프로토콜을 처리합니다.
3021 Proxy Service Teleport Proxy Service 인스턴스가 프록시 피어링 모드에서 에이전트에 전화하는 데 사용되는 포트.

TLS 라우팅이 없는 포트#

일부 경우 관리자는 다른 서비스에 대해 별도의 포트를 사용하려 할 수 있습니다. 이러한 경우 구성 파일에서 별도의 리스너를 설정할 수 있습니다.

포트 다운스트림 서비스 설명
3021 Proxy Service Teleport Proxy Service 인스턴스가 프록시 피어링 모드에서 에이전트에 전화하는 데 사용되는 포트.
3023 모든 클라이언트 클라이언트가 연결하는 SSH 포트. Proxy Service는 이 연결을 대상 서비스의 3022 포트로 전달하거나 역방향 터널 연결을 사용합니다.
3024 Auth Service 방화벽 뒤 환경에서 신뢰할 수 있는 Proxy Service 인스턴스로 역방향 SSH 터널을 만드는 데 사용되는 SSH 포트. Proxy Service를 통해 연결하는 모든 Teleport 서비스(예: SSH Service 및 Database Service)는 이 포트를 사용하여 역방향 터널 연결을 형성합니다.
3080 또는 443 Proxy Service 클러스터에 tsh 사용자를 인증하는 HTTPS 연결. 동일한 연결이 Web UI를 제공하는 데 사용됩니다.
3036 Database Service MySQL 데이터베이스로의 트래픽.
5432 Database Service Postgres 데이터베이스로의 트래픽.
27017 Database Service MongoDB 인스턴스로의 트래픽.
6379 Database Service Redis 인스턴스로의 트래픽.

Auth Service 포트#

포트 다운스트림 서비스 설명
3025 모든 Teleport 서비스 Auth Service가 클러스터의 다른 Teleport 서비스에 gRPC API를 제공하는 데 사용하는 TLS 포트.

Proxy Service 포트#

클라우드 호스팅 Teleport 배포는 각 테넌트의 Proxy Service에 다른 포트 세트를 할당합니다. Teleport 테넌트에서 사용 가능한 포트를 확인하려면 example.teleport.sh를 테넌트 도메인으로 바꾸어 다음과 유사한 명령을 실행하세요:

$ curl https://example.teleport.sh/webapi/ping | jq '.proxy'

출력은 테넌트에 할당된 고유 포트를 포함하여 다음과 유사해야 합니다:

{
  "kube": {
    "enabled": true,
    "listen_addr": "0.0.0.0:3080"
  },
  "ssh": {
    "listen_addr": "0.0.0.0:3080",
    "tunnel_listen_addr": "0.0.0.0:3080",
    "web_listen_addr": "0.0.0.0:3080",
    "public_addr": "example.teleport.sh:443",
    "dial_timeout": 30000000000
  },
  "db": {
    "postgres_listen_addr": "0.0.0.0:3080",
    "mysql_listen_addr": "0.0.0.0:3080"
  },
  "tls_routing_enabled": true
}

이 출력은 테넌트에 대해 TLS 라우팅이 활성화되어 있는지 여부도 나타냅니다. TLS 라우팅이 활성화된 경우 Teleport 서비스(예: Teleport SSH Service)에 대한 연결은 해당 서비스에 할당된 포트가 아닌 Proxy Service의 공개 웹 주소를 통해 라우팅됩니다.

이 경우 TLS 라우팅이 활성화되어 있고 Proxy Service의 공개 웹 주소(ssh.public_addr)가 mytenant.teleport.sh:443임을 알 수 있습니다.

자세한 내용은 TLS 라우팅 가이드를 참조하세요.

에이전트 포트#

Teleport 에이전트는 역방향 터널을 설정하기 위해 Teleport Proxy Service에 연결합니다. 클라이언트 트래픽은 Proxy Service를 통해 에이전트로 흐르고, 에이전트는 인프라의 리소스로 트래픽을 전달합니다.

따라서 SSH Service, Kubernetes Service 및 인프라의 리소스를 보호하는 기타 서비스 인스턴스와 같이 에이전트를 실행하는 Teleport 프로세스의 경우, 에이전트를 실행하는 머신의 포트를 공개 인터넷에 열 필요가 없습니다.

에이전트에 대한 직접 연결#

자체 호스팅 Teleport 클러스터를 실행하는 경우 에이전트를 Teleport Auth Service에 직접 참가할 수 있습니다. 이 설정에서 특정 Teleport 서비스는 역방향 터널을 통한 연결을 수락하는 대신 자체 리스너를 엽니다. Proxy Service는 이러한 에이전트 서비스에 직접 전화를 걸어 연결합니다.

아래 표는 각 Teleport 서비스가 프록시된 트래픽을 위해 열어두는 포트를 설명합니다:

포트 서비스 트래픽 유형
3022 SSH Service 수신 SSH 연결.
3026 Kubernetes Service Kubernetes API 서버로의 HTTPS 트래픽.
3028 Windows Desktop Service Teleport 클라이언트에서의 Teleport Desktop Protocol 트래픽.

등록된 애플리케이션과 데스크톱은 Teleport Proxy Service를 통해서만 액세스할 수 있습니다. Teleport Application Service와 Teleport Database Service는 Teleport Proxy Service를 통한 역방향 터널 연결을 사용하며 포트를 직접 노출할 수 없습니다.

Warning

직접 Auth Service 참가는 Teleport SSH Service, Kubernetes Service 및 Windows Desktop Service를 실행하는 Teleport 에이전트에 대해서만 지원됩니다. 애플리케이션, 데이터베이스를 등록하고 다른 검색 기반 기능에 Auth Service 참가를 사용하는 것은 지원되지 않습니다.

Teleport 네트워킹 참조

원문 보기
요약

Teleport 클러스터는 여러 네트워크로 구성될 수 있는 분산 시스템입니다. 이 참조 가이드는 Teleport 클러스터의 네트워킹 요구 사항을 설명합니다. Teleport 클러스터는 공용 네트워크와 사설 네트워크 모두에서 실행할 수 있는 구성 요소로 이루어진 분산 시스템입니다.

Teleport 클러스터는 여러 네트워크로 구성될 수 있는 분산 시스템입니다. 예를 들어, Teleport Enterprise (Cloud)에서 Auth Service와 Proxy Service는 Teleport 관리 인프라에서 실행되고, Teleport 사용자는 에이전트와 tbot 인스턴스를 관리합니다.

이 참조 가이드는 Teleport 클러스터의 네트워킹 요구 사항을 설명합니다.

아키텍처 개요#

Teleport 클러스터는 공용 네트워크와 사설 네트워크 모두에서 실행할 수 있는 구성 요소로 이루어진 분산 시스템입니다. Teleport는 완전히 에어갭 환경도 지원합니다.

백엔드 데이터를 관리하고 인증서를 발급하는 Teleport Auth Service는 일반적으로 사설 네트워크에서 실행됩니다. Teleport Proxy Service는 공용 인터넷에서 주소 지정 가능한 Teleport 클러스터의 유일한 구성 요소여야 하며, 최종 사용자가 접속할 수 있는 한 사설 네트워크에서도 실행할 수 있습니다.

Teleport Agent와 Machine & Workload ID Bot을 포함한 다른 모든 구성 요소는 사설 네트워크에서 실행될 것으로 예상됩니다. 사설 네트워크의 구성 요소는 Teleport Proxy Service에 연결하고 역방향 터널을 설정하며, Proxy Service는 이를 통해 구성 요소와 통신합니다.

Teleport 클러스터의 작동 방식에 대한 포괄적인 설명은 Teleport 아키텍처를 참조하세요. 용어 설명은 핵심 개념을 참조하세요.

Mermaid 다이어그램 (115줄)
소스 코드 보기
architecture-beta

%%%%%%%%%%% %% Groups % %%%%%%%%%%%

group public_net(carbon-network-public)[Public Internet] group dmz_net(carbon-network-public)[DMZ or Public Subnet] group private_net2(carbon-virtual-private-cloud)[Private Network]

%% private_net contains Teleport Agents and protected resources. group private_net(carbon-virtual-private-cloud)[Private Network] group k8s_net(logos-kubernetes)[Kubernetes Cluster] in private_net group k8s_net2(logos-kubernetes)[Kubernetes Cluster] in private_net

%%%%%%%%%%%%% %% Services % %%%%%%%%%%%%%

service user(carbon-user)[User] in public_net

%% Teleport control plane service proxy(teleport-logo-purple)[Proxy Service] in dmz_net service auth(teleport-logo-purple)[Auth Service] in private_net2

%% Agents and a protected server in the private network service agent(teleport-logo-purple)[Teleport Agents] in private_net service ssh_node(teleport-logo-purple)[Protected Server] in private_net

%% Resources that Teleport Agents protect service db(carbon-db2-database)[Databases] in private_net service windows(carbon-virtual-desktop)[Desktops] in private_net service webapp(carbon-code)[Web Apps] in private_net

%% Protected Kubernetes clusters representing two enrollment methods: %% running in the same cluster as the protected API server and using a %% kubeconfig to protect a remote cluster. %% k8s_agent runs as a Pod inside the cluster it manages %% k8s_agent_external runs outside its target cluster and connects via kubeconfig service k8s_agent(teleport-logo-purple)[Teleport Agent Pod] in k8s_net service k8s_pods(logos-kubernetes)[Kubernetes API Server] in k8s_net service k8s_agent_external(teleport-logo-purple)[External Teleport Agent with Kubeconfig] in private_net service k8s_pods2(logos-kubernetes)[Kubernetes API Server] in k8s_net2

%%%%%%%%%%%%%% %% Junctions % %%%%%%%%%%%%%%

%% p_conn: collects the external Kubernetes agent's reverse-tunnel wire %% connection routing it into the Proxy Service from below. junction p_conn in private_net

%% j_mid / j_top / j_bot form a vertical spine for connections from the Teleport %% Agents service: %% j_mid is the center junction, and connects to Desktops and branches to j_top/j_bot %% j_top sits above j_mid and connects to Databases %% j_bot sits below j_mid and connects to Web Apps junction j_mid in private_net junction j_top in private_net junction j_bot in private_net

%% j_proxy_auth_bend: L-bend that routes the User connection above the %% Proxy Service so that the Public Internet group appears at the top of %% the diagram. junction j_proxy_auth_bend

%% j_ssh_proxy / j_ssh_proxy_buf: connects Protected Server reverse-tunnel to %% the Proxy Service. j_ssh_proxy also serves as part of the connection between %% Teleport Agents and Proxy Service. junction j_ssh_proxy junction j_ssh_proxy_buf

%% j_agents_buf1 / j_agents_buf2: extend the Teleport Agents reverse tunnel %% %% vertically until it meets j_ssh_proxy at the private_net boundary. junction j_agents_buf1 junction j_agents_buf2

%%%%%%%%%%%%%%%% %% Connections % %%%%%%%%%%%%%%%%

%% Proxy Service to Auth Service proxy:L --> R:auth j_proxy_auth_bend:L -- R:user j_proxy_auth_bend:B --> T:proxy

%% Kubernetes Agent Pod to Proxy Service and Kubernetes API server k8s_agent:L --> R:proxy k8s_agent:R --> L:k8s_pods

%% External Kubernetes agent to Proxy Service and the remote Kubernetes %% cluster's API server k8s_agent_external:L -- R:p_conn k8s_agent_external:R --> L:k8s_pods2 p_conn:L --> B:proxy

%% Protected Server and Teleport Agents to the Proxy Service via reverse %% tunnel ssh_node:L -- R:j_ssh_proxy j_ssh_proxy:T -- B:j_ssh_proxy_buf j_ssh_proxy_buf:T --> B:proxy

%% Vertical spine connecting the Proxy Service to Teleport Agents in the private %% network j_ssh_proxy:B -- T:j_agents_buf1 j_agents_buf1:B -- T:j_agents_buf2 j_agents_buf2:R -- L:agent agent:R -- L:j_mid j_mid:B -- T:j_top j_mid:T -- B:j_bot

%% Agents to protected databases, desktops, and web apps j_top:R --> L:db j_mid:R --> L:windows j_bot:R --> L:webapp

공용 주소#

모든 Teleport 서비스(예: Proxy Service, Auth Service 및 에이전트)에는 각 서비스의 구성 파일에서 수정할 수 있는 선택적 public_addr 속성이 있습니다. 공용 주소는 IP 또는 DNS 이름을 사용할 수 있습니다. 값의 목록일 수도 있습니다:

public_addr: ["service1.example.com", "service2.example.com"]
Note

단일 Proxy Service public_addr만 구성해야 합니다. 여러 주소를 갖도록 시도하면 클라이언트에서 사용할 수 없는 첫 번째 나열된 주소로 리다이렉션이 발생할 수 있습니다.

Teleport 서비스의 공용 주소를 지정하면 다음과 같은 사용 사례에서 유용할 수 있습니다:

  • 로드 밸런서 뒤에 여러 동일한 서비스(예: Proxy Service 인스턴스)가 있는 경우.
  • Teleport가 추가 주체(예: 호스트 이름)로 서비스에 대한 SSH 인증서를 발급하기를 원하는 경우.

Teleport Enterprise (Cloud)에서 Teleport 에이전트 서비스는 항상 역방향 터널을 사용하여 연결하므로 에이전트의 공용 주소를 설정할 필요가 없습니다.

HTTP CONNECT 프록시#

일부 네트워크는 모든 연결을 감사하고 액세스 제어 규칙을 적용할 수 있는 프록시 서버를 통해 모든 연결을 필터링합니다. 이러한 시나리오를 위해 Teleport는 HTTP CONNECT 터널링을 지원합니다. HTTP CONNECT는 다음에 적용됩니다:

  • 모든 경우의 tsh.
  • Teleport Proxy Service로 다시 전화를 거는 SSH Service 및 Database Service와 같은 Teleport 서비스.

HTTP CONNECT 터널링을 사용하려면 Teleport를 실행할 때 HTTPS_PROXYHTTP_PROXY 환경 변수를 설정합니다. 지정된 호스트/넷마스크/포트에 액세스할 때 프록시 사용을 피하기 위해 선택적으로 NO_PROXY 환경 변수를 설정할 수도 있습니다.

기본적으로 패키지 관리자(aptyum 등)를 기반으로 한 Teleport 설치는 EnvironmentFile 필드를 사용하여 /etc/default/teleport 파일에서 환경 변수를 읽도록 teleport systemd 유닛을 구성합니다:

<div class="admonition note"><div class="admonition-title">Note</div><p>이 섹션의 내용은 원문 문서를 참조하세요. (<code>teleport.service</code>)</p></div>

HTTP CONNECT 터널링을 구성하려면 Teleport 바이너리를 실행하는 머신의 /etc/default/teleport에 이러한 환경 변수를 할당할 수 있습니다. proxy.example.com을 프록시 주소로 바꾸어 다음 예시를 사용하세요:

HTTP_PROXY=http://proxy.example.com:8080/
HTTPS_PROXY=http://proxy.example.com:8080/
NO_PROXY=localhost,127.0.0.1,192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

Teleport가 메인 클러스터로의 역방향 터널을 구축하고 설정할 때, 모든 트래픽을 프록시를 통해 전달합니다. 특히, 기본 구성을 사용하는 경우 Teleport는 포트 3024(SSH, 역방향 터널)와 3080(HTTPS, 신뢰 설정)을 프록시를 통해 터널링합니다. 이 트래픽의 일부를 프록시하지 않으려면(예: SSH는 프록시하지 않고 HTTPS만 프록시), NO_PROXYhost:port 형식으로 HTTP_CONNECT 터널링에서 제외하려는 Teleport Proxy Service 엔드포인트 주소로 할당합니다.

예를 들어, Teleport 바이너리를 실행하는 각 머신의 /etc/default/teleport 환경 파일을 다음과 유사하게 수정할 수 있습니다:

HTTP_PROXY=http://httpproxy.example.com:8080/
HTTPS_PROXY=http://httpproxy.example.com:8080/
NO_PROXY=teleportproxy.example.com:3024

HTTPS_PROXY 또는 HTTP_PROXY의 값은 scheme://[user[:password]@]host:port 형식이어야 하며 여기서 scheme은 https 또는 http입니다. 값이 host:port인 경우 Teleport는 http를 앞에 추가합니다.

Note

localhost127.0.0.1은 프록시 호스트에 유효하지 않은 값입니다. 어떤 이유로 프록시가 로컬에서 실행되는 경우 다른 DNS 이름이나 개인 IP 주소를 제공해야 합니다.

Note

Proxy Service도 로컬 Kubernetes 클러스터에 연결할 때 HTTPS_PROXYHTTP_PROXY를 존중하며, 이것이 작동하지 않을 수 있습니다. 이를 수정하려면 kube.teleport.cluster.localNO_PROXY에 추가하세요.

포트#

이 섹션은 Teleport 인스턴스에서 열어야 하는 포트를 설명합니다.

Proxy Service 포트#

Note

Teleport Proxy Service 인스턴스에 할당된 포트 목록을 얻으려면 다음 명령을 사용하세요:

$ curl https://teleport.example.com:443/webapi/ping | jq

Teleport 구성에서 auth_service.proxy_listener_modemultiplex로 설정된 경우, 이는 프록시를 통한 여러 서비스에 단일 포트만 사용된다는 의미입니다.

TLS 라우팅이 있는 포트#

TLS 라우팅은 기본적으로 활성화되어 있습니다. 이 모드에서 Teleport 서비스(예: Teleport SSH Service 또는 Kubernetes)에 대한 모든 연결은 Proxy Service의 공개 웹 주소를 통해 라우팅됩니다.

자세한 내용은 TLS 라우팅 가이드를 참조하세요.

포트 다운스트림 서비스 설명
443 Proxy Service TLS 라우팅 모드에서 프록시는 단일 포트에서 Web UI, HTTPS, Kubernetes, SSH 및 모든 데이터베이스를 포함한 모든 프로토콜을 처리합니다.
3021 Proxy Service Teleport Proxy Service 인스턴스가 프록시 피어링 모드에서 에이전트에 전화하는 데 사용되는 포트.

TLS 라우팅이 없는 포트#

일부 경우 관리자는 다른 서비스에 대해 별도의 포트를 사용하려 할 수 있습니다. 이러한 경우 구성 파일에서 별도의 리스너를 설정할 수 있습니다.

포트 다운스트림 서비스 설명
3021 Proxy Service Teleport Proxy Service 인스턴스가 프록시 피어링 모드에서 에이전트에 전화하는 데 사용되는 포트.
3023 모든 클라이언트 클라이언트가 연결하는 SSH 포트. Proxy Service는 이 연결을 대상 서비스의 3022 포트로 전달하거나 역방향 터널 연결을 사용합니다.
3024 Auth Service 방화벽 뒤 환경에서 신뢰할 수 있는 Proxy Service 인스턴스로 역방향 SSH 터널을 만드는 데 사용되는 SSH 포트. Proxy Service를 통해 연결하는 모든 Teleport 서비스(예: SSH Service 및 Database Service)는 이 포트를 사용하여 역방향 터널 연결을 형성합니다.
3080 또는 443 Proxy Service 클러스터에 tsh 사용자를 인증하는 HTTPS 연결. 동일한 연결이 Web UI를 제공하는 데 사용됩니다.
3036 Database Service MySQL 데이터베이스로의 트래픽.
5432 Database Service Postgres 데이터베이스로의 트래픽.
27017 Database Service MongoDB 인스턴스로의 트래픽.
6379 Database Service Redis 인스턴스로의 트래픽.

Auth Service 포트#

포트 다운스트림 서비스 설명
3025 모든 Teleport 서비스 Auth Service가 클러스터의 다른 Teleport 서비스에 gRPC API를 제공하는 데 사용하는 TLS 포트.

Proxy Service 포트#

클라우드 호스팅 Teleport 배포는 각 테넌트의 Proxy Service에 다른 포트 세트를 할당합니다. Teleport 테넌트에서 사용 가능한 포트를 확인하려면 example.teleport.sh를 테넌트 도메인으로 바꾸어 다음과 유사한 명령을 실행하세요:

$ curl https://example.teleport.sh/webapi/ping | jq '.proxy'

출력은 테넌트에 할당된 고유 포트를 포함하여 다음과 유사해야 합니다:

{
  "kube": {
    "enabled": true,
    "listen_addr": "0.0.0.0:3080"
  },
  "ssh": {
    "listen_addr": "0.0.0.0:3080",
    "tunnel_listen_addr": "0.0.0.0:3080",
    "web_listen_addr": "0.0.0.0:3080",
    "public_addr": "example.teleport.sh:443",
    "dial_timeout": 30000000000
  },
  "db": {
    "postgres_listen_addr": "0.0.0.0:3080",
    "mysql_listen_addr": "0.0.0.0:3080"
  },
  "tls_routing_enabled": true
}

이 출력은 테넌트에 대해 TLS 라우팅이 활성화되어 있는지 여부도 나타냅니다. TLS 라우팅이 활성화된 경우 Teleport 서비스(예: Teleport SSH Service)에 대한 연결은 해당 서비스에 할당된 포트가 아닌 Proxy Service의 공개 웹 주소를 통해 라우팅됩니다.

이 경우 TLS 라우팅이 활성화되어 있고 Proxy Service의 공개 웹 주소(ssh.public_addr)가 mytenant.teleport.sh:443임을 알 수 있습니다.

자세한 내용은 TLS 라우팅 가이드를 참조하세요.

에이전트 포트#

Teleport 에이전트는 역방향 터널을 설정하기 위해 Teleport Proxy Service에 연결합니다. 클라이언트 트래픽은 Proxy Service를 통해 에이전트로 흐르고, 에이전트는 인프라의 리소스로 트래픽을 전달합니다.

따라서 SSH Service, Kubernetes Service 및 인프라의 리소스를 보호하는 기타 서비스 인스턴스와 같이 에이전트를 실행하는 Teleport 프로세스의 경우, 에이전트를 실행하는 머신의 포트를 공개 인터넷에 열 필요가 없습니다.

에이전트에 대한 직접 연결#

자체 호스팅 Teleport 클러스터를 실행하는 경우 에이전트를 Teleport Auth Service에 직접 참가할 수 있습니다. 이 설정에서 특정 Teleport 서비스는 역방향 터널을 통한 연결을 수락하는 대신 자체 리스너를 엽니다. Proxy Service는 이러한 에이전트 서비스에 직접 전화를 걸어 연결합니다.

아래 표는 각 Teleport 서비스가 프록시된 트래픽을 위해 열어두는 포트를 설명합니다:

포트 서비스 트래픽 유형
3022 SSH Service 수신 SSH 연결.
3026 Kubernetes Service Kubernetes API 서버로의 HTTPS 트래픽.
3028 Windows Desktop Service Teleport 클라이언트에서의 Teleport Desktop Protocol 트래픽.

등록된 애플리케이션과 데스크톱은 Teleport Proxy Service를 통해서만 액세스할 수 있습니다. Teleport Application Service와 Teleport Database Service는 Teleport Proxy Service를 통한 역방향 터널 연결을 사용하며 포트를 직접 노출할 수 없습니다.

Warning

직접 Auth Service 참가는 Teleport SSH Service, Kubernetes Service 및 Windows Desktop Service를 실행하는 Teleport 에이전트에 대해서만 지원됩니다. 애플리케이션, 데이터베이스를 등록하고 다른 검색 기반 기능에 Auth Service 참가를 사용하는 것은 지원되지 않습니다.