가이드

작성자 Matt Connor 2026-08-13 · 업데이트됨 2026-08-27

Linux VPS 원격 데스크톱 설정 및 보안 가이드

xrdp와 XFCE를 사용하여 Linux VPS에 원격 데스크톱을 구축하는 방법을 설명합니다. 3389 포트를 직접 노출하지 않고 SSH 터널을 통해 안전하게 접속하는 설정법과 RustDesk와의 차이점을 명확히 정리했습니다.

Linux VPS에서 원격 데스크톱이 실제로 의미하는 것

"Linux VPS 원격 데스크톱"을 검색하면 두 가지 서로 다른 제품이 나오는데, 잘못 선택하면 오후 내내 시간을 낭비하게 됩니다. 첫 번째는 원격 접속 중개자(broker)입니다. RustDesk의 자체 호스팅 서버가 대표적인 예로, 노트북과 가정용 PC처럼 이미 보유한 두 기기 사이의 세션을 중계합니다. 대여한 서버는 데스크톱 화면을 직접 그리지 않습니다. 서버는 두 기기를 서로 연결해주고, 직접 통신이 불가능할 때 패킷을 전달하는 역할만 합니다. 두 번째는 대여한 서버에서 직접 실행되는 실제 그래픽 데스크톱으로, 데이터 센터에서 픽셀을 그려 사용자에게 스트리밍하는 방식입니다. xrdp, VNC(virtual network computing) 또는 컨테이너 워크스페이스가 이에 해당합니다.

이 둘을 구분하는 질문은 하나입니다. 설정이 완료된 후 마우스 포인터가 어디에 위치하는가입니다. 이미 보유한 기기에서 작업하려면 중개자가 필요합니다. VPS 자체에서 작업하려면 VPS에 데스크톱이 있어야 합니다. 아래 내용은 대부분 두 번째 경우를 다루는데, 이는 다른 가이드에서 흔히 생략하는 부분이기 때문입니다.

작업에 적합한 옵션 선택

자체 릴레이를 사용하는 RustDesk. 사용자가 키 쌍을 직접 보유하므로 세션이 타인이 운영하는 공개 랑데부 서버를 거치지 않도록 보호합니다. 다만 제어 대상이 되는 PC 자체를 보호하지는 않으며, 여전히 클라이언트가 설치된 PC의 기존 비밀번호 정책을 따릅니다.
SSH 터널 또는 VPN을 경유하는 xrdp. TCP 3389 포트가 인터넷에 직접 노출되지 않으므로, 인터넷 전역에서 수행되는 상시 스캔과 RDP 로그인 화면을 대상으로 한 비밀번호 무차별 대입 공격으로부터 보호합니다. 다만 터널 접근 권한을 이미 획득한 공격자로부터 취약한 계정 비밀번호를 보호하지는 못합니다.
동일한 터널을 경유하는 VNC. 연결이 끊겨도 유지되는 데스크톱 세션을 제공하며, RDP보다 오래되고 단순한 프로토콜을 사용합니다. VNC 자체는 보안 기능을 제공하지 않으며 모든 보안은 터널에 의존합니다. 따라서 공용 포트에 VNC만 단독으로 노출하는 것은 가장 위험한 선택입니다.
Webtop 또는 Kasm과 같은 컨테이너 워크스페이스. 브라우저나 전체 데스크톱 환경을 컨테이너 내에서 제공하며, 필요 시 폐기하고 재구축할 수 있어 브라우저가 접근하는 대상으로부터 실제 호스트 머신을 보호합니다. 다만 호스트 자체를 보호하지는 않습니다. 이러한 이미지는 광범위한 권한으로 실행되며 내부적으로 비밀번호가 없는 sudo을 사용하므로, 컨테이너를 적대적인 워크로드를 격리할 수 있는 신뢰할 만한 경계로 보아서는 안 됩니다.

Ubuntu 24.04에 xrdp 및 XFCE 설치

VPS 서버 이미지는 그래픽 데스크톱 없이 제공됩니다. 데스크톱 환경을 설치한 뒤, Windows 클라이언트가 사용하는 RDP(Remote Desktop Protocol)를 지원하는 오픈 소스 서버인 xrdp를 설치합니다. 가벼운 데스크톱 환경을 선택해야 하며, 보통 XFCE가 권장됩니다.

sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies dbus-x11
systemctl is-active xrdp

2026년 8월 기준으로 Ubuntu 24.04는 universe 저장소에서 xrdp 0.9.24와 xorgxrdp를 제공합니다. xorgxrdp은 권장 패키지일 뿐이지만 반드시 이름으로 지정하여 설치하십시오. 이는 xrdp가 새 세션을 시작할 때 사용하는 X 서버 백엔드이며, 이 패키지가 없으면 로그인 화면에서 비밀번호를 입력해도 다시 로그인 화면으로 돌아오게 됩니다.

이제 세션에 어떤 데스크톱을 시작할지 알려주어야 합니다. xrdp는 /etc/xrdp/startwm.sh을 실행하며, 이 파일이 존재하면 ~/.xsession를 실행합니다.

echo "xfce4-session" > ~/.xsession
chmod 644 ~/.xsession

마지막으로, xrdp는 클라이언트에 제공할 TLS(Transport Layer Security) 키를 읽어야 합니다. 해당 파일은 모드 640이어야 하며 ssl-cert 그룹이 소유해야 합니다.

ls -l /etc/ssl/private/ssl-cert-snakeoil.key
id xrdp

목록에 -rw-r----- 1 root ssl-cert이 표시됩니다. 만약 id xrdp를 실행했을 때 그룹 목록에 ssl-cert이 없다면, sudo adduser xrdp ssl-cert를 실행한 뒤 sudo systemctl restart xrdp를 실행하십시오. 이 과정을 건너뛰면 xrdp가 키를 열 수 없으며, /var/log/xrdp.log에는 snakeoil 파일 이름과 함께 실패 기록이 남게 됩니다.

인터넷에 3389 포트를 개방하면 안 되는 이유

TCP 3389 포트는 인터넷상의 모든 스캐너가 지속적으로 탐색하며, RDP 로그인 창은 모든 비밀번호 시도에 정중하게 응답합니다. 이 포트를 개방하지 마십시오. 대신 xrdp를 루프백 주소에 바인딩하고, 이미 신뢰하는 터널을 통해 접속하십시오.

/etc/xrdp/xrdp.ini 파일을 편집하고 [Globals] 섹션에서 리스너 설정을 변경합니다.

[Globals]
port=tcp://.:3389

배포된 파일의 주석에는 해당 구문이 설명되어 있습니다. tcp://.:3389는 127.0.0.1:3389를 의미하며, tcp://:3389은 모든 인터페이스를 의미합니다. 설정을 변경한 후에는 반드시 재시작하여 확인하십시오. 오타가 있으면 서비스가 모든 주소에서 대기 상태로 남게 됩니다.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

127.0.0.1:3389 상태가 되어야 합니다. 0.0.0.0:3389가 보인다면 xrdp가 편집 내용을 무시한 것입니다. 보통 해당 줄이 파일 하단의 다른 섹션 헤더 아래에 위치했기 때문입니다.

이제 로컬 머신에서 터널을 엽니다.

ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com

-N은 "연결은 열되 명령은 실행하지 않음"을 의미하며, 세션은 오직 포트 전달을 위해서만 존재합니다. 해당 터미널을 계속 실행해 두고 RDP 클라이언트에서 127.0.0.1:3389로 접속하십시오. Linux 클라이언트의 경우 FreeRDP 3 소프트웨어를 사용하며, Ubuntu 24.04의 바이너리 이름은 xfreerdp3입니다.

sudo apt install -y freerdp3-x11
xfreerdp3 /v:127.0.0.1:3389 /u:you /dynamic-resolution +clipboard /sound

Windows에서는 내장된 mstsc을 사용하고 컴퓨터 항목에 127.0.0.1을 입력합니다. FreeRDP는 첫 연결 시 인증서를 신뢰할지 묻고 Do you trust the above certificate? (Y/T/N)을 출력하는데, 이는 자체 서명된 snakeoil 인증서 사용 시 정상적인 동작입니다.

ssh가 bind [127.0.0.1]:3389: Address already in use를 반환한다면, 로컬 머신에서 이미 3389 포트를 사용 중인 것입니다. ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com을 사용하여 로컬 포트를 변경하고 127.0.0.1:13389로 접속하십시오.

사용자마다 터널을 하나씩 만드는 것은 번거로우므로, 팀 단위라면 사설 네트워크를 사용하는 것이 더 나은 해결책입니다. 서버를 자체 호스팅 WireGuard VPN 뒤에 배치하고, 터널 주소 10.8.0.1를 부여한 뒤, xrdp가 VPN 내부에서만 응답하도록 port=tcp://10.8.0.1:3389을 설정하십시오. 어떤 방식을 선택하든 3389 포트에 대한 방화벽 규칙은 아예 존재하지 않아야 합니다. 현재 어떤 규칙이 허용되어 있는지 확실하지 않다면, VPS의 ufw 방화벽 기초를 참고하여 연결하기 전에 미리 확인하십시오.

2 GB VPS에서 원격 데스크톱은 RAM을 얼마나 사용하는가

선택하는 데스크톱 환경에 따라 2 GB 플랜이 쾌적할 수도, 불가능할 수도 있습니다. 아래 수치는 Ubuntu 24.04에 로그인한 직후의 메모리 사용량을 반올림한 일반적인 값이며, 실제 사용자의 머신에서 측정한 것이 아니라 공개된 비교 자료를 바탕으로 합니다. 연결 직후 free -m 명령어로 직접 측정해 보십시오.

ChartTypical memory in use after login, Ubuntu 24.04 (published figures)

label

idle_ram_mb

LXQt

300

XFCE

400

MATE

500

KDE Plasma

800

GNOME

1,200

The data behind this chart

[
  {
    "label": "LXQt",
    "idle_ram_mb": 300
  },
  {
    "label": "XFCE",
    "idle_ram_mb": 400
  },
  {
    "label": "MATE",
    "idle_ram_mb": 500
  },
  {
    "label": "KDE Plasma",
    "idle_ram_mb": 800
  },
  {
    "label": "GNOME",
    "idle_ram_mb": "1,200"
  }
]

5개의 데스크톱 환경을 비교해 보면 그 차이가 핵심입니다. LXQt는 300 MB, XFCE는 400 MB 수준이므로, 둘 다 2 GB 서버에서 브라우저를 실행할 여유가 있습니다. 반면 GNOME은 창을 하나도 열지 않은 상태에서 약 1,200 MB를 점유하므로, 2 GB 환경에서는 브라우저가 데스크톱과 남은 메모리를 두고 경쟁하게 됩니다.

실제 비용을 결정하는 것은 데스크톱 셸이 아니라 브라우저입니다. 최신 브라우저는 활성 탭 하나당 150에서 400 MB를 사용하므로, XFCE를 실행 중인 2 GB VPS는 탭 몇 개를 띄우면 스왑(swap)을 사용하기 시작합니다. 프로세스가 강제 종료되는 대신 시스템이 느려지도록 스왑을 추가하십시오. sudo fallocate -l 2G /swapfile를 실행한 뒤 sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile을 차례로 수행하고, /etc/fstab에 해당 라인을 추가하여 재부팅 후에도 유지되도록 합니다. 아무런 경고 없이 프로세스가 사라진다면 dmesg | grep -i "killed process"을 실행하십시오. 해당 로그는 커널의 OOM(out-of-memory) 킬러가 프로세스를 종료했음을 의미하며, 보통 브라우저가 그 대상이 됩니다.

CPU 역시 또 다른 제한 요소이며, 과소평가하기 쉽습니다. VPS에는 GPU가 없으므로 X 서버는 llvmpipe를 통한 소프트웨어 렌더링으로 전환되며, 이는 CPU가 모든 픽셀을 직접 그려야 함을 의미합니다. 무거운 페이지를 스크롤하거나 영상을 재생하면 CPU 부하가 급증하며, 시스템이 멈추는 대신 프레임 레이트가 떨어집니다. 이는 VPS에서 게임이 가능한지 궁금해할 때 마주하게 되는 것과 같은 한계입니다. 3D 작업이 불가능한 이유는 바로 이 때문입니다.

xrdp 세션에서의 사운드 및 클립보드

Ubuntu 24.04는 오디오 처리에 PipeWire를 사용하지만, xrdp의 사운드 리다이렉션은 PulseAudio를 기준으로 작성되었습니다. 따라서 새로 설치하면 화면은 정상적으로 나오지만 소리가 들리지 않습니다. Ubuntu는 이를 위한 브리지 패키지를 제공합니다.

sudo apt install -y pipewire-module-xrdp pulseaudio-utils alsa-utils

모듈은 세션이 시작될 때 로드되므로, RDP 세션에서 완전히 로그아웃한 뒤 다시 로그인하십시오. 단순히 재연결하는 것만으로는 충분하지 않습니다. 그 후 세션 내부에서 다음을 확인하십시오.

pactl list short sinks
speaker-test -c 2 -t wav -l 1

이름에 xrdp가 포함된 싱크(sink)가 보여야 하며, 클라이언트를 통해 테스트 음이 들려야 합니다. xrdp 싱크가 보이지 않는다면 해당 세션에 모듈이 로드되지 않은 것입니다. 또한 클라이언트 측에서도 오디오를 요청해야 합니다. 이는 xfreerdp3의 /sound 플래그이거나, Windows 클라이언트의 '로컬 리소스(Local Resources)' 설정에 있는 '원격 오디오(Remote audio)' 항목입니다.

텍스트 클립보드는 세션에 대해 xrdp-chansrv이 실행 중이면 양방향으로 작동하며, 이는 xrdp가 자동으로 시작해 줍니다. pgrep -a xrdp-chansrv 명령으로 이를 확인하십시오. 세션 도중 복사 및 붙여넣기가 작동하지 않는다면 해당 프로세스가 종료된 것이며, 재연결을 수행하면 프로세스가 다시 시작됩니다. 텍스트가 아닌 파일을 복사하는 것은 드라이브 리다이렉션이라는 별도의 채널을 사용합니다. xfreerdp3에서 /drive:home,/home/you를 사용하면 로컬 폴더를 원격 세션에 마운트할 수 있습니다.

polkit 팝업 및 기타 최초 로그인 실패 사례

최초 로그인 시 가장 흔히 발생하는 문제는 Authentication is required to create a color managed device 메시지가 담긴 대화 상자입니다. 원인은 명확합니다. colord 서비스가 polkit에 권한을 요청하면, polkit은 로컬에 위치한 세션이라고 판단될 때만 조용히 권한을 부여합니다. 하지만 RDP 세션은 로컬 세션으로 간주되지 않으므로, polkit은 사용자에게 비밀번호를 요구하게 됩니다. Ubuntu 24.04는 polkit 124 버전을 탑재하고 있으며, 이 버전에서는 기존의 로컬 권한 .pkla 파일이 제거되었습니다. 따라서 /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla를 작성하라는 모든 가이드는 24.04에서 아무런 효과가 없습니다. 대신 JavaScript 규칙을 작성해야 합니다.

/* /etc/polkit-1/rules.d/45-allow-colord.rules */
polkit.addRule(function(action, subject) {
    if (action.id.indexOf("org.freedesktop.color-manager.") === 0 &&
        subject.isInGroup("sudo")) {
        return polkit.Result.YES;
    }
});

sudo systemctl restart polkit을 실행한 뒤 다시 연결하십시오. 다음 두 가지 실패 사례는 증상만으로도 원인을 파악할 수 있습니다.

로그인 창에서 비밀번호를 입력하면 다시 로그인 창으로 돌아옵니다. 세션이 시작되자마자 종료된 경우입니다. 먼저 /var/log/xrdp-sesman.log을 확인하고, 이어서 홈 디렉터리의 ~/.xsession-errors를 확인하십시오. xorgxrdp 파일이 없거나, 설치되지 않은 데스크톱 환경을 가리키는 ~/.xsession 설정이 있거나, 홈 디렉터리에 쓰기 권한이 없거나, 디스크가 가득 찬 경우 모두 이 증상으로 이어집니다.

연결 시 X 커서가 있는 회색 화면만 보입니다. X 서버는 시작되었으나 데스크톱 환경이 실행되지 않은 상태입니다. 이는 다시 ~/.xsession 문제입니다. SSH를 통해 xfce4-session을 직접 실행하여 출력되는 오류 메시지를 확인하십시오.

자체 호스팅 RustDesk 서버의 역할

RustDesk는 두 개의 프로세스로 나뉩니다. hbbs은 클라이언트가 등록하는 ID 및 랑데부 서버이며, hbbr은 직접적인 피어 투 피어 연결이 실패할 경우 세션을 전달하는 릴레이입니다. 두 프로세스 모두 데스크톱 환경을 실행하지 않습니다. 두 프로세스 모두 하나의 이미지에서 생성되며, 다음은 프로젝트에서 제공하는 compose 파일입니다. 릴레이 주소는 사용자의 호스트 이름으로 변경되었습니다.

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r rustdesk.example.com:21117
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
      - 21118:21118
    volumes:
      - ./data:/root
    restart: unless-stopped
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - 21117:21117
      - 21119:21119
    volumes:
      - ./data:/root
    restart: unless-stopped

서비스를 시작한 뒤, 첫 실행 시 서버가 생성한 공개 키를 확인합니다.

sudo docker compose up -d
sudo cat ./data/id_ed25519.pub

모든 클라이언트는 RustDesk 클라이언트의 Network 설정에서 사용자의 호스트 이름과 해당 공개 키를 입력해야 합니다. 일치하는 개인 키는 ./data/id_ed25519에 저장됩니다. 데이터 디렉터리를 삭제하면 서버가 새로운 키 쌍을 생성하므로, 모든 클라이언트를 새 키로 다시 설정해야 합니다. 해당 디렉터리를 백업하십시오. 이 방식이 단순한 주말 실험을 넘어 팀의 모든 머신에 접근하는 표준 수단이 된다면, Ed25519 키 처리, latest 대신 고정된 이미지 태그 사용, 그리고 요금제에 따른 릴레이 대역폭 확보를 위해 RustDesk 릴레이 전용 빌드를 구성하는 것을 권장합니다.

방화벽에서 다음 포트를 직접 허용해야 합니다. hbbs는 TCP 21115, 21116, 21118 및 UDP 21116을 사용합니다. hbbr은 TCP 21117 및 21119를 사용합니다.

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp

RustDesk를 nginx나 Traefik 뒤에 배치할 수 없는 이유

모든 서비스의 TLS를 리버스 프록시에서 종료하는 환경을 구축한 사용자들이 RustDesk를 시도하다 실패하는 경우가 많습니다. hbbs와 hbbr은 HTTP가 아닌 자체 바이너리 프로토콜을 TCP와 UDP로 통신합니다. 라우팅에 필요한 Host 헤더가 없고 검사할 HTTP 요청도 존재하지 않으므로, nginx의 server 블록이나 Traefik의 HTTP 라우터는 매칭할 대상을 찾지 못합니다. 21116 포트에서 대기하는 UDP 리스너는 어떤 계층에서도 HTTP와 관련이 없습니다.

두 가지 방법은 정상적으로 작동합니다. nginx의 stream 블록을 사용하면 TCP 포트를 전달할 수 있는데, 이는 일반적인 리버스 프록시 방식이 아닌 단순한 4계층 포워딩입니다. 또한 21118 및 21119 포트는 RustDesk 웹 클라이언트가 사용하는 웹소켓을 처리하며, 이는 일반적인 HTTP이므로 프록시 뒤에 배치할 수 있습니다. 이 방식을 사용할 경우, hbbs가 웹소켓 연결의 X-Real-IP 헤더를 통해 실제 클라이언트 주소를 파악하므로, 반드시 방화벽 규칙을 추가하여 프록시만 21118 및 21119 포트에 접근할 수 있도록 제한해야 합니다.

컨테이너 기반의 일회용 브라우저

때로는 자신의 로컬 머신과 격리된 상태로 IP가 변하지 않는 깨끗한 브라우저 환경이 필요할 때가 있습니다. 컨테이너 워크스페이스를 사용하면 최소한의 소프트웨어만 설치하여 이러한 환경을 구축할 수 있습니다. LinuxServer의 Webtop은 가벼운 대안입니다.

services:
  webtop:
    image: lscr.io/linuxserver/webtop:latest
    container_name: webtop
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - /path/to/data:/config
    ports:
      - 127.0.0.1:3000:3000
      - 127.0.0.1:3001:3001
    shm_size: "1gb"
    restart: unless-stopped

포트 3000은 HTTP를, 3001은 HTTPS를 서비스하며, 별도의 RDP 클라이언트 없이 브라우저 탭에서 바로 데스크톱에 접근할 수 있습니다. 이미지 태그는 여러 기본 배포판에서 XFCE, KDE, MATE, i3 환경을 지원합니다. 프로젝트 공식 문서에서는 이 컨테이너가 호스트에 대한 권한 있는 접근 권한을 가지며 비밀번호 없는 sudo를 포함한 터미널을 제공하므로, 인터넷에 직접 노출해서는 안 된다고 경고합니다. 따라서 위 포트들은 모든 주소에 공개하는 대신 127.0.0.1에 바인딩해야 합니다. xrdp 사용 시와 동일한 SSH 터널이나 VPN을 통해 접근하십시오.

Kasm Workspaces는 훨씬 큰 규모에서 동일한 개념을 구현한 것으로, 웹 콘솔, 사용자 계정, 세션 종료 시 초기화되는 세션별 컨테이너 기능을 제공합니다. 이 솔루션은 소규모 VPS가 감당하기에는 더 많은 자원을 요구합니다. 2026년 8월 기준 문서화된 최소 사양은 CPU 2코어, 메모리 4 GB, SSD 50 GB이며, 각 사용자 세션은 기본적으로 추가 2코어와 2768 MB의 메모리를 사용합니다. 2 GB 플랜에서는 실행할 수 없습니다. 설치는 다운로드 후 스크립트를 실행하는 방식입니다.

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.sh

VNC와 여전히 유효한 활용 사례

VNC는 그리기 명령 대신 프레임버퍼 업데이트를 전송하므로, 느린 연결 환경에서는 RDP보다 무겁게 느껴지며 오디오 채널을 지원하지 않습니다. 하지만 VNC가 유용한 상황이 하나 있습니다. 연결을 끊은 뒤에도 데스크톱 세션을 계속 유지하고, 다시 접속했을 때 동일한 세션을 그대로 불러와야 하는 경우입니다. TigerVNC는 이 기능을 제공합니다. vncserver -localhost yes :1은 Xvnc를 127.0.0.1의 TCP 5901 포트에 바인딩하고 외부에서의 연결을 차단하므로, ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com을 사용하여 xrdp와 동일한 방식으로 터널링해야 합니다. VNC 포트를 절대 외부에 공개하지 마십시오. 대부분의 VNC 서버는 핸드셰이크 과정에서만 비밀번호를 보호할 뿐 그 이후에는 암호화를 제공하지 않으므로, 공개 포트에 노출할 경우 세션 내용을 네트워크상에서 그대로 읽을 수 있습니다.

VPS를 데스크톱으로 사용하는 것이 좋은 선택입니까?

일상적인 용도로는 적합하지 않으며, 그 이유는 다음과 같습니다. GPU가 없으므로 모든 화면을 CPU가 그려야 합니다. 키를 누를 때마다 네트워크 왕복 시간을 기다려야 하며, SSH에서는 괜찮게 느껴지던 40 ms의 지연 시간도 텍스트 편집기에서는 확연히 느껴집니다. 영상은 사이트에서 한 번, RDP 인코더에서 다시 한 번 압축됩니다. 파일은 사용자가 직접 소유하지 않은 디스크에 저장되며, 헤비한 데스크톱 사용은 웹 서버 기준으로 책정된 월간 대역폭 제한을 빠르게 소진합니다.

일회용 머신으로 사용하기에는 매우 좋습니다. 앞서 언급한 특성들이 그 이유를 설명합니다. IP 주소가 안정적이고 데이터 센터에 속해 있어, 서비스가 일관된 주소를 확인해야 할 때 유리합니다. 이미지를 통해 몇 분 만에 머신을 재구축할 수 있으므로, 악성 코드에 감염된 세션도 비용 부담 없이 폐기할 수 있습니다. 실제 하드웨어와 격리되어 있으며, 노트북을 닫아도 계속 실행됩니다. 시간 단위 과금 방식 덕분에 일회용 데스크톱을 저렴하게 운영할 수 있습니다.

이 서버의 용도를 고민 중이라면, 데스크톱 환경을 설치하기 전에 VPS가 유용한 작업 목록을 먼저 읽어보는 것이 좋습니다. 만약 특정 Windows 애플리케이션 때문에 데스크톱 환경을 원한다면, Linux와 Windows Server의 실제 차이점을 먼저 비교해 보십시오. 라이선스 정책에 따라 운영 비용이 크게 달라질 수 있기 때문입니다.

FAQ

2 GB VPS에서 원격 데스크톱을 실행할 수 있습니까?

네, 가벼운 데스크톱 환경을 사용하면 가능합니다. XFCE나 LXQt는 로그인 후 약 300~400 MB를 점유하므로, 브라우저에서 탭 몇 개를 띄울 여유가 있습니다. 2 GB 환경에서 GNOME이나 KDE Plasma를 사용하면 애플리케이션을 실행할 자원이 거의 남지 않습니다. 2 GB 크기의 스왑 파일을 추가하여 메모리 부족 시 프로세스가 강제 종료되는 대신 시스템 속도가 느려지도록 설정하십시오. 메시지 없이 프로세스가 사라진다면 dmesg | grep -i "killed process"을 확인하여 커널의 OOM(Out-of-Memory) 킬러가 작동했는지 확인하십시오.

VPS 방화벽에서 3389 포트를 열어야 합니까?

아니요. TCP 3389 포트는 지속적으로 스캔 대상이 되며, RDP 로그인 화면을 외부에 노출하면 무차별 대입 공격에 취약해집니다. /etc/xrdp/xrdp.ini 파일에서 port=tcp://.:3389를 설정하여 xrdp가 127.0.0.1에서만 대기하도록 하고, ss -tlnp | grep 3389로 이를 확인한 뒤 ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com를 통해 접속하십시오. 사용자 수가 2명을 초과한다면 루프백 주소 대신 WireGuard 인터페이스 주소에 xrdp를 바인딩하십시오.

xrdp 로그인 시 "Authentication is required to create a color managed device"라는 메시지가 뜨는 이유는 무엇입니까?

colord 서비스가 polkit에 권한을 요청하는데, polkit은 로컬 세션에만 해당 동작을 자동으로 허용하기 때문입니다. RDP 세션은 로컬 세션으로 간주되지 않아 로그인할 때마다 암호를 묻습니다. Ubuntu 24.04에서는 polkit 124 버전부터 로컬 권한 파일이 제거되어 기존의 .pkla 수정 방식이 작동하지 않습니다. org.freedesktop.color-manager.으로 시작하는 작업 ID에 대해 polkit.Result.YES를 반환하는 자바스크립트 규칙을 포함한 /etc/polkit-1/rules.d/45-allow-colord.rules 파일을 생성한 뒤, sudo systemctl restart polkit을 실행하십시오.

자체 호스팅한 RustDesk 서버를 nginx나 Traefik 뒤에 둘 수 있습니까?

메인 서비스는 불가능합니다. hbbs와 hbbr은 HTTP가 아닌 자체 바이너리 프로토콜을 사용하므로 라우팅에 필요한 Host 헤더가 없으며, UDP 21116 포트는 HTTP 프록시를 통과할 수 없습니다. 방화벽에서 TCP 21115~21119 포트와 UDP 21116 포트를 개방하여 클라이언트가 직접 연결하도록 하십시오. 웹 클라이언트가 사용하는 웹소켓 포트 21118과 21119는 HTTP 기반이므로 프록시 뒤에 배치할 수 있습니다. 이 경우 프록시만 해당 포트에 접근하도록 방화벽을 설정하십시오. hbbs는 해당 연결에서 X-Real-IP을 신뢰하기 때문입니다.

xrdp 세션에서 소리가 나지 않는 이유는 무엇입니까?

Ubuntu 24.04는 PipeWire를 사용하지만 xrdp의 사운드 리다이렉션은 PulseAudio용으로 설계되었기 때문에 브리지 패키지를 설치하기 전까지는 오디오가 작동하지 않습니다. sudo apt install -y pipewire-module-xrdp를 실행한 뒤 세션에서 완전히 로그아웃하고 다시 로그인하십시오. 모듈은 세션 시작 시 로드되므로 단순히 재연결하는 것만으로는 적용되지 않습니다. pactl list short sinks을 실행하여 xrdp라는 이름의 싱크(sink)가 있는지 확인하고, 클라이언트가 오디오를 요청하도록 설정하십시오. 이는 xfreerdp3의 /sound 플래그 또는 Windows 클라이언트의 "원격 오디오" 설정에 해당합니다.

#remote-desktop#xrdp#rustdesk#vnc#self-hosting