VNet | Teleport 공식 기술 문서 한국판 by 인포그랩

VNet

VNet은 공용 주소의 프록시 서비스 아래에서 사용할 수 있는 TCP 애플리케이션에 대해 연결을 자동으로 프록시합니다. 이 가이드는 VNet을 구성하여 사용자 지정 공용 주소를 지원하는 방법을 설명합니다.

작동 방식

사용자가 teleport.example.com에서 사용할 수 있는 프록시 서비스를 통해 클러스터에 로그인했다고 가정해 보겠습니다. 해당 클러스터와 연결된 리프 클러스터가 있으며, 이 리프 클러스터는 leaf.example.com에서 사용할 수 있는 자체 프록시 서비스를 가지고 있습니다. 시작되면 VNet은 두 도메인 및 해당 하위 도메인에 대한 DNS 쿼리를 캡처합니다.

Type A 및 AAAA 쿼리는 두 클러스터에서 등록된 애플리케이션의 public_addr과 일치합니다. 일치하고 애플리케이션이 TCP 애플리케이션으로 등록되어 있으면, VNet은 해당 애플리케이션으로 프록시할 가상 IP 주소로 응답합니다. 다른 경우에는 쿼리가 OS에서 사용되는 기본 DNS 이름 서버로 전달됩니다.

VNet이 사용자 지정 public_addr이 설정된 애플리케이션으로 연결을 전달하도록 하려면, 먼저 Auth Service의 VNet 구성을 업데이트하여 일치하는 DNS 영역을 포함하고 DNS TXT 레코드를 통해 영역을 승인해야 합니다.

필수 조건

실행 중인 Teleport 클러스터 버전 16.0.0 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.
tctl 관리 도구와 tsh 클라이언트 도구.

tctl과 tsh 다운로드에 대한 지침은 설치를 방문하세요.

당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  16.2.0
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
클러스터에 연결된 TCP 애플리케이션.
귀하의 통제 하에 있는 도메인 이름.

이 가이드에서는 TCP 애플리케이션 액세스 가이드의 예제 애플리케이션을 사용하여 VNet에서 tcp-app.company.test와 함께 사용자 지정 DNS 영역으로 company.test를 사용할 수 있도록 합니다.

단계 1/4. 사용자 지정 DNS 영역 구성

사용자 지정 DNS 영역을 지정하는 vnet-config.yaml라는 파일을 만듭니다. 이 경우 애플리케이션의 public_addr는 tcp-app.company.test가 되므로 company.test를 suffix로 설정합니다:

kind: vnet_config
version: v1
metadata:
  name: vnet-config
spec:
  custom_dns_zones:
  - suffix: suffix

VNet 구성을 만듭니다:

tctl create vnet-config.yaml
vnet_config가 생성되었습니다

suffix와 public_addr 간의 관계

suffix는 애플리케이션의 public_addr 바로 위에 있는 도메인에 꼭 맞출 필요는 없습니다. 어떤 수준의 중첩도 가능합니다. 예를 들어, 애플리케이션이 tcp-app.foo.bar.qux.test 아래에 있을 수 있으며, suffix는 bar.qux.test로 설정할 수 있습니다.

단계 2/4. DNS TXT 레코드 설정

클러스터의 이름을 설정합니다:

tctl status | awk '/Cluster/ {print $2}'
teleport.example.com

VNet 구성의 suffix로 제공된 도메인에 teleport-cluster=<cluster name>이라는 DNS TXT 레코드를 설정합니다. 이는 VNet이 악의적인 클러스터 관리자가 무작위 도메인의 DNS 해상도를 가로채는 것을 방지하기 위해 필요합니다.

몇 분 정도 기다린 후 DNS 레코드 변경사항이 전파되었는지 확인합니다.

host -t TXT suffix
company.test descriptive text "teleport-cluster=teleport.example.com"

DNS TXT 및 CNAME 레코드

선택한 도메인에 CNAME 레코드가 설정되어 있으면 TXT 레코드를 추가할 수 없습니다. CNAME 레코드는 주어진 이름에 대한 유일한 레코드여야 합니다. 이 경우 가능한 경우 suffix를 바로 위의 도메인으로 설정할 수 있습니다(예: company.test 대신 internal.company.test) 또는 CNAME을 A 레코드로 변경해야 합니다.

단계 3/4. 애플리케이션의 `public_addr` 설정

애플리케이션 서비스 구성 파일 /etc/teleport.yaml에서 애플리케이션의 public_addr 필드를 설정하고 teleport 데몬을 재시작합니다.

version: v3
# …
app_service:
  # …
  apps:
  - name: "tcp-app"
    uri: tcp://localhost:5432
    public_addr: "public_addr"

단계 4/4. 연결

VNet을 시작하면 애플리케이션 클라이언트를 사용하여 고객의 사용자 지정 public_addr를 통해 애플리케이션에 연결할 수 있어야 합니다. 클러스터에 대한 변경을 하면서 VNet이 이미 실행 중이었다면 VNet을 재시작해야 할 수도 있습니다.

psql postgres://postgres@tcp-app.company.test/postgres

다음 단계

IPv4 CIDR 범위 구성

각 클러스터는 VNet이 해당 클러스터의 애플리케이션에 IP 주소를 할당할 때 사용하는 구성 가능한 IPv4 CIDR 범위를 가집니다. 루트 및 리프 클러스터는 서로 다른 범위를 사용할 수 있습니다. 기본값은 100.64.0.0/10이며, VNet 구성의 ipv4_cidr_range 필드를 설정하여 변경할 수 있습니다.

vnet-config.yaml이라는 파일을 만듭니다:

kind: vnet_config
version: v1
metadata:
  name: vnet-config
spec:
  ipv4_cidr_range: "100.64.0.0/10"

VNet 구성을 만듭니다:

tctl create vnet-config.yaml
vnet_config가 생성되었습니다

구성이 이미 존재하는 경우 tctl edit를 대신 사용할 수 있습니다:

$ tctl edit vnet_config

TUN 장치의 IPv4 주소

시작할 때 VNet은 가상 네트워크 장치에 대해 IPv4 주소를 할당해야 합니다. 주소를 선택하기 위해 VNet은 사용자가 로그인한 루트 클러스터를 임의로 선택하고 해당 클러스터에서 사용하는 범위의 주소를 선택합니다. 클러스터가 사용자 지정 범위를 사용하는 경우 사용자가 귀하의 통제 하에 없는 다른 클러스터에 로그인 한 경우, VNet이 해당 클러스터에서 제공하는 범위에서 TUN 장치의 주소를 선택할 수 있습니다.

리프 클러스터 애플리케이션 구성

사용자 지정 public_addr를 통해 리프 클러스터 애플리케이션에 액세스하려면 직접 리프 클러스터에 로그인한 상태에서 동일한 단계를 수행해야 합니다.

tsh login --proxy=leaf.example.com --user=email@example.com

제공된 도메인의 DNS TXT 레코드에는 리프 클러스터의 이름이 포함되어야 합니다. 단일 도메인은 여러 클러스터에서 사용하려는 경우 여러 TXT 레코드를 가질 수 있습니다.

VNet을 통한 웹 애플리케이션 액세스

VNet은 공식적으로 웹 애플리케이션을 지원하지 않습니다. 그러나 기술적으로 모든 웹 애플리케이션은 TCP 애플리케이션이며, 따라서 VNet을 통해 제공될 수 있습니다. 애플리케이션 서비스 구성 파일에서 애플리케이션의 uri를 http:// 대신 tcp://를 사용하도록 변경해야 합니다. 몇 가지 caveat도 있습니다:

Teleport 웹 UI는 HSTS를 사용합니다. 애플리케이션이 프록시 서비스의 하위 도메인에서 제공될 경우, 애플리케이션은 VNet이 실행 중이더라도 일반 HTTP를 통해 브라우저에서 액세스할 수 없습니다. 이 가이드에서 설명한 대로 사용자 지정 public_addr를 설정하여 우회할 수 있습니다.
애플리케이션이 HTTPS를 통해 액세스 가능해야 하는 경우, TLS 연결을 처리하고 제공되는 도메인에 대한 유효한 인증서를 반환해야 합니다.
JWT 토큰, 리디렉션 및 헤더 재작성은 TCP 애플리케이션에는 제공되지 않습니다.
Teleport는 TCP 애플리케이션의 세션 시작 및 종료를 감사 로그에 기록하지만 세션 청크는 캡처되지 않습니다.

VNet을 통해 HTTP API에 액세스할 때 위와 같은 caveat가 적용되며, 한 가지 주요 예외가 있습니다. API 클라이언트는 HSTS를 준수할 필요가 없기 때문에 API 자체는 HTTPS로 제공될 필요가 없습니다.

중요한 것은 VNet이 연결에 대해 특별한 추가 작업을 수행하지 않고, 단지 Teleport 프록시 서비스를 통해 전파된다는 것입니다. 어떤 애플리케이션 계층 프로토콜이 사용될지는 오로지 애플리케이션 자체와 그 클라이언트에 의해서만 결정됩니다.

추가 읽기

RFD 163를 읽어 VNet이 기술적으로 어떻게 작동하는지 배워보세요.

Teleport 원문 보기