Windows 원격 데스크톱에서 Linux로 전환할 때마다 항상 다소 충격을 받곤 합니다. 그 이유는 Remote Desktop Protocol(RDP)이 Microsoft의 기본 기능인 반면, Linux에서는 임시방편처럼 느껴지기 때문입니다. Linux 장비에 원격으로 접속하는 일은 종종 세션 충돌, 제대로 되지 않는 화면 크기 조절, 그리고 느린 성능을 의미했습니다. 또한, 필연적으로 발생하는 Xrdp 서비스 충돌 시 이를 재시작하기 위해 SSH 세션을 계속 열어두어야 했습니다.
저는 오픈 소스 원격 액세스 게이트웨이인 Apache Guacamole을 사용해 보기로 했습니다. 더 구체적으로는, 기존 Linux 장비를 추가하고 액세스할 수 있는 새 서버에 독립형으로 설치하는 방식을 택했습니다. Guacamole을 선택한 이유는 HTTPS를 통해 브라우저에서 RDP 세션을 제어할 수 있기 때문입니다. 또한, 모든 원격 Linux 사용자가 최소 몇 번은 겪었을 RDP 성능 및 안정성 문제의 대부분을 해결해 주었습니다.
관련 기사
모든 Linux 장비를 위한 하나의 브라우저 게이트웨이를 원했습니다
Guacamole은 내 원격 데스크톱과 터미널을 한곳에서 관리할 수 있게 해주었습니다
제 홈랩에는 기능적인 데스크톱을 갖춘 여러 대의 Linux 장비가 있습니다. 각각의 용도는 다르지만, 원격으로 관리하는 것은 노출된 원격 액세스 서비스 포트가 많아 상당한 보안 위험을 초래합니다. 물론 Tailscale과 같은 메시 VPN 뒤로 숨길 수도 있지만, 그것만으로는 느린 성능과 지속적인 Xrdp 서비스 충돌 문제를 해결할 수 없습니다. 또한, 그렇게 하는 것은 도전적이거나 재미있지도 않습니다.
제가 진정으로 원했던 것은 모든 Linux 데스크톱에 중앙에서 액세스하고 Xrdp의 지연 문제를 한곳에서 해결하는 것이었습니다. Apache Guacamole은 정확히 그 역할을 해줍니다. 원격 연결을 추가하고 브라우저 탭에서 실행할 수 있게 해주며, 창 크기 조절과 성능 설정을 내부적으로 처리해 줍니다. Guacamole의 가장 큰 장점은 원격 데스크톱 서비스를 공용 인터넷에 노출할 필요가 없다는 것입니다.
저의 새로운 Guacamole 설정은 다음과 같습니다:
브라우저 → 443 포트 HTTPS → Guacamole 서버 → 사설 RDP → Linux 머신
어떤 노트북이나 데스크톱에서든 브라우저만 있으면 됩니다. 443 포트의 HTTPS는 네트워크의 포트 포워딩 규칙으로, 게이트웨이에 대한 액세스를 허용하며 다른 모든 원격 액세스 포트는 닫혀 있습니다.
Guacamole 서버는 게이트웨이 역할을 하며, 연결 프로필을 저장하고 RDP(Remote Desktop Protocol)를 실행하는 사설 Linux 머신에 대한 액세스 권한을 부여합니다.
먼저 새 서버에 Apache Guacamole을 설치했습니다
게이트웨이 자체는 쉬웠지만, Docker를 작동시키는 데 한 가지 큰 걸림돌이 있었습니다
Guacamole은 세 가지 서비스로 구성된 작은 스택으로 설치됩니다. Guacamole 웹 앱, guacd, 그리고 PostgreSQL입니다. 웹 앱은 브라우저 인터페이스를 제공하고, guacd는 모든 원격 연결을 처리하며, PostgreSQL 데이터베이스는 사용자 자격 증명과 연결 설정을 관리합니다.
저는 새 가상 머신에 Guacamole을 설치하고 192.168.100.10 IP 주소를 할당했습니다. Guacamole 게이트웨이 자체는 많은 리소스를 필요로 하지 않지만, 서버 사양을 다음과 같이 결정했습니다:
Ubuntu 24.04 LTS 4GB 메모리 1.5GB SWAP을 포함한 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 구성 요소를 설치했습니다:
docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin 다음 명령어를 사용했습니다:
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. 앱을 위한 RDP, SSH 및 VNC 연결을 처리하는 guacd. 브라우저 기반 앱 인터페이스를 제공하는 Guacamole. 또한 Guacamole을 localhost에만 바인딩했습니다:
127.0.0.1:8080:8080
시작하기 전에 PostgreSQL 초기화 스크립트를 생성했습니다:
docker run –rm guacamole/guacamole /opt/guacamole/bin/initdb.sh –postgresql > initdb.sql
그 후 다음 명령어로 Guacamole 스택을 시작했습니다:
docker compose up -d
독립형 docker-compose(v1)는 더 이상 사용되지 않으며, Docker는 이제 통합된 docker compose 플러그인(Compose V2) 사용을 권장합니다.
컨테이너가 실행된 후, Nginx를 Guacamole 앞단의 리버스 프록시로 배포했습니다. 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 서비스가 노출되는 것은 아닙니다
이 프로젝트의 목표는 원격 액세스를 중앙 집중화하는 동시에 Linux 데스크톱이 인터넷에 노출되는 것을 방지하는 것이었습니다. 기본적으로 Guacamole이 정문이 되고, 다른 모든 것은 그 뒤에 숨겨졌습니다.
Apache Guacamole 서버의 공용 측면은 충분히 간단했습니다. Nginx를 리버스 프록시로 사용하여 443 포트에서 HTTPS를 처리했습니다. Let’s Encrypt와 Certbot을 사용하여 무료 TLS 인증서를 생성했고, Guacamole은 그 뒤에 배치되었습니다. Guacamole 뒤에 있는 Linux 머신들은 여전히 LAN에서 로컬로 액세스할 수 있었지만, 공유기의 원격 액세스 포트를 닫음으로써 각 머신에 대한 외부 액세스는 차단되었습니다.
Guacamole 서버 방화벽의 공용 규칙은 다음과 같았습니다:
| Guacamole 노출 포트 | 역할 |
| 22 | 관리자 액세스를 위한 SSH |
| 80 | Let’s Encrypt 검증을 위한 HTTP |
| 443 | HTTPS를 통한 Guacamole |
제 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
각 Linux 데스크톱에 대해서도 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
다음이자 마지막 단계는 Linux 머신들을 Guacamole에 추가하는 것이었습니다.
Linux 머신들을 추가하여 모든 것을 통합했습니다
연결 설정은 Guacamole이 진정한 원격 허브처럼 느껴지기 시작하는 부분입니다
새로운 방화벽 규칙을 만든 후, Guacamole에 머신을 추가하는 것은 매우 쉬웠습니다. 첫 번째 단계는 기본 guacadmin 비밀번호를 재설정하고 새 연결을 만드는 것이었습니다. 관리자 패널에서 Settings -> Connections -> New Connection으로 이동했습니다. 각 머신에 친숙한 이름을 지정하고, 호스트 이름/IP 주소를 입력하고, 필요한 프로토콜을 선택한 다음 액세스를 위한 자격 증명을 할당했습니다.
유용한 점은 Guacamole이 연결별로 얼마나 많은 제어권을 제공하느냐입니다. Xrdp 데스크톱의 경우 색상 깊이 설정, 읽기 전용 설정, 사용자 지정 해상도 설정, 배경 화면 켜기/끄기, 클립보드, 파일 업로드 및 원격 인쇄 활성화/비활성화, 드라이브 리디렉션 설정 등을 할 수 있습니다.
연결 설정을 통해 이전에는 RDP 클라이언트 자체에서 설정해야 했던 항목들을 제어할 수 있게 되었으며, 이는 보통 끔찍한 스케일링, 느린 성능, 그리고 필연적인 Xrdp 서비스 충돌로 이어지곤 했습니다. 가벼운 XFCE 데스크톱을 실행하는 첫 번째 테스트 머신에는 다음 설정을 사용했습니다:
해상도 자동 조정 데스크톱 크기 조절을 위한 활성 디스플레이 모드 데스크톱 구성, 메뉴 애니메이션 및 글꼴 다듬기 비활성화 테마, 클립보드, 파일 업로드/다운로드 및 비트맵 캐싱 활성화 Guacamole이 이러한 설정을 제어하게 되면서, 이제는 연결하고 브라우저를 전체 화면으로 전환하기만 하면 지연 없고 문제없는 원격 데스크톱 환경을 경험할 수 있습니다. 새 머신에 원격으로 접속하여 작업을 계속해야 할 경우, 새 탭을 열기만 하면 됩니다. 이것이 바로 제가 원했던 것입니다. 브라우저 창에 맞춰 크기가 조절되는 Linux 데스크톱, 세션을 고아로 만들지 않고 깔끔하게 연결을 끊는 방법, 그리고 더 이상 SSH를 통해 Xrdp-sesman 서비스를 관리할 필요가 없게 된 것입니다.
또 하나의 서버가 늘었지만, 이제 복잡한 것들은 깔끔한 로그인 뒤에 숨겨졌습니다
브라우저 기반 액세스를 위해 설정의 번거로움을 감수할 가치가 있었습니다
네, Guacamole은 제 서버 목록에 서버를 하나 더 추가했고, 그 과정에서 Docker의 문제점, TLS, 몇 가지 추가 방화벽 규칙을 다뤄야 했습니다. 이 모든 것은 원격 데스크톱을 열기 위해 몇 가지 움직이는 부품이 더 필요하다는 것을 의미합니다.
하지만 그 보상은 Guacamole이 저의 중앙 원격 액세스 허브가 된다는 점입니다. 모든 SSH, VNC 및 RDP 포트를 인터넷에 노출하는 대신, 해당 서비스들을 비공개로 유지하고 단일 HTTPS 로그인을 통해 Guacamole이 액세스를 처리하도록 할 수 있습니다.
설정의 번거로움을 감수할 가치가 있었던 이유는, 이 모든 작업이 초기에 이루어졌고 나중에 소중한 서버를 불필요한 보안 위험에 무심코 노출하는 것을 막아주었기 때문입니다. Guacamole이 원격 액세스의 혼란을 완전히 해결한 것은 아니지만, 제가 제어할 수 있는 단일 지점 뒤로 모든 것을 옮겨놓았습니다.
홈랩, 소규모 서버군, 또는 Xrdp의 부족한 성능에 좌절하는 모든 사람에게 이 절충안은 충분히 가치가 있습니다.
관련 기사