나는 느린 리눅스 원격 데스크톱을 버리고 이 브라우저 기반 설정을 사용했다
Windows 원격 데스크톱에서 Linux로 전환할 때마다 항상 약간 충격을 받습니다. 이는 원격 데스크톱 프로토콜(RDP)이 Microsoft에 기본적으로 내장되어 있기 때문이지만, Linux에서는 더 즉흥적으로 느껴지기 때문입니다. Linux 서버에 원격 접속하는 것은 종종 세션 충돌, 느린 크기 조정, 지연된 성능을 의미했습니다. 또한 Xrdp 서비스가 불가피하게 충돌할 때 다시 시작하기 위해 SSH 세션을 계속 열어 두어야 했습니다.
저는 오픈 소스 원격 접속 게이트웨이인 Apache Guacamole을 사용해보기로 결정했지만, 보다 구체적으로 말하면, 기존의 Linux 서버들을 추가하고 접근할 수 있는 새로운 서버에 독립적으로 설치하는 방법을 선택했습니다. 제가 Guacamole을 선택한 이유는 HTTPS를 통해 브라우저에서 RDP 세션을 제어할 수 있었기 때문입니다. 또한 이 솔루션은 모든 원격 Linux 사용자가 적어도 몇 번은 겪어본 RDP 성능 및 안정성 문제 대부분을 해결해 주었습니다.
나는 내 모든 리눅스 박스에 하나의 브라우저 게이트웨이를 원했다
Guacamole은 내 원격 데스크톱과 터미널이 하나의 장소에서 존재할 수 있게 해주었다
제 홈랩에는 기능적인 데스크탑이 설치된 꽤 많은 리눅스 박스들이 있습니다. 이들은 각각의 용도가 있지만, 모든 시스템을 원격으로 관리하는 것은 많은 원격 접근 서비스 포트가 열려 있기 때문에 상당한 보안 위험을 초래합니다. 물론, Tailscale 같은 메쉬 VPN 뒤에 두면 되지만, 그것만으로는 느린 성능과 계속 발생하는 Xrdp 서비스 충돌 문제를 해결할 수 없습니다. 또한 그렇게 하는 것은 그렇게 도전적이거나 재미있지도 않습니다.
내가 정말 원했던 것은 모든 리눅스 데스크탑에 중앙에서 접근하고 Xrdp 지연 문제를 한곳에서 해결하는 것이었습니다. Apache Guacamole은 바로 그것을 가능하게 해줍니다. 원격 연결을 추가하고 브라우저 탭에서 바로 실행할 수 있으며, 화면 크기 조정과 성능 설정을 백그라운드에서 처리해줍니다. 그리고 Guacamole의 가장 좋은 점은 원격 데스크탑 서비스를 공용 인터넷에 더 이상 노출할 필요가 없다는 것입니다.
내 새로운 과카몰리 설정은 이렇게 생겼다:
브라우저 → 포트 443의 HTTPS → 구아카몰 서버 → 프라이빗 RDP → 리눅스 머신
브라우저는 어떤 노트북이나 데스크탑에서도 필요한 유일한 클라이언트입니다. 포트 443의 HTTPS는 내 네트워크에서 포트 포워딩된 규칙으로, 게이트웨이에 대한 접근을 허용하며, 나머지 모든 원격 접근 포트는 닫혀 있습니다.
Guacamole 서버는 게이트웨이 역할을 하며, 연결 프로필을 저장하고 RDP(원격 데스크톱 프로토콜)를 실행하는 나의 개인 Linux 기기에 대한 접근을 허용합니다.
저는 새 서버에 먼저 Apache Guacamole을 설치했습니다
게이트웨이 자체는 쉬웠지만, Docker를 작동시키는 데에는 한 가지 큰 함정이 있었다
Guacamole는 세 가지 서비스로 구성된 작은 스택에 설치되어 있습니다. Guacamole 웹 앱, guacd, 그리고 PostgreSQL입니다. 웹 앱은 브라우저 인터페이스를 제공하고, guacd는 모든 원격 연결을 처리하며, PostgreSQL 데이터베이스는 사용자 자격 증명과 연결 설정을 처리합니다.
나는 새로운 가상 머신에 Guacamole을 설치하고 IP 주소를 192.168.100.10으로 지정했다. Guacamole 게이트웨이 자체는 많은 자원을 필요로 하지 않지만, 나는 서버에 대해 다음 사양을 선택했다:
- 우분투 24.04 LTS
- 4GB 메모리
- 1.5GB 스왑이 있는 20GB 저장소
- 2 vCPU
다음은 Docker 설치였고, 여기서 약간의 문제가 발생했습니다. 간단한 Ubuntu 패키지 경로로는 제가 필요한 compose 플러그인을 제공하지 않았기 때문에, 대신 Docker 공식 저장소를 사용했습니다. ca-certificates와 curl을 설치한 후, 키 저장소를 만들고 Docker 공식 GPG 서명 키를 다운로드했습니다:
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
그런 다음 Docker의 저장소를 추가했습니다:
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
https://download.docker.com/linux/ubuntu \
$ (. /etc/os-release && echo "$ {UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
마지막으로, 나는 이 Docker 구성 요소들을 설치했습니다:
- 도커-CE
- docker-ce-cli
- 컨테이너디.io
- 도커-빌드엑스-플러그인
- 도커-컴포즈-플러그인
다음 명령어 사용:
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
내가 이상적으로 생각한 설정은 Guacamole을 서버에서 비공개로 유지하고, Nginx가 공개 HTTPS를 처리하는 것이었습니다:
저는 기본 Docker compose 파일에서 크게 벗어나지 않았습니다. 주로 이 세 개의 컨테이너를 정의했습니다:
- Guacamole 사용자, 자격 증명 및 연결 설정을 저장하는 PostgreSQL.
- guacd는 앱을 위해 RDP, SSH 및 VNC 연결을 처리합니다.
- 앱의 브라우저 기반 부분에 대한 웹 인터페이스를 제공하는 과카몰리.
저도 Guacamole을 로컬호스트에만 바인딩했습니다:
127.0.0.1:8080:8080
시작하기 전에, 저는 PostgreSQL 초기화 스크립트를 생성했습니다:
docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --postgresql > initdb.sql
그 후, 나는 다음과 함께 구아카몰 스택을 시작했습니다:
도커 컴포즈 업 -d
독립 실행형 docker-compose(v1)는 더 이상 사용되지 않습니다. Docker는 이제 통합된 docker compose 플러그인(Compose V2)을 사용할 것을 권장합니다.
컨테이너가 실행되자, 나는 Guacamole 앞에 리버스 프록시로 Nginx를 배포했다. Guacamole은 127.0.0.1:8080에서만 로컬로 수신하고 있었기 때문에, Nginx가 웹 애플리케이션에 접근하는 게이트웨이가 되었다.
그런 다음 Nginx 사이트를 활성화하고 제대로 작동하는지 확인했습니다:
sudo ln -s /etc/nginx/sites-available/guacamole /etc/nginx/sites-enabled/guacamole
sudo nginx -t
sudo systemctl reload nginx
마침내, HTTPS를 위해 TLS 인증서로 모든 것을 합법적으로 만들었습니다:
sudo certbot --nginx -d remote.ggcontentlabs.com
그것은 Docker 포트를 비공개로 유지했고 https://remote.ggcontentlabs.com/guacamole에서 Guacamole 로그인 페이지에 접근할 수 있는 공개 URL을 제공했습니다.
다음으로, 나는 내 가정용 네트워크에 몇 가지 변경을 해야 했다
Guacamole을 설치하면 HTTPS가 노출되며, 그 뒤에 있는 모든 Linux 서비스가 노출되는 것은 아닙니다
이 프로젝트의 목표는 원격 접근을 중앙집중화하면서 내 리눅스 데스크탑이 인터넷에 노출되지 않도록 하는 것이었습니다. 기본적으로, Guacamole이 정문이 되었고 나머지는 모두 그 뒤에 숨겨졌습니다.
내 아파치 과카몰리 서버의 공개 측은 충분히 단순했다. Nginx는 리버스 프록시로 사용되었고 443번 포트에서 HTTPS를 처리했다. 무료 TLS 인증서를 생성하기 위해 Let’s Encrypt와 Certbot이 사용되었고, 과카몰리는 그 모든 뒤에 위치했다. 과카몰리 뒤의 리눅스 머신들은 여전히 내 LAN에서 로컬로 접근할 수 있었지만, 라우터에서 원격 접근 포트를 닫아 각 머신에 대한 접근은 차단됐다.
Guacamole 서버 방화벽 규칙의 공개용 부분은 다음과 같았습니다:
Guacamole의 노출된 포트 | 역할 |
22 | 관리자 접근용 SSH |
80 | Let’s Encrypt는 검증을 위해 HTTP가 필요합니다 |
443 | HTTPS를 통한 과카몰리 |
제 Guacamole 서버는 Docker에서 실행되므로, 방화벽 규칙에도 로컬 서브넷을 추가해야 했습니다. 먼저 Docker 서브넷을 확인했습니다:
docker network inspect guacamole_default | grep Subnet
그런 다음 나는 그 서브넷을 UFW 방화벽을 통해 허용했습니다:
sudo ufw allow from 172.18.0.0/16 to any port 3389 proto tcp
각각의 리눅스 데스크톱마다, 나는 또한 Guacamole 서버가 해당 원격 서비스에 접근할 수 있도록 다음과 같은 인바운드 규칙들을 추가했습니다:
sudo ufw allow from 192.168.100.10 to any port 22 proto tcp
sudo ufw allow from 192.168.100.10 to any port 3389 proto tcp
sudo ufw allow from 192.168.100.10 to any port 5900 proto tcp
다음 단계이자 마지막 단계는 리눅스 머신을 Guacamole에 추가하기 시작하는 것이었습니다.
내 리눅스 기기를 추가하니 모든 것이 하나로 모였다
연결 설정은 Guacamole이 제대로 된 원격 허브처럼 느껴지기 시작하는 곳입니다
새 방화벽 규칙을 만든 후에는 Guacamole에 기계를 추가하는 것이 정말 쉬웠습니다. 첫 번째 단계는 기본 guacadmin 비밀번호를 재설정하고 새 연결을 만드는 것이었습니다. 관리자 패널에서 설정 -> 연결 -> 새 연결로 이동했습니다. 각 기계에 친근한 이름을 지정하고, 호스트 이름/IP 주소를 입력하고, 필요한 프로토콜을 선택했으며, 접근을 위한 자격 증명 세트를 할당했습니다.
유용한 부분은 연결당 Guacamole이 제공하는 제어 정도입니다. Xrdp 데스크탑의 경우 색 깊이를 설정하고, 읽기 전용으로 만들고, 사용자 지정 해상도를 설정하고, 배경화면을 켜고 끄고, 클립보드, 파일 업로드, 원격 인쇄를 활성화 및 비활성화하고, 드라이브 리디렉션을 설정할 수 있었습니다. 몇 가지 예를 들자면 이렇습니다.
연결 설정을 통해 이전에 RDP 클라이언트 자체에서 설정한 설정을 제어할 수 있었으며, 이는 보통 형편없는 화면 배율, 느린 성능, 불가피한 Xrdp 서비스 충돌을 초래했습니다. 첫 번째 테스트 머신에서는 경량 XFCE 데스크톱을 실행하면서 다음과 같은 설정을 사용했습니다:
- 해상도에 맞게 자동 조정
- 데스크톱 크기 조정을 위한 활성 디스플레이 모드
- 데스크톱 구성, 메뉴 애니메이션 및 글꼴 부드럽게 처리 비활성화
- 테마, 클립보드, 파일 업로드/다운로드, 비트맵 캐싱 및 테마 사용을 활성화합니다
이제 이러한 설정이 Guacamole로 제어되므로, 나는 그냥 연결하고, 브라우저를 전체 화면으로 하고, 지연 없이 문제 없는 원격 데스크탑 경험을 할 수 있었습니다. 새 머신에 원격으로 접속해서 계속 작업해야 한다면, 새 탭을 여는 것만으로 충분합니다. 그것은 나에게 필요한 것을 제공했습니다: 브라우저 창에 맞게 크기가 조정되는 Linux 데스크탑, 세션을 고아로 남기지 않고 깔끔하게 연결을 끊는 방법, 그리고 SSH를 통해 Xrdp-sesman 서비스를 계속 감시할 필요가 없는 것.
또 다른 서버이지만, 이제 복잡한 것들은 깔끔한 로그인 뒤에 숨겨져 있습니다.
설정하는 고통은 브라우저 기반 접근을 위해 그만한 가치가 있었다
네, Guacamole은 내 컬렉션에 또 다른 서버를 추가하고, 그 과정에서 Docker의 함정, TLS, 그리고 몇 가지 추가적인 방화벽 규칙을 처리해야 했습니다. 이는 단순히 원격 데스크톱을 실행하는 것만으로도 몇 가지 더 많은 구성 요소가 필요하다는 것을 의미합니다.
하지만 그 보상은 Guacamole이 내 중앙 원격 접속 허브가 된다는 것입니다. 모든 SSH, VNC, RDP 포트를 인터넷에 노출하는 대신, 이러한 서비스를 비공개로 유지하고 Guacamole이 단일 HTTPS 로그인을 통해 접속을 처리하도록 할 수 있습니다.
그것이 바로 설정 과정의 고통을 감수할 만하게 만든 이유였는데, 모든 것이 사전에 처리되어 나중에 내가 중요하게 생각하는 서버를 불필요한 보안 위험에 노출시키는 일을 막아주었기 때문이다. Guacamole이 원격 접근 문제를 완전히 해결한 것은 아니지만, 모든 것을 내가 제어할 수 있는 단일 지점 뒤로 이동시켰다.
홈 랩, 소규모 서버 군, 또는 Xrdp 성능 부족에 좌절하는 누구에게나, 이 거래의 대가는 완전히 가치가 있습니다.