Infograb logo
네트워킹

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

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

공용 주소

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

public_addr: ["service1.example.com", "service2.example.com"]
참고

Proxy 서비스의 public_addr 는 하나만 구성해야 합니다. 여러 주소를 시도하면 클라이언트가 사용할 수 없는 첫 번째 나열된 주소로 리디렉션될 수 있습니다.

Teleport 서비스에 대한 공용 주소를 지정하는 것은 다음 사용 사례에서 유용할 수 있습니다:

  • 여러 개의 동일한 서비스(예: Proxy 서비스 인스턴스)가 로드 밸런서 뒤에 있습니다.
  • Teleport가 서비스에 추가 프린시플(예: 호스트 이름)을 가진 SSH 인증서를 발급하도록 하려는 경우입니다.

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

HTTP CONNECT 프록시

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

  • 모든 경우의 tsh
  • Teleport Proxy 서비스로 다시 연결하는 SSH 서비스 및 데이터베이스 서비스와 같은 Teleport 서비스

HTTP CONNECT 터널링을 사용하려면 Teleport를 실행할 때 HTTPS_PROXYHTTP_PROXY 환경 변수를 설정하십시오. 특정 호스트/넷마스크/포트에 접근할 때 프록시 사용을 피하려면 선택적으로 NO_PROXY 환경 변수를 설정할 수 있습니다.

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

(!/examples/systemd/teleport.service!)

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, 신뢰 설정)을 프록시를 통해 터널링합니다. 이 트래픽 중 일부(예: HTTPS는 프록시하지만 SSH는 프록시하지 않음)를 프록시하고 싶지 않다면, NO_PROXYhost:port 형식으로 HTTP_CONNECT 터널링에서 제외할 Teleport Proxy 서비스 엔드포인트 주소로 할당하십시오.

예를 들어, 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 를 접두사로 붙입니다.

참고

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

참고

Proxy 서비스는 로컬 Kubernetes 클러스터에 연결할 때도 HTTPS_PROXYHTTP_PROXY 를 존중하지만, 이 경우 작동하지 않을 수 있습니다. 이를 수정하려면 kube.teleport.cluster.localNO_PROXY 에 추가하십시오.

포트

이 섹션에서는 Teleport 인스턴스에서 열어야 할 포트에 대해 설명합니다.

프록시 서비스 포트

참고

Teleport 프록시 서비스 인스턴스의 할당된 포트 목록을 보려면 다음 명령을 사용하십시오:

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

auth_service.proxy_listener_mode 가 Teleport 구성에서 multiplex 로 설정되어 있으면, 이는 여러 서비스에 대해 단일 포트만 사용됨을 의미합니다.

TLS 라우팅이 있는 포트

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

자세한 내용은 TLS Routing 가이드를 참조하십시오.

포트하위 서비스설명
443프록시 서비스TLS 라우팅 모드에서 프록시는 웹 UI, HTTPS, Kubernetes, SSH 및 모든 데이터베이스를 단일 포트에서 처리합니다.
3021프록시 서비스프록시 피어링 모드에서 Teleport 프록시 서비스 인스턴스가 에이전트에 연결하는 데 사용되는 포트입니다.

TLS 라우팅이 없는 포트

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

포트하위 서비스설명
3021프록시 서비스프록시 피어링 모드에서 Teleport 프록시 서비스 인스턴스가 에이전트에 연결하는 데 사용되는 포트입니다.
3023모든 클라이언트클라이언트가 연결하는 SSH 포트. 프록시 서비스가 이 연결을 목적지 서비스의 포트 3022 로 전달하거나 리버스 터널 연결을 사용합니다.
3024인증 서비스방화벽 뒤에서 신뢰할 수 있는 프록시 서비스 인스턴스로 리버스 SSH 터널을 생성하는 데 사용되는 SSH 포트입니다. 프록시 서비스를 통해 연결되는 모든 Teleport 서비스(예: SSH 서비스 및 데이터베이스 서비스)는 이 포트를 사용하여 리버스 터널 연결을 형성합니다.
3080 또는 443프록시 서비스클러스터에 tsh 사용자를 인증하기 위한 HTTPS 연결. 이 연결은 웹 UI를 제공하는 데에도 사용됩니다.
3036데이터베이스 서비스MySQL 데이터베이스에 대한 트래픽입니다.
5432데이터베이스 서비스Postgres 데이터베이스에 대한 트래픽입니다.
27017데이터베이스 서비스MongoDB 인스턴스에 대한 트래픽입니다.
6379데이터베이스 서비스Redis 인스턴스에 대한 트래픽입니다.

인증 서비스 포트

포트하위 서비스설명
3025모든 Teleport 서비스클러스터 내의 다른 Teleport 서비스에 gRPC API를 제공하기 위해 인증 서비스에서 사용하는 TLS 포트입니다.

프록시 서비스 포트

클라우드 호스팅된 Teleport 배포는 각 테넌트의 프록시 서비스에 서로 다른 포트 세트를 할당합니다. 사용 가능한 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 서비스)에 대한 연결은 해당 서비스에 할당된 포트를 통해서가 아니라 프록시 서비스의 공용 웹 주소를 통해 라우팅됩니다.

이 경우 TLS 라우팅이 활성화되어 있으며, 프록시 서비스의 공용 웹 주소(ssh.public_addr )는 mytenant.teleport.sh:443 임을 볼 수 있습니다.

자세한 내용은 TLS Routing 가이드를 참조하십시오.

에이전트 포트

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

결과적으로 에이전트를 실행하는 Teleport 프로세스(예: SSH Service, Kubernetes Service 및 인프라 내 리소스를 보호하는 다른 서비스)의 경우, 에이전트를 실행하는 머신에서 공개 인터넷에 포트를 열 필요가 없습니다.

자체 호스팅된 Teleport 클러스터를 실행하는 경우, 에이전트를 Teleport Auth Service에 직접 조인할 수 있습니다. 이 설정에서는 특정 Teleport 서비스가 역터널을 통해 연결을 수락하는 대신 자신의 리스터를 열어 놓습니다. Proxy Service는 이러한 에이전트 서비스에 직접 다이얼하여 연결합니다.

아래 표는 각 Teleport 서비스가 프로시된 트래픽에 대해 여는 포트를 설명합니다:

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

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

Teleport 원문 보기