CML Teleport에 등록하기

이전까지 Proxmox 위에 OPNsense를 올리고,

WireGuard를 통해 외부에서도 홈랩 내부망에 접근할 수 있는 구조를 만들었습니다.

그리고 그 위에 Cisco Modeling Labs[CML]을 설치해서 네트워크 실습 환경도 구성했습니다.

처음에는 외부에서 CML에 접속할 때 WireGuard만 사용하면 충분하다고 생각했습니다. 

실제로 제 맥북에서 WireGuard를 켜면 내부망으로 들어와 CML 웹 관리 페이지에 접근할 수 있었습니다.

접속 흐름을 정리하면 다음과 같습니다.

외부 맥북
→ WireGuard
→ OPNsense
→ Proxmox 내부망
→ CML 웹 UI

이 구조는 개인이 사용할 때는 괜찮았습니다. 

하지만 CML은 혼자만 사용하는 실습 환경이 아니라, 다른 사람들과 함께 네트워크 실습을 할 수도 있는 플랫폼입니다.

이때마다 모든 사용자에게 WireGuard 설정 파일을 만들어주고, 

VPN 접속 방법을 알려주고, 내부 IP로 접근하게 만드는 것은 관리가 번거롭다고 느꼈습니다.

그래서 CML을 외부에 직접 노출하지 않으면서도, 인증된 사용자만 웹 브라우저로 접근할 수 있는 구조가 필요했습니다.

이때 선택한 것이 저희 낭만 인프라에서 운영되고 있는 Teleport였습니다.

1.Teleport란

 

여기서 Teleport가 무엇인지 간단히 정리하고 넘어가겠습니다.

Teleport는 서버, 데이터베이스, 쿠버네티스, 내부 웹 애플리케이션 같은 리소스에

안전하게 접근할 수 있도록 도와주는 접근 제어 플랫폼입니다.

쉽게 말하면 외부 사용자가 내부 서비스에 바로 접속하는 것이 아니라,

Teleport에 먼저 로그인하고 인증을 통과한 뒤 필요한 서비스에 접근하게 해주는 중간 관문입니다.

일반적인 리버스 프록시가 단순히 외부 요청을 내부 서비스로 전달하는 역할에 가깝다면,

Teleport는 여기에 사용자 인증, 권한 관리, 접근 기록 같은 기능까지 함께 제공합니다.

예를 들어 CML 웹 페이지를 외부에 직접 열어두면 누구든 해당 주소로 접근을 시도할 수 있습니다.

하지만 Teleport를 사용하면 먼저 Teleport 로그인 과정을 거쳐야 하고,

권한이 있는 사용자만 CML에 접근할 수 있습니다.

정리하면 Teleport는 내부 서비스를 외부에 직접 노출하지 않고도,

인증된 사용자만 안전하게 접근할 수 있도록 만들어주는 보안 접속 관문이라고 볼 수 있습니다.

이번 구성에서는 Teleport를 이용해

내부망에 있는 CML 웹 UI를 외부 사용자에게 안전하게 제공하는 구조를 만들었습니다.

 

 

2. 왜 Teleport를 사용했는가

CML은 네트워크 실습 플랫폼입니다.(아주비싼)

CML 안에는 라우터, 스위치, 서버, 방화벽 같은 여러 노드가 올라가고, 

사용자는 웹 UI를 통해 토폴로지를 만들고 장비를 제어합니다.

그렇기 때문에 CML 웹 관리 페이지를 공인 IP로 직접 열어두는 것은 좋은 방식이 아니라고 판단했습니다.

제가 생각한 선택지는 크게 세 가지였습니다.

1. CML을 공인 IP로 직접 오픈한다.
2. WireGuard VPN으로 내부망에 들어와서 접속한다.
3. Teleport에 CML을 등록해서 인증 기반으로 접속한다.

첫 번째 방식은 가장 단순하지만 보안상 부담이 큽니다.

두 번째 방식은 개인 사용에는 좋지만, 

여러 사용자가 접근해야 하는 상황에서는 VPN 설정을 각각 관리해야 해서 번거롭습니다.

세 번째 방식은 CML을 내부망에 그대로 두면서도, 

외부 사용자는 Teleport 로그인 후 웹 브라우저로 접근할 수 있습니다.

그래서 최종적으로 CML을 Teleport Application으로 등록하기로 했습니다.

3. 전체 구조 설계

제가 구성한 홈랩은 기본적으로 OPNsense 뒤쪽 내부망에 주요 서비스들이 위치하는 구조입니다.

기존 구조는 다음과 같습니다.

외부 인터넷
→ OPNsense
→ Proxmox 내부망
→ CML VM

CML은 Proxmox 위에 VM으로 올라가 있고, 내부망 IP를 가지고 있습니다.

예를 들어 CML 웹 관리 페이지는 다음과 같은 내부 주소로 접근할 수 있습니다.

https://192.168.20.3

이 주소는 내부망에서만 접근 가능한 주소입니다.

외부 사용자가 이 주소로 직접 접근할 수는 없습니다.

그래서 Teleport를 중간에 두어 다음과 같은 구조를 만들었습니다.

외부 사용자 브라우저
→ Teleport 로그인 페이지
→ Teleport Proxy
→ 내부망의 Teleport Agent
→ CML 내부 주소
→ CML 웹 UI

조금 더 실제 흐름에 가깝게 정리하면 다음과 같습니다.

외부 사용자
→ cml.console.nangman.cloud
→ Teleport Proxy
→ Teleport Application Service(Agent)
→ https://192.168.20.3

여기서 중요한 점은 CML이 외부에 직접 노출되는 것이 아니라는 점입니다.

외부 사용자는 CML 내부 IP로 직접 접속하지 않습니다.

사용자는 Teleport 주소로 접속하고, Teleport가 내부망의 CML로 요청을 전달합니다.

 

4. Teleport Agent VM을 따로 만든 이유

처음에는 CML 서버 자체에 Teleport를 설치해야 하나 고민했습니다.

하지만 저는 CML 자체는 실습 플랫폼으로만 두기로 했습니다.

CML은 Cisco에서 제공하는 실습 환경에 맞춰 구성된 Linux 기반 OS이기 때문에,

내부에 Teleport를 직접 설치할 경우 예상치 못한 오류가 발생하거나

CML 운영에 영향을 줄 가능성이 있다고 판단했습니다.

무엇보다

외부 접속을 중계하는 역할은 별도 VM에서 처리하는 것이 더 깔끔하다고 판단했습니다.

그래서 Proxmox 위에 Ubuntu VM을 하나 만들고, 이 VM을 Teleport Application Service 역할로 사용했습니다.

이 Ubuntu VM은 CML을 대신해서 외부 요청을 받아주는 역할을 합니다.

정확히 말하면, 

외부 사용자가 Teleport를 통해 CML에 접속하면 

Teleport Agent VM이 내부망에 있는 CML 주소로 요청을 전달합니다.

그래서 이 Ubuntu VM은 반드시 CML 내부 주소에 접근할 수 있어야 합니다.

5. Teleport Agent VM 준비

Teleport Agent용 Ubuntu VM은 CML처럼 큰 자원이 필요하지 않습니다.

CML을 직접 실행하는 VM이 아니라, CML로 요청을 전달하는 중계 역할을 하기 때문입니다.

제가 생각한 기본 구성은 다음과 같습니다.

OS: Ubuntu Server
CPU: 1Core
Memory: 1GB
Disk: 8GB 내외
Network: Proxmox 내부 LAN 브릿지

중요한 것은 리소스보다 네트워크 위치입니다.

Teleport Agent VM은 CML과 같은 내부망에 있어야 합니다.

그래야 다음 주소로 접근할 수 있습니다.

https://192.168.20.3

먼저 Ubuntu VM에서 CML에 접근이 되는지 확인했습니다.

ping check

 

 

6. Teleport 설치

이제 Ubuntu VM에 Teleport를 설치했습니다.

Teleport 클러스터에서 제공하는 설치 스크립트를 사용했습니다.

예시는 다음과 같습니다.

curl "Teleport cluster도메인 주소/scripts/install.sh" | sudo bash

여기서 뒤에 sudo bash가 붙는 이유는 설치 스크립트를 관리자 권한으로 실행하기 위해서입니다.

Teleport 바이너리를 시스템에 설치하고, 서비스로 등록하려면 관리자 권한이 필요합니다.

설치가 끝난 뒤에는 다음 명령어로 Teleport가 정상적으로 설치되었는지 확인했습니다.

which teleport
teleport version

정상적으로 설치되었다면 teleport 명령어의 경로와 버전 정보가 출력됩니다.

 

7. teleport.yaml 설정

Teleport Agent는 /etc/teleport.yaml 파일을 읽고 동작합니다.

이번 Ubuntu VM은 Auth 서버나 Proxy 서버가 아닙니다.

오직 CML을 Teleport에 Application으로 등록하는 역할만 합니다.

그래서 설정의 방향은 다음과 같습니다.

auth_service: 비활성화
proxy_service: 비활성화
ssh_service: 필요 없으면 비활성화
app_service: 활성화

예시 설정은 다음과 같습니다.

여기서 중요한 설정은 uri, public_addr, insecure_skip_verify, rewrite.redirect 입니다.

uri는 Teleport Agent가 실제로 접근할 내부 CML 주소입니다.

uri: https://192.168.20.3

public_addr는 사용자가 브라우저에서 접속하게 될 외부 주소입니다.

public_addr: cml.console.nangman.cloud

하지만 저는 프록시 쪽에서 자동으로 매핑이 되기 때문에 생략하였습니다.

insecure_skip_verify는 Teleport Agent가 CML에 접속할 때 인증서 검증을 건너뛰도록 하는 설정입니다.

insecure_skip_verify: true

CML이 자체 서명 인증서를 사용하기 때문에 이 설정이 필요했습니다.

rewrite.redirect는 CML이 내부 IP로 리다이렉트하려는 문제를 해결하기 위해 사용했습니다.

rewrite:
  redirect:
    - "192.168.20.3"

이 설정이 없으면 CML 접속 중 브라우저가 cml.console.nangman.cloud가 아니라 

192.168.20.3으로 이동하여 다른 사용자가 갑자기 접근이 불가할 수 있습니다.

 

8. Teleport 서비스 시작과 자동 실행

설정 파일을 작성한 뒤 Teleport 서비스를 시작했습니다.

sudo systemctl enable teleport
sudo systemctl restart teleport
sudo systemctl status teleport --no-pager

enable은 서버가 재부팅되어도 Teleport가 자동으로 시작되게 하는 명령어입니다.

restart는 설정 파일을 다시 읽고 Teleport 서비스를 재시작합니다.

status는 Teleport 서비스가 정상적으로 실행 중인지 확인하는 명령어입니다.

Teleport가 정상적으로 실행되면 Teleport 웹 UI에서 CML 애플리케이션이 보이기 시작합니다.

 

 

9. Teleport에서 CML 앱 확인

 

Teleport Agent가 정상적으로 등록되면 Teleport 웹 UI의 Applications 목록에서 CML 앱을 확인할 수 있습니다.

사용자는 Teleport에 로그인한 뒤 CML 앱을 클릭하면 됩니다.

접속 주소는 다음과 같습니다.

https://cml.console.nangman.cloud

여기서 사용자가 직접 CML 내부 IP에 접속하는 것이 아닙니다.

브라우저는 Teleport Proxy로 접속하고, 

Teleport Proxy가 내부망의 Teleport Agent를 통해 CML로 요청을 전달합니다.

최종적으로 요청이 안정적으로 전달되어 Teleport 웹 UI에서 cml로 정상 접근한 것을 확인할 수 있었습니다.

10. 최종 접속 흐름 정리

최종적으로 CML 접속 흐름은 다음과 같이 정리할 수 있습니다.

외부 사용자
→ cml.console.nangman.cloud 접속
→ Teleport 로그인
→ Teleport Proxy
→ 내부망 Teleport Agent
→ CML 내부 주소
→ CML 웹 UI

조금 더 간단히 표현하면 다음과 같습니다.

Browser
→ Teleport Proxy
→ Teleport Application Service
→ https://192.168.20.3

이 구조에서 CML은 여전히 내부망에만 있습니다.

외부에 직접 노출된 것은 CML이 아니라 Teleport 접속 지점입니다.

그래서 CML 관리 페이지를 공인 IP에 직접 열지 않고도, 

인증된 사용자만 안전하게 접근할 수 있는 구조를 만들 수 있었습니다.

 

마무리

이번 글에서는 Proxmox 위에 설치한 CML을 Teleport에 등록하고, 

외부에서 안전하게 접근할 수 있도록 구성한 과정을 정리했습니다.

처음에는 단순히 CML 주소를 Teleport에 등록하면 끝날 줄 알았습니다.

하지만 실제로는 내부망 주소, 도메인, 인증서, 리다이렉트, Agent 위치, DNS 방향까지 

함께 맞아야 정상적으로 동작했습니다.

이번 구성에서 가장 중요했던 포인트는 다음과 같습니다.

1. CML은 WAN에 직접 노출하지 않고 내부망에 유지
2. 별도 Ubuntu VM을 Teleport Application Service로 사용
3. Teleport Agent가 내부 CML 주소에 접근할 수 있어야 함
4. 사용자는 cml.console.nangman.cloud 같은 외부 주소로 접속
5. 실제 CML URI는 내부 주소인 https://192.168.20.3 사용

이번 작업을 하면서 가장 크게 느낀 점은, 

Teleport가 단순한 리버스 프록시가 아니라는 점이었습니다.

Teleport는 외부 사용자와 내부 애플리케이션 사이에서 인증, 접근 제어, 프록시 역할을 함께 수행합니다.

그리고 /etc/teleport.yaml은 Teleport Proxy가 직접 읽는 설정이 아니라, 

내부망에서 실행 중인 Teleport Agent가 읽는 설정입니다.

Agent가 이 설정을 읽고 Teleport 클러스터에 "나는 CML이라는 앱을 제공할 수 있다"고 등록하면,

Teleport Proxy가 사용자 요청을 해당 Agent로 전달하는 구조입니다.

결국 이번 구성의 핵심은 다음 한 줄로 정리할 수 있습니다.

CML은 내부망에 그대로 두고, 외부 접속은 Teleport 인증을 통과한 사용자만 가능하게 만든 구조

이렇게 해서 CML을 외부에 직접 노출하지 않고도, 

브라우저만으로 안전하게 접근할 수 있는 실습 환경을 구성할 수 있었습니다.