Kendi RustDesk Relay Sunucunuzu Kurma Rehberi

Self-hosted RustDesk relay sunucusu nedir

Self-hosted bir RustDesk relay sunucusu, tek bir VPS üzerinde çalışan iki daemon'dan oluşur. hbbs, ID ve rendezvous sunucusudur; her istemci ID'sini kaydeder ve iki istemciyi birbirine tanıtır. hbbr ise relay sunucusudur; doğrudan bağlantı kurulamayan oturumlar için veri trafiğini taşır. Çoğu kılavuz her ikisini de kurup eşleşmeyi sağlar ve orada durur. Aşağıdaki bölümler işin geri kalanını kapsamaktadır: erişim kontrolünüzü sağlayan anahtar, portlar, yükseltme işlemleri ve bant genişliği yönetimi.

Her iki daemon da aynı imaj olan rustdesk/rustdesk-server içerisinde gelir ve aynı dizin içerisindeki aynı Ed25519 anahtar çiftini okur. Ed25519, bir açık anahtar imza şemasıdır. Bu anahtar çifti, sunucunuzun hangi istemcilerle iletişim kuracağını belirler ve arkasında herhangi bir kullanıcı veritabanı bulunmaz.

hbbs ve hbbr: hangi daemon bant genişliği tüketir

hbbs trafiği düşük ve sabittir: ID kaydı, sinyal (heartbeat) iletimi ve iki istemciyi birbirine tanıtan kısa süreli veri alışverişi. Tüm gün çalışır ve neredeyse hiç bant genişliği tüketmez.

hbbr trafiği ise oturumun kendisidir. Ekran görüntüleri bir yöne, klavye ve fare verileri diğer yöne akar; aktarılan her bayt önce VPS sunucunuza gelir, ardından oradan çıkar. Sağlayıcınız yalnızca çıkış (egress) trafiğini ücretlendiriyorsa, aktarılan bir oturum yaklaşık oturum hızı kadar maliyet oluşturur. Eğer toplam transferi ücretlendiriyorsa, maliyet bunun yaklaşık iki katı olur.

Röle (relay) bir yedekleme mekanizmasıdır, normal yol değildir. hbbs, her iki istemciyi doğrudan birbirine bağlamayı dener; bunu her iki tarafın önündeki NAT (network address translation) üzerinden delik açma (hole punching) yöntemiyle yapar. Bu yöntem başarılı olduğunda, oturum hbbr üzerinden geçmez ve transfer kotanız etkilenmez. Taraflardan biri her hedef için yeni bir port atayan bir NAT arkasındaysa veya güvenlik duvarı açılan yolu engelliyorsa, oturum hbbr üzerinden devam eder ve her kare VPS sunucunuz üzerinden geçer.

Bir ortam değişkeni bu seçeneği ortadan kaldırır. hbbs üzerindeki ALWAYS_USE_RELAY=Y, tüm oturumları hbbr üzerinden geçmeye zorlar. RustDesk belgeleri bunu Compose örneklerinden birinde gösterdiği için sıkça kopyalanmaktadır. Bu ayar bağlantıları daha öngörülebilir kılar ve çıkış trafiğinizi gerçek bir maliyete dönüştürür. Bu ayarı, kopyala-yapıştır yaptığınız için değil, bilinçli bir tercih olarak kullanın.

Self-hosted bir RustDesk sunucusu hangi portlara ihtiyaç duyar

Aşağıdaki port numaraları, 17 Ağustos 2026 tarihinde RustDesk sunucu belgeleri ve rustdesk-server deposu üzerinden kontrol edilmiştir.

• TCP 21115, hbbs üzerinde: NAT türü testi.
• UDP 21116, hbbs üzerinde: Kimlik kaydı ve sinyal (heartbeat). Bu port açık olmadığı sürece istemci çevrimiçi olmaz.
• TCP 21116, hbbs üzerinde: TCP delik açma (hole punching) ve bağlantı servisi.
• TCP 21117, hbbr üzerinde: Aktarıcı (relay). Oturum verilerini taşıyan port budur; dolayısıyla trafik maliyetini oluşturan porttur.
• TCP 21118 (hbbs üzerinde) ve TCP 21119 (hbbr üzerinde): Tarayıcı istemcisi tarafından kullanılan WebSocket. Kullanmıyorsanız her ikisini de kapalı tutun.
• TCP 21114: RustDesk Server Pro sürümündeki web konsoludur. Açık kaynaklı sürüm bu portu dinlemez.

hbbs ve hbbr servislerini sabitlenmiş imaj etiketiyle kurun

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

Her iki servis de running dosyasını okumalıdır. Güvenlik duvarı ayarlarını yapmadan önce dinleyicilerin aktif olduğunu doğrulayın.

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

21115, 21116 ve 21117 portlarında TCP dinleyicilerini, 21116 portunda ise bir UDP dinleyicisini görmelisiniz. UDP satırının eksik olması hbbs servisinin çalışmadığı anlamına gelir; çünkü istemciler kayıt işlemini bu dinleyici üzerinden gerçekleştirir.

Bu dosyadaki dört unsur bilinçli olarak seçilmiştir. Etiket, latest yerine 20 Temmuz 2026 tarihinde yayınlanmış ve Ağustos 2026 itibarıyla güncel sürüm olan 1.1.16 olarak belirlenmiştir. Bunun nedeni, latest etiketinin en son gönderilen sürümü ifade etmesi ve altı ay sonraki bir docker compose pull sürümünün, daha önce test etmediğiniz bir sunucu yapısını karşınıza çıkarabilmesidir. network_mode: "host", RustDesk dokümantasyonunun önerdiği şekilde ana makine arayüzlerini doğrudan bağlar ve güvenlik duvarınızın davranışını belirler. ./data:/root, imajın çalışma dizinini ana makineye eşler; böylece anahtar çifti yedekleyebileceğiniz bir konumda saklanır. hbbr -k _ ise orijinal örnekten yapılan tek değişikliktir, çünkü varsayılan ayar röle sunucunuzu herkese açık bırakır. Eğer Compose yapısı sizin için yeniyse, VPS üzerinde Docker Compose çalıştırma rehberi dosya formatını ve yaşam döngüsü komutlarını kapsamlı bir şekilde açıklar.

Eğer hbbr ileride ikinci bir sunucuya taşınırsa, hbbs servisine yeni konumu bildirilmelidir: -r relay.example.com:21117 parametresini geçin veya RELAY-SERVERS ortam değişkenini ayarlayın. Tek bir sunucu üzerinde çalışıyorsanız buna gerek yoktur.

Ed25519 anahtar çifti erişim kontrolünü sağlar

hbbs ilk kez başlatıldığında, çalışma dizininde id_ed25519 ve id_ed25519.pub dosyalarını oluşturur. Yukarıdaki mount işlemi sayesinde her iki dosya da ana makinede görünür hale gelir.

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

id_ed25519.pub tek bir base64 dizgisi içerir. Bu dizgi, her istemcideki Key alanına girilmelidir. id_ed25519 özel anahtar kısmıdır ve sunucudan asla dışarı çıkarılmamalıdır. Genel anahtar gizli değildir, çünkü zaten her istemci yapılandırmasına kopyalanır. Özel anahtar ise gizlidir: bu anahtara sahip olan herkes, istemcilerinizin güveneceği bir sunucu kurabilir.

Yirmi istemciyi yapılandırmadan önce her iki dosyanın da yedeğini alın.

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

Bu arşivi sunucudan başka bir yere kopyalayın. Bunun diğer tüm adımlardan daha önemli olmasının nedeni şudur: ~/rustdesk/data dosyasını silerseniz veya kopyalamadan yeni bir VPS üzerinde yeniden kurulum yaparsanız, hbbs bir sonraki başlatmada yeni bir anahtar çifti oluşturur. Her istemci eski genel anahtarı taşımaya devam ettiği için hbbs bağlantıyı reddeder ve istemci çevrimdışı olur. sudo cat ~/rustdesk/data/id_ed25519.pub komutunu çalıştırıp çıktısını herhangi bir istemcideki Key alanı ile karşılaştırırsanız, iki dizginin artık eşleşmediğini görürsünüz; bu uyumsuzluk hatanın temel nedenidir. Sorunu düzeltmek, RustDesk üzerinden erişmeyi planladığınız makineler de dahil olmak üzere her cihazdaki ayarları manuel olarak düzenlemeniz gerektiği anlamına gelir.

Bu anahtar oturum parolası değildir; ikisini karıştırmak, birini atlamanıza neden olur. Anahtar, sunucunuzun hangi istemcilerle iletişim kuracağını belirler. Kontrol edilen makinedeki kalıcı parola veya tek kullanımlık kod ise o makinede kimin oturum açabileceğini belirler. Her ikisine de ihtiyacınız vardır ve birinin varlığı diğerindeki zayıflığı telafi etmez.

Kimlik doğrulaması yapılmayan bir rölenin oluşturduğu sorunlar

Varsayılan olarak hbbr hiçbir şeyi denetlemez. RustDesk yapılandırma belgeleri bunu açıkça belirtir: boş bir anahtar, eşleşen bir anahtarı olmayan istemcilerin röleyi kullanmasına izin verir. Boş varsayılan değer, yeni kullanıcıların ilk çalıştırmada anahtar uyuşmazlığı hatalarıyla karşılaşmaması için mevcuttur. Bunun bedeli, TCP 21117 üzerindeki adresinizi bulan herkesin, sizin IP adresiniz üzerinden ve sizin veri transfer kotanızı kullanarak kendi oturum trafiğini VPS'iniz üzerinden geçirebilmesidir.

command: hbbr -k _ bu durumu engeller. _ argümanı, hbbr'ye çalışma dizininden bir anahtar çifti yüklemesini söyler ve her iki container da aynı ./data dizinini mount ettiği için, bu hbbs'nin zaten oluşturmuş olduğu anahtar çiftidir. Elle hiçbir şey kopyalanmaz, bu nedenle tutarsızlık oluşamaz.

Paylaşılan birim (volume), insanların hata yaptığı kısımdır. hbbr'ye kendi dizinini verirseniz farklı bir anahtar çifti oluşturur. Bu durumda hbbs ve hbbr uyumsuz hale gelir, röle üzerinden kurulan tüm oturumlar başarısız olur ancak doğrudan oturumlar çalışmaya devam eder. Belirti kafa karıştırıcıdır: RustDesk, hole punching işleminin başarılı olup olmamasına bağlı olarak bazı eşlere ulaşabilirken diğerlerine ulaşamaz. Tek bir id_ed25519 çiftini gösteren bir ls -l ~/rustdesk/data/ komutu, bu sorunu ortadan kaldırır.

İstemcileri sunucunuza yönlendirin

Her makinede RustDesk uygulamasını açın, ardından Settings, Network ve son olarak ID/Relay Server menüsüne gidin.

• ID Server: ana bilgisayar adınız (hostname), örneğin rustdesk.example.com. Farklı bir port belirtmediğiniz sürece istemci 21116 numaralı portu kullanır.
• Relay Server: hbbr, hbbs ile aynı sunucuda çalışıyorsa bu alanı boş bırakın.
• API Server: boş bırakın. Açık kaynaklı sunucu bir API sağlamaz.
• Key: id_ed25519.pub dosyasındaki base64 dizisini, sonunda boşluk kalmayacak şekilde tam olarak buraya yapıştırın.

Ana pencerede istemcinin hazır olduğu bilgisi görünmelidir. Eğer görünmüyorsa, UDP 21116 trafiği hbbs sunucusuna ulaşmıyor demektir; çünkü kayıt ve sinyal (heartbeat) işlemleri UDP üzerinden yürütülür ve ID'yi çevrimiçi hale getiren başka bir mekanizma yoktur.

Rölenin açık bir servis olmaması için portları kısıtlayın

Container'lar host networking kullandığı için önlerinde bir Docker NAT kuralı bulunmaz; bu nedenle ufw kuralları beklediğiniz şekilde uygulanır.

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 ifadesini yalnızca tarayıcı istemcisini çalıştırıyorsanız ekleyin. ufw'yi etkinleştirirken ikinci bir SSH oturumunu açık tutun; böylece SSH kuralındaki bir hata sunucunuzdan dışarı atılmanıza neden olmaz. VPS için ufw güvenlik duvarı temelleri, varsayılan politikaları ve kural sıralamasını ele alır.

Şimdi kritik noktaya gelelim. Eğer alternatif RustDesk supervisor image örneğinde olduğu gibi ports: bloğu ile portları dışarı açarsanız, Docker kendi DNAT kurallarını yazar ve paketler, ufw kurallarınızın bulunduğu zincirden geçmeden doğrudan container'a ulaşır. Bu durumda 21117 portuna uygulanan bir ufw deny kuralı etkisiz kalır ve ufw status aksini iddia etse de röle internete açık hale gelir. Docker ile dışarı açılan portların ufw'yi devre dışı bırakması, zincir sırasını açıklar. Host networking kullanımı bu sorunu tamamen ortadan kaldırır. Eğer bir portu dışarı açmanız gerekiyorsa, "127.0.0.1:21118:21118" örneğinde olduğu gibi bir reverse proxy arkasında tek bir adrese bağlayın.

Kaynak adrese göre kısıtlama yapmak, yalnızca istemcilerinizin sabit adresleri olduğunda işe yarar.

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

Otel ağlarındaki dizüstü bilgisayarlar sabit adreslere sahip değildir; işte tam da bu yüzden hbbr üzerindeki anahtar, burada güvenlik duvarından çok daha fazla işlev görür.

Anahtarınızı barındıran bir stack'i yükseltme

Anahtar, container içinde değil bind mount üzerinde tutulduğu için ./data dosyasını değiştirmediğiniz sürece yükseltme işlemi güvenlidir.

1. Öncelikle veri dizinini yedekleyin: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. rustdesk-server sürümleri sayfasından yeni etiket (tag) için yayın notlarını okuyun.
3. compose.yml dosyasını düzenleyin ve her iki image: satırını da yeni etiket ile değiştirin.
4. sudo docker compose pull komutunu, ardından sudo docker compose up -d komutunu çalıştırın.
5. sudo cat ~/rustdesk/data/id_ed25519.pub komutunu çalıştırın ve dizinin istemcilerinizde halihazırda kayıtlı olanla aynı olduğunu doğrulayın.

1. adım en kritik kontrol noktasıdır; çünkü değişen bir anahtar sunucu tarafında sessiz kalır ancak tüm istemcilerin bağlantısını aynı anda koparır. Geri alma işlemi, eski etiketi tekrar yazıp up -d komutunu çalıştırmaktan ibarettir. Bu yöntem yalnızca etiketi sabitlediğiniz (pin) durumlarda işe yarar: latest kullanıldığında docker compose pull ismi yeni imaja taşıdığı için, eskisini işaret eden bir etiket kalmaz.

Anahtarı kaybetmenin yaygın yolu docker compose down işlemi değildir; çünkü bu işlem bind mount'a dokunmaz. Asıl risk, yeni bir VPS'e geçiş yaparken sadece compose.yml dosyasını kopyalamaktır. ./data dosyasını da onunla birlikte kopyaladığınızdan emin olun.

Transfer kotası olan bir planda çıkış trafiğini izleme

hbbr, bu yığının transfer kotasını tüketebilen tek parçasıdır. RustDesk'in FAQ bölümü, 1920x1080 çözünürlüklü bir ekrandaki aktarımlı bağlantının 30 KB/s ile 3 MB/s arasında veri tükettiğini, standart ofis işlerinin ise yaklaşık 100 KB/s civarında olduğunu belirtir. Bunlar tek bir oturum için yayınlanan verilerdir, sizin kurulumunuzun ölçümü değildir. Ayda altmış saat, yani günde iki saat üzerinden hesaplandığında sonuçlar şu şekildedir.

[
  {
    "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
  }
]

Ofis işi hızında bir oturum ayda yaklaşık 21.6 GB tüketir; bu miktar hiçbir planda fark edilmez. Yayınlanan aralığın üst sınırında aynı altmış saat 648 GB tutar ve bu hızda iki eş zamanlı oturum, 1 TB'lık kotayı ay içinde bitirir. Alt sınır ise 6.5 GB'tır. Buradaki gigabaytlar, transfer kotalarının normalde hesaplandığı gibi 1000 MB olarak alınmıştır.

docker stats bunu sizin için ayrıştırmayacaktır; çünkü host networking kullanan bir container, host'un ağ ad alanını paylaşır, dolayısıyla sayaçları host'un sayaçlarıdır. Başka iki araç işe yarar. vnstat tüm sunucuyu ölçer:

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

Tüm sunucu demek, tüm sunucu demektir: Eğer bu VPS, her gece telefon kütüphanelerini çeken self-hosted fotoğraf sunucuları gibi gerçek veri taşıyan başka bir şey çalıştırıyorsa, bu yüklemeler relay trafiğinizle aynı aylık satıra yazılır. Bir medya sunucusu da diğer uçtan bakıldığında aynı durumdadır; çünkü Jellyfin kütüphanesini 90'ların video dükkanına dönüştüren Halcyon gibi bir yazılım izleyen herkese yayın yapar ve bu çıkış trafiği, relay'inizin kullandığı kotayı paylaşır.

Bir nftables sayacı, relay'i özel olarak ölçer:

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

Bu kural herhangi bir karar (verdict) içermez, bu nedenle izin verilenleri değiştirmeden paketleri ve baytları sayar ve kendi tablosunda durduğu için ufw'yi rahatsız etmez. Kalıcı değildir: Yeniden başlatma sonrasında geri gelmesini istiyorsanız aynı satırları /etc/nftables.conf içine ekleyin. Sayaç sadece bir oturum aktif olarak aktarılıyorken artar. Kendi makinelerinizden hiçbiri bağlı değilken artmaya devam eden bir sayaç, bir başkasının relay'inizi bulduğu anlamına gelir; bu, hbbr -k _'un önlemek için var olduğu durumdur. nft list'ı her sabah okumayacağınız için, bayt sayısını bir eşik değerle karşılaştıran ve aşıldığında push bildirimi gönderen bir cron işi kurun; bu, kendi ntfy sunucunuz için uygun bir görevdir.

hbbr'nin ayrıca düşürebileceğiniz hız sınırları vardır. SINGLE_BANDWIDTH varsayılan olarak relay bağlantısı başına 128 Mb/s, TOTAL_BANDWIDTH ise tüm bağlantılar için toplam 1024 Mb/s değerindedir. SINGLE_BANDWIDTH=8 ayarını yapmak, bir oturumu 1 MB/s civarında sınırlar. Bu, aylık toplamı değil hızı sınırlar, bu yüzden bunu bir bütçe kontrolü olarak değil, tek bir oturumun hattı doyurmasını engellemenin bir yolu olarak değerlendirin.

Hiç röleye ihtiyaç duymadığınız durumlar

Kişisel bir kurulum için dürüst cevap, bunların hiçbirine ihtiyaç duymayabileceğinizdir. Her iki makineyi de bir mesh VPN ağına dahil edin ve doğrudan tünel adresi üzerinden bağlantı kurun. Bu durumda hbbs, hbbr, röle çıkışı veya yükseltilmesi gereken bir VPS container'ı olmaz.

Kontrol etmek istediğiniz makinede, RustDesk'in güvenlik ayarlarından doğrudan IP erişimini etkinleştirin. Port alanı varsayılan olarak 21118 değerindedir. Bağlanmayı denemeden önce portun dinlemede olduğunu doğrulayın:

ss -tlnp | grep 21118

Ardından bir ID yerine ilgili eşin VPN adresine bağlanın. RustDesk'in SSS bölümü bu moddaki bağlantının şifrelenmemiş olduğunu belirtir; bu nedenle bağlantıyı mutlaka tünel içinde çalıştırın ve asla açık internet üzerinden gerçekleştirmeyin. Şifrelemeyi sağlayan yapı tünelin kendisidir.

Seçiminizi makinelerin sahibine göre yapın. Kendi kendine barındırılan (self-hosted) hbbs ve hbbr, size ait olmayan makineleri desteklediğinizde veya VPN istemcisi kurmayacak kişilerle çalıştığınızda uygundur; çünkü bu kişilerin tarafındaki kurulum yalnızca bir ID ve paroladan ibarettir. Mesh VPN ve doğrudan IP erişimi ise tüm makineler size ait olduğunda ve bir anahtar taşıyabildiğinde doğrudur. WireGuard ve Tailscale karşılaştırması, bu mesh yapısını oluşturmanın iki yaygın yolunu ele alır; Linux VPS üzerinde uzak masaüstü çalıştırma ise ekranına erişmek istediğiniz makinenin bizzat sunucunun kendisi olduğu diğer durumu kapsar.

FAQ

Her RustDesk oturumu benim relay sunucum üzerinden mi geçer?

Hayır. hbbs, her iki istemcinin önündeki NAT üzerinden hole punching yöntemini kullanarak önce doğrudan bağlantı kurmayı dener. Yalnızca bu işlemin başarısız olduğu oturumlar hbbr'ye geri döner ve sadece bu oturumlar bant genişliği tüketir. Bunun istisnası, hbbs üzerindeki ALWAYS_USE_RELAY=Y değişkenidir; bu değişken, doğrudan bir yol olup olmadığına bakılmaksızın her oturumu hbbr üzerinden geçmeye zorlar. Eğer bu değişken Compose dosyanızda tanımlıysa, her oturumun her baytı transfer faturanıza yansır.

RustDesk sunucu anahtarı nerede saklanır ve kaybedersem ne olur?

hbbs, ilk başlatıldığında çalışma dizininde id_ed25519 ve id_ed25519.pub dosyalarını oluşturur. Resmi imaj içerisinde bu dizin /root konumundadır, dolayısıyla yukarıda gösterilen volume mount işlemi ile dosyalar ana makinede ./data dizininde görünür hale gelir. Her iki dosyayı da sunucu dışında yedekleyin. Eğer dosyalar kaybolursa, hbbs bir sonraki başlatmada yeni bir çift oluşturur ve eski genel anahtarı tutan tüm istemcilerin bağlantısı reddedilir. Bu durumda, her istemcideki Key alanını manuel olarak düzenlemek dışında bir kurtarma yöntemi yoktur.

Kendi kendine barındırılan (self-hosted) bir RustDesk sunucusu için hangi portları açmalıyım?

TCP 21115, 21116 ve 21117 ile birlikte UDP 21116 portları. hbbs, NAT türü testi için 21115'i, ID kaydı ve UDP üzerinden heartbeat ile TCP üzerinden hole punching işlemleri için 21116'yı kullanır. hbbr ise relay için 21117 portunu kullanır. TCP 21118 ve 21119, tarayıcı istemcisi için WebSocket portlarıdır; bu nedenle kullanmıyorsanız kapalı tutun. TCP 21114, Pro web konsoluna aittir ve açık kaynaklı sürüm için gerekli değildir.

Yabancılar kendi kendine barındırdığım RustDesk relay sunucumu kullanabilir mi?

Evet, eğer hbbr'yi varsayılan yapılandırmasıyla çalıştırırsanız. RustDesk belgeleri, boş bir anahtarın, eşleşen bir anahtara sahip olmayan istemcilerin relay kullanmasına izin verdiğini belirtir; bu nedenle sunucu adınızı ve 21117 numaralı portu öğrenen herkes sunucunuz üzerinden trafik geçirebilir. hbbr'yi -k _ ile çalıştırarak, hbbs tarafından paylaşılan ./data volume dizininde oluşturulan aynı anahtar çiftini yüklemesini sağlayın. Bu işlemden sonra, yalnızca genel anahtarınızla yapılandırılmış istemciler sizin üzerinizden relay yapabilir.