가이드

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

RustDesk 자체 호스팅 릴레이 서버 구축 및 설정 가이드

Q: RustDesk 서버 키는 어디에 저장되며, 분실하면 어떻게 됩니까?

hbbs는 최초 실행 시 작업 디렉터리에 id_ed25519와 id_ed25519.pub를 생성합니다. 공식 이미지 내부의 해당 디렉터리는 /root이므로, 위에서 설명한 볼륨 마운트를 사용하면 호스트의 ./data 경로에 파일이 나타납니다. 두 파일을 서버 외부로 백업하십시오. 파일을 분실하여 hbbs가 재시작 시 새 키 쌍을 생성하면, 기존 공개 키를 가진 모든 클라이언트의 연결이 거부됩니다. 이 경우 모든 클라이언트의 Key 필드를 수동으로 수정하는 것 외에는 복구 방법이 없습니다.

VPS에서 hbbs와 hbbr 데몬을 직접 운영하는 방법을 설명합니다. Ed25519 키 관리와 포트 보안 설정은 물론, 릴레이 대역폭 비용을 최적화하기 위한 필수 환경 변수 설정과 NAT 홀 펀칭 동작 원리를 상세히 다룹니다.

자체 호스팅 RustDesk 릴레이 서버란 무엇인가

자체 호스팅 RustDesk 릴레이 서버는 하나의 VPS에서 실행되는 두 개의 데몬으로 구성됩니다. hbbs은 ID 및 랑데부 서버로, 모든 클라이언트 ID를 등록하고 두 클라이언트를 서로 연결합니다. hbbr는 릴레이 서버로, 직접 통신이 불가능한 세션의 데이터를 중계합니다. 대부분의 가이드는 두 데몬을 설치하고 연결하는 과정까지만 다룹니다. 이 문서에서는 그 이후의 작업인 접근 제어를 위한 키, 포트 설정, 업그레이드, 대역폭 관리에 대해 설명합니다.

두 데몬은 동일한 이미지인 rustdesk/rustdesk-server에 포함되어 있으며, 같은 디렉터리에서 동일한 Ed25519 키 쌍을 읽어 들입니다. Ed25519는 공개 키 서명 방식입니다. 이 키 쌍은 서버가 어떤 클라이언트와 통신할지 결정하며, 별도의 사용자 데이터베이스는 존재하지 않습니다.

hbbs와 hbbr: 대역폭을 소모하는 데몬

hbbs의 트래픽은 작고 일정합니다. ID 등록과 하트비트, 그리고 두 피어를 연결하기 위한 짧은 교환이 전부입니다. 하루 종일 실행되어도 비용은 거의 발생하지 않습니다.

hbbr의 트래픽은 세션 그 자체입니다. 화면 프레임은 한쪽으로 흐르고, 키보드와 마우스 입력은 반대쪽으로 흐릅니다. 릴레이되는 모든 바이트는 VPS에 도착했다가 다시 나갑니다. 제공업체가 송신(egress) 트래픽만 측정한다면 릴레이 세션은 세션 속도만큼의 비용이 발생합니다. 총 전송량을 측정한다면 그 두 배 정도의 비용이 듭니다.

릴레이는 기본 경로가 아니라 예비 경로입니다. hbbs는 먼저 두 클라이언트를 직접 연결하려고 시도합니다. 각 클라이언트 앞에 있는 NAT(네트워크 주소 변환)를 통과하기 위해 홀 펀칭(hole punching)을 사용합니다. 이 방식이 성공하면 세션은 hbbr을 거치지 않으며 전송 허용량도 소모되지 않습니다. 한쪽이 목적지마다 새로운 포트를 할당하는 NAT 뒤에 있거나, 펀칭된 경로를 차단하는 방화벽 뒤에 있다면 세션은 hbbr로 전환되며 모든 프레임이 VPS를 통과하게 됩니다.

환경 변수 하나로 이 선택을 강제할 수 있습니다. hbbs의 ALWAYS_USE_RELAY=Y는 모든 세션이 hbbr을 통과하도록 강제합니다. RustDesk 문서의 Compose 예제 중 하나에 이 설정이 포함되어 있어 자주 복사되곤 합니다. 이 설정은 연결을 더 예측 가능하게 만들지만, 송신 트래픽을 실제로 발생시킵니다. 단순히 복사해서 붙여넣기 때문이 아니라, 필요성을 판단한 뒤에 설정하십시오.

자체 호스팅 RustDesk 서버에 필요한 포트

아래 포트 번호는 2026년 8월 17일 기준으로 RustDesk 서버 문서와 rustdesk-server 저장소를 확인한 결과입니다.

TCP 21115, hbbs: NAT 유형 테스트용입니다.
UDP 21116, hbbs: ID 등록 및 하트비트용입니다. 이 포트가 열려 있지 않으면 다른 포트가 열려 있어도 클라이언트가 온라인 상태가 되지 않습니다.
TCP 21116, hbbs: TCP 홀 펀칭 및 연결 서비스용입니다.
TCP 21117, hbbr: 릴레이용입니다. 세션 데이터를 전송하는 포트이므로 트래픽 비용이 발생하는 포트입니다.
TCP 21118(hbbs) 및 TCP 21119(hbbr): 웹 브라우저 클라이언트에서 사용하는 WebSocket용입니다. 사용하지 않는다면 둘 다 닫아 두십시오.
TCP 21114: RustDesk Server Pro의 웹 콘솔용입니다. 오픈 소스 빌드에서는 이 포트를 사용하지 않습니다.

hbbs 및 hbbr을 특정 이미지 태그로 설치하기

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbr -k _
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

mkdir -p ~/rustdesk
cd ~/rustdesk
# save the block above as ~/rustdesk/compose.yml before this line
sudo docker compose up -d
sudo docker compose ps

두 서비스 모두 running을 읽어야 합니다. 방화벽을 설정하기 전에 리스너가 존재하는지 확인하십시오.

sudo ss -tlnp | grep -E ':2111[5-7]'
sudo ss -ulnp | grep ':21116'

21115, 21116, 21117 포트에서 TCP 리스너가, 21116 포트에서 UDP 리스너가 실행 중이어야 합니다. UDP 항목이 보이지 않는다면 hbbs가 실행되지 않은 것입니다. 클라이언트가 등록을 시도하는 곳이 바로 해당 리스너이기 때문입니다.

파일에 포함된 네 가지 설정은 의도된 것입니다. 태그는 1.1.16로 고정했습니다. 이는 2026년 8월 기준 최신 릴리스이며 2026년 7월 20일에 배포되었습니다. latest을 사용하지 않은 이유는 latest를 사용하면 가장 최근에 푸시된 이미지를 가져오게 되며, 6개월 뒤의 docker compose pull은 테스트하지 않은 서버 환경을 초래할 수 있기 때문입니다. network_mode: "host"은 호스트 인터페이스를 직접 바인딩합니다. 이는 RustDesk 문서에서 권장하는 방식이며 방화벽 동작 방식을 결정합니다. ./data:/root는 이미지의 작업 디렉터리를 호스트에 매핑하여 키 쌍을 백업 가능한 위치에 저장합니다. hbbr -k _은 업스트림 예제에서 변경한 유일한 부분입니다. 기본 설정은 릴레이를 누구나 사용할 수 있도록 개방하기 때문입니다. Compose 사용이 처음이라면 VPS에서 Docker Compose 실행하기를 통해 파일 형식과 생명주기 명령어를 확인하십시오.

hbbr을 다른 서버로 이전하는 경우, hbbs에 이전 위치를 알려주어야 합니다. -r relay.example.com:21117를 전달하거나 RELAY-SERVERS 환경 변수를 설정하십시오. 단일 서버 환경에서는 이 설정이 필요하지 않습니다.

Ed25519 키 쌍은 접근 제어의 핵심입니다

최초 실행 시 hbbs는 작업 디렉터리에 id_ed25519 및 id_ed25519.pub을 생성합니다. 위와 같이 마운트 설정을 하면 두 파일 모두 호스트에 나타납니다.

ls -l ~/rustdesk/data/
sudo cat ~/rustdesk/data/id_ed25519.pub

id_ed25519.pub에는 하나의 base64 문자열이 들어 있습니다. 이 문자열은 모든 클라이언트의 Key 필드에 입력됩니다. id_ed25519는 비공개 키이며 서버 외부로 유출되어서는 안 됩니다. 공개 키는 어차피 모든 클라이언트 설정에 복사되므로 비밀이 아닙니다. 하지만 비공개 키는 비밀입니다. 이를 탈취한 사람은 클라이언트가 신뢰하는 서버를 임의로 구축할 수 있습니다.

클라이언트 20대를 설정하기 전에 지금 바로 두 파일을 백업하십시오.

sudo tar czf ~/rustdesk-keys.tgz -C ~/rustdesk/data id_ed25519 id_ed25519.pub
sudo chmod 600 ~/rustdesk-keys.tgz

해당 아카이브를 서버 외부로 복사하십시오. 이 작업이 다른 어떤 단계보다 중요한 이유는 다음과 같습니다. ~/rustdesk/data을 삭제하거나 이를 복사하지 않은 채 새로운 VPS에서 재구축하면, hbbs는 다음 시작 시 새로운 키 쌍을 생성합니다. 모든 클라이언트는 여전히 이전 공개 키를 가지고 있으므로 hbbs는 연결을 거부하고 클라이언트는 오프라인 상태가 됩니다. sudo cat ~/rustdesk/data/id_ed25519.pub을 실행하여 클라이언트의 Key 필드와 비교해 보면 두 문자열이 더 이상 일치하지 않으며, 이 불일치가 모든 장애의 원인이 됩니다. 이를 해결하려면 RustDesk를 통해 원격 접속 중이던 기기를 포함하여 모든 기기의 설정을 수동으로 수정해야 합니다.

이 키는 세션 비밀번호가 아니며, 둘을 혼동하여 하나를 생략하는 경우가 많습니다. 키는 서버가 어떤 클라이언트와 통신할지를 결정합니다. 제어 대상 기기의 영구 비밀번호나 일회용 코드는 누가 해당 기기의 세션을 열 수 있는지를 결정합니다. 두 가지 모두 필요하며, 하나가 있다고 해서 다른 하나가 취약한 상태를 보완할 수는 없습니다.

인증되지 않은 릴레이가 문제가 되는 이유

기본 설정에서 hbbr은 아무것도 확인하지 않습니다. RustDesk 구성 문서에는 키가 비어 있으면 키가 일치하지 않는 클라이언트도 릴레이를 사용할 수 있다고 명시되어 있습니다. 이 기본값은 신규 사용자가 처음 실행할 때 키 불일치 오류를 겪지 않도록 하기 위해 존재합니다. 그 대가는 귀하의 주소를 TCP 21117 포트에서 찾아낸 누구나 귀하의 VPS를 통해 세션 트래픽을 전송할 수 있다는 점입니다. 이 경우 귀하의 전송 허용량을 소모하며, 귀하의 IP 주소에서 트래픽이 발생합니다.

command: hbbr -k _는 이 문제를 해결합니다. _ 인자는 hbbr이 작업 디렉터리에서 키 쌍을 불러오도록 지시하며, 두 컨테이너 모두 동일한 ./data를 마운트하므로 hbbs가 이미 생성한 키 쌍을 사용하게 됩니다. 수동으로 복사할 필요가 없으므로 설정이 어긋날 가능성이 없습니다.

공유 볼륨은 사용자가 가장 자주 실수하는 부분입니다. hbbr에 별도의 디렉터리를 지정하면 hbbr은 다른 키 쌍을 생성합니다. 이 경우 hbbs와 hbbr의 키가 서로 달라져 모든 릴레이 세션이 실패하고, 직접 연결 세션만 정상 작동하게 됩니다. 이 증상은 혼란을 야기합니다. RustDesk는 홀 펀칭(hole punching) 성공 여부에 따라 일부 피어와는 연결되지만 다른 피어와는 연결되지 않는 상태가 됩니다. ls -l ~/rustdesk/data/를 확인하여 id_ed25519 쌍이 하나만 존재하는지 확인하면 이 문제를 배제할 수 있습니다.

클라이언트에서 서버를 지정하기

각 머신에서 RustDesk를 열고 Settings, Network, ID/Relay Server 순으로 이동합니다.

ID Server: 호스트 이름을 입력합니다(예: rustdesk.example.com). 다른 포트를 지정하지 않으면 클라이언트는 21116 포트를 사용합니다.
Relay Server: hbbr이 hbbs와 동일한 호스트에서 실행 중이라면 비워 둡니다.
API Server: 비워 둡니다. 오픈 소스 서버는 API를 제공하지 않습니다.
Key: id_ed25519.pub에 있는 base64 문자열을 복사하여 붙여넣습니다. 이때 뒤에 공백이 포함되지 않도록 주의하십시오.

메인 창에 클라이언트가 준비되었다는 상태가 표시되어야 합니다. 만약 표시되지 않는다면 UDP 21116 포트가 hbbs에 도달하지 못하는 상태입니다. 등록 및 하트비트 과정은 UDP를 통해서만 이루어지며, 이외의 다른 방법으로는 ID를 온라인 상태로 만들 수 없습니다.

릴레이가 개방형 서비스가 되지 않도록 포트 제한하기

컨테이너가 호스트 네트워킹을 사용하므로 컨테이너 앞단에 Docker NAT 규칙이 존재하지 않으며, 따라서 ufw 규칙이 예상대로 적용됩니다.

sudo ufw allow 22/tcp
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udp
sudo ufw enable
sudo ufw status numbered

브라우저 클라이언트를 실행하는 경우에만 21118:21119/tcp를 추가하십시오. ufw를 활성화하는 동안 SSH 세션을 하나 더 열어두어, SSH 규칙 설정 실수로 서버에서 차단되는 일을 방지하십시오. VPS를 위한 ufw 방화벽 기초에서 기본 정책과 규칙 우선순위에 대해 다룹니다.

이제 주의할 점입니다. RustDesk supervisor 이미지 예제에서 사용하는 방식처럼 ports: 블록을 사용하여 포트를 게시하도록 전환하면, Docker가 자체 DNAT 규칙을 작성합니다. 이 경우 패킷은 ufw 규칙이 위치한 체인을 거치지 않고 컨테이너에 도달합니다. 따라서 21117 포트에 ufw deny를 설정해도 효과가 없으며, ufw status 설정과는 무관하게 릴레이가 인터넷에 개방됩니다. Docker 게시 포트가 ufw를 우회하는 현상에서 체인 순서에 대해 설명합니다. 호스트 네트워킹을 사용하면 이 문제를 완전히 피할 수 있습니다. 포트를 게시해야 한다면, "127.0.0.1:21118:21118"와 같이 리버스 프록시 뒤에서 특정 주소에만 바인딩하십시오.

소스 주소에 의한 제한은 클라이언트가 고정 주소를 가질 때만 유효합니다.

sudo ufw allow from 203.0.113.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 21116 proto udp

호텔 네트워크를 사용하는 노트북은 고정 주소를 갖지 않으며, 바로 이 점 때문에 방화벽보다 hbbr의 키가 여기서 더 실질적인 역할을 수행합니다.

키를 포함하는 스택 업그레이드

키는 컨테이너 내부가 아닌 바인드 마운트(bind mount)에 저장되므로, ./data을 건드리지 않는 한 업그레이드는 안전합니다.

먼저 데이터 디렉터리를 백업하십시오: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
rustdesk-server 릴리스 페이지에서 새 태그에 대한 릴리스 노트를 읽어보십시오.
compose.yml를 편집하여 두 개의 image: 라인을 새 태그로 변경하십시오.
sudo docker compose pull을 실행한 다음 sudo docker compose up -d을 실행하십시오.
sudo cat ~/rustdesk/data/id_ed25519.pub를 실행하여 해당 문자열이 클라이언트가 이미 보유한 것과 일치하는지 확인하십시오.

5단계는 가장 중요한 확인 과정입니다. 서버에서 키가 변경되면 별도의 오류 메시지 없이 모든 클라이언트와의 연결이 즉시 끊기기 때문입니다. 롤백은 이전 태그로 되돌리고 up -d을 다시 실행하는 방식인데, 이는 태그를 고정해 두었을 때만 가능합니다. latest을 사용하면 docker compose pull가 이름을 새 이미지로 옮겨버리기 때문에, 이전 이미지를 가리키는 태그가 남지 않게 됩니다.

키를 잃어버리는 일반적인 원인은 바인드 마운트를 그대로 두는 docker compose down이 아닙니다. 새로운 VPS로 마이그레이션하면서 compose.yml만 복사하는 경우입니다. 반드시 ./data도 함께 복사하십시오.

전송 허용량이 있는 플랜에서 송신 트래픽 모니터링하기

hbbr은 이 스택에서 전송 허용량을 소모할 수 있는 유일한 구성 요소입니다. RustDesk의 FAQ에 따르면 1920x1080 화면에서 릴레이 연결 하나당 30 KB/s에서 3 MB/s의 트래픽이 발생하며, 일반적인 사무 작업 시에는 약 100 KB/s가 소모됩니다. 이는 단일 세션에 대한 공개된 수치일 뿐, 사용자의 환경을 직접 측정한 값은 아닙니다. 이를 한 달 60시간(하루 2시간) 기준으로 계산하면 다음과 같습니다.

ChartVPS egress from one relayed RustDesk session, 60 hours per month

label

gb_per_month

Low end, 30 KB/s

6.5

Office work, 100 KB/s

21.6

High end, 3 MB/s

648

The data behind this chart

[
  {
    "label": "Low end, 30 KB/s",
    "gb_per_month": 6.5
  },
  {
    "label": "Office work, 100 KB/s",
    "gb_per_month": 21.6
  },
  {
    "label": "High end, 3 MB/s",
    "gb_per_month": 648
  }
]

사무 작업 속도로 계산하면 한 세션당 월간 약 21.6 GB를 사용하게 되며, 이는 어떤 플랜에서도 문제가 되지 않는 수준입니다. 공개된 범위의 최댓값으로 60시간을 계산하면 648 GB가 되며, 동일한 속도로 두 세션을 동시에 유지할 경우 한 달 안에 1 TB 허용량을 모두 소모하게 됩니다. 최솟값은 6.5 GB입니다. 여기서 기가바이트는 전송 허용량 산정의 일반적인 기준인 1000 MB를 의미합니다.

docker stats은 이를 세부적으로 분석해주지 않습니다. 호스트 네트워킹을 사용하는 컨테이너는 호스트의 네트워크 네임스페이스를 공유하므로, 컨테이너의 카운터가 곧 호스트의 카운터가 되기 때문입니다. 대신 두 가지 도구를 사용할 수 있습니다. vnstat은 전체 서버의 트래픽을 측정합니다.

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

전체 서버를 측정한다는 것은 말 그대로 전체를 의미합니다. 만약 이 VPS에서 자체 호스팅 사진 서버와 같이 매일 밤 휴대폰 라이브러리를 동기화하는 등 대용량 데이터를 처리하는 서비스가 함께 실행 중이라면, 해당 업로드 트래픽도 릴레이 트래픽과 동일한 월간 합계에 포함됩니다.

nftables 카운터를 사용하면 릴레이 트래픽만 구체적으로 측정할 수 있습니다.

sudo nft add table inet relaymeter
sudo nft add chain inet relaymeter out '{ type filter hook output priority 0 ; }'
sudo nft add rule inet relaymeter out tcp sport 21117 counter
sudo nft list table inet relaymeter

이 규칙은 판정이 없으므로 허용되는 항목을 변경하지 않고 패킷과 바이트만 계산한다. 또한 별도의 테이블에 배치되므로 ufw에 영향을 주지 않는다. 이 설정은 영구적이지 않다. 재부팅 후에도 다시 적용하려면 동일한 줄을 /etc/nftables.conf에 넣는다. 카운터는 세션이 실제로 릴레이되는 동안에만 증가한다. 자체 시스템이 연결되어 있지 않은데도 카운터가 계속 증가한다면 다른 누군가가 릴레이를 발견했다는 의미다. 이 상황을 방지하기 위해 hbbr -k _가 존재한다. 매일 아침 nft list를 직접 확인하지는 않을 것이므로, 바이트 수를 임계값과 비교하고 임계값을 넘으면 푸시 알림을 보내는 cron 작업을 설정한다. 이 작업에는 자체 ntfy 서버를 사용한다.

hbbr에는 낮출 수 있는 속도 제한 설정도 있습니다. SINGLE_BANDWIDTH은 릴레이 연결당 기본값이 128 Mb/s이며, TOTAL_BANDWIDTH은 전체 연결 합계에 대해 1024 Mb/s로 설정되어 있습니다. SINGLE_BANDWIDTH=8를 설정하면 한 세션의 속도를 약 1 MB/s로 제한할 수 있습니다. 이는 월간 총 사용량이 아닌 속도를 제한하는 것이므로, 예산 관리보다는 특정 세션이 네트워크 대역폭을 독점하는 것을 방지하는 용도로 사용하십시오.

릴레이가 전혀 필요하지 않은 경우

개인용 설정이라면, 솔직히 이 모든 과정이 필요하지 않을 수 있습니다. 두 기기를 모두 메시 VPN에 연결하고 터널 주소로 직접 접속하십시오. hbbs나 hbbr, 릴레이 송신(egress), VPS에서 업그레이드해야 할 컨테이너도 없습니다.

제어하려는 기기에서 RustDesk 보안 설정의 직접 IP 접근(direct IP access)을 활성화하십시오. 포트 필드는 기본값으로 21118이 설정됩니다. 연결을 시도하기 전에 해당 포트가 리스닝 상태인지 확인하십시오.

ss -tlnp | grep 21118

그런 다음 ID 대신 해당 피어의 VPN 주소로 연결하십시오. RustDesk의 FAQ에 따르면 이 모드의 연결은 암호화되지 않으므로, 반드시 터널 내부에서 실행하고 개방된 인터넷을 통해 직접 연결하지 마십시오. 암호화는 터널이 담당합니다.

기기 소유주에 따라 방식을 선택하십시오. 본인 소유가 아닌 기기를 지원하거나 VPN 클라이언트를 설치할 수 없는 사용자를 상대할 때는 ID와 비밀번호만으로 설정이 가능한 자체 호스팅 hbbs 및 hbbr이 적합합니다. 모든 기기가 본인 소유이고 키를 설치할 수 있는 환경이라면 직접 IP 접근을 사용하는 메시 VPN이 적합합니다. WireGuard와 Tailscale 비교에서는 이러한 메시 네트워크를 구축하는 두 가지 일반적인 방법을 다루며, Linux VPS에서 원격 데스크톱 실행하기에서는 화면을 공유하려는 기기가 서버 자체인 다른 경우를 다룹니다.

FAQ

모든 RustDesk 세션이 내 릴레이를 거쳐서 통신합니까?

아니요. hbbs는 먼저 두 클라이언트 사이의 NAT를 통과하는 홀 펀칭(hole punching)을 시도하여 직접 연결을 맺으려 합니다. 이 과정이 실패한 세션만 hbbr로 전환되며, 이때만 대역폭이 소모됩니다. 예외적으로 hbbs에서 ALWAYS_USE_RELAY=Y을 설정하면 직접 연결 경로가 있더라도 모든 세션이 hbbr을 거치도록 강제됩니다. Compose 파일에 해당 변수가 설정되어 있다면, 모든 세션의 데이터가 전송량 청구 대상이 됩니다.

RustDesk 서버 키는 어디에 저장되며, 분실하면 어떻게 됩니까?

hbbs는 최초 실행 시 작업 디렉터리에 id_ed25519와 id_ed25519.pub를 생성합니다. 공식 이미지 내부의 해당 디렉터리는 /root이므로, 위에서 설명한 볼륨 마운트를 사용하면 호스트의 ./data 경로에 파일이 나타납니다. 두 파일을 서버 외부로 백업하십시오. 파일을 분실하여 hbbs가 재시작 시 새 키 쌍을 생성하면, 기존 공개 키를 가진 모든 클라이언트의 연결이 거부됩니다. 이 경우 모든 클라이언트의 Key 필드를 수동으로 수정하는 것 외에는 복구 방법이 없습니다.

자체 호스팅 RustDesk 서버를 위해 열어야 할 포트는 무엇입니까?

TCP 21115, 21116, 21117 포트와 UDP 21116 포트가 필요합니다. hbbs는 NAT 유형 테스트에 21115를 사용하며, UDP를 통한 ID 등록 및 하트비트와 TCP를 통한 홀 펀칭에 21116을 사용합니다. hbbr은 릴레이를 위해 21117을 사용합니다. TCP 21118과 21119는 브라우저 클라이언트를 위한 WebSocket 포트이므로, 사용하지 않는다면 닫아 두십시오. TCP 21114는 Pro 웹 콘솔용이며 오픈 소스 빌드에서는 필요하지 않습니다.

낯선 사람이 내 자체 호스팅 RustDesk 릴레이를 사용할 수 있습니까?

네, hbbr을 기본 설정으로 실행하면 가능합니다. RustDesk 문서에 따르면 키가 비어 있으면 키가 일치하지 않는 클라이언트도 릴레이를 사용할 수 있으므로, 호스트 이름과 21117 포트를 알아낸 누구나 서버를 통해 트래픽을 보낼 수 있습니다. hbbr을 -k _ 옵션으로 실행하여 hbbs가 생성한 키 쌍을 공유 ./data 볼륨에서 불러오도록 하십시오. 이렇게 설정하면 공개 키가 구성된 클라이언트만 릴레이를 사용할 수 있습니다.

#rustdesk #remote-desktop #docker #self-hosting #firewall