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

VNet

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

작동 방식

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

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

VNet이 사용자 지정 public_addr 로 설정된 앱으로 연결을 전달하도록 하려면, 먼저 Auth 서비스의 VNet 구성을 업데이트하여 일치하는 DNS 존을 포함해야 합니다.

전제 조건

실행 중인 Teleport 클러스터 버전 16.0.0 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
tctl 관리자 도구와 tsh 클라이언트 도구.

tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하십시오.

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

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

1/3단계. 사용자 지정 DNS 존 구성

vnet-config.yaml 라는 파일을 생성하여 사용자 지정 DNS 존을 지정합니다. 우리의 경우 애플리케이션의 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/3단계. 앱의 `public_addr` 설정

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

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

3/3단계. 연결

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

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

다음 단계

IPv4 CIDR 범위 구성

각 클러스터는 해당 클러스터의 애플리케이션에 IP 주소를 할당할 때 VNet이 사용하는 구성 가능한 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

VNet을 통한 웹 애플리케이션 접근

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

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

VNet을 통해 HTTP API에 접근할 때, 위의 동일한 주의 사항이 적용되며, 단 하나의 주요 예외가 있습니다. API 클라이언트는 HSTS를 준수할 필요가 없으므로, API 자체는 HTTPS를 통해 제공될 필요가 없습니다.

중요한 점은 VNet이 Teleport Proxy Service를 통해 연결을 전달하는 것 외에는 추가 작업을 하지 않는다는 것입니다. 사용되는 애플리케이션 레이어 프로토콜은 오로지 애플리케이션과 클라이언트에 따라 다릅니다.