Kendi sunucunuzda uzak masaüstü — 2026 rehberi

"Kendi sunucunuzda barındırılan uzak masaüstü" için arama yaptığınızda, çoğu rehber docker compose up -d ile sona erer. Kurulum kolay kısmıdır ve gerçekten 30 dakika sürer. Bu rehber tüm kurulumu kapsar — ardından da şu soruyu cevaplayan kısmı anlatır: eğitim bitince, çalışır durumda tutmanın maliyeti nedir?

Kısa cevap

Kendi sunucunuzda barındırın yalnızca bir gereklilik sizi zorladığında. Hiçbir gereklilik yoksa yönetilen bir relay kullanın. Bu basit geliyor; işte gerçek testi:

• Kendi sunucunuzda barındırın eğer: yazılı bir uyumluluk yükümlülüğü oturum trafiğinin üçüncü taraf altyapısından geçmemesini şart koşuyorsa; dış relay'e ulaşılamayan air-gapped veya başka şekilde kısıtlı ağlar işletiyorsanız; ya da veri ikamet kuralları sizi belirli bir yargı içinde tutmanızı gerektiriyorsa.
• Yönetilen bir relay kullanın eğer: nedeniniz herhangi bir çeşidiyle "Kendi sunucumu çalıştırmayı tercih ederim." ise. Bu gerçek bir tercihdir, ama aynı zamanda devam eden bir işletme işi demektir — aşağıdaki faturaya bakmadan üzerine imza atmayın.

Ne arasında seçim yaptığınız net olsun; çünkü bun iki farklı ürün değil. Tenvo AGPL-3.0 lisanslıdır ve yönetilen relay aynı hbbs/hbbr mimarisini çalıştırır; karar sunucuyu kimin işlettiğidir, yazılımın ne yaptığı değil.

Önce: bir relay gerçekten neleri görebilir

Bu her şeyden önce önemlidir, çünkü genellikle insanların kendileri barındırmayı tercih etmesinin sebebi budur — ve genellikle yanlış tanımlanır.

Doğrudan eşler arası bağlantıda oturum iki cihaz arasında uçtan uca çalışır. Doğrudan bağlantı kurulamazsa — simetrik NAT, katı kurumsal güvenlik duvarları gibi durumlarda — oturum relay üzerinden gider ve TLS relay'de sonlanır. Relay'i işleten taraf bu nedenle yönlendirilen trafiği görebilir. Biz kendi relay'imiz hakkında aksi bir şey söylemeyeceğiz.

Bu, protokolün bir özelliğidir, kimin sunucuyu ödediğiyle ilgili değildir. Relay'i kendiniz çalıştırmanız, bir satıcı relay'inin şifrelemediği bir şeyi şifrelemez; sadece bu pozisyonda kimin olduğunu değiştirir. "Kimin bu pozisyonda olmasına izin veriliyor" sorusunun cevabı bir uyumluluk yükümlülüğüne yazılı şekilde bağlıysa, kendi sunucunuzu barındırmak doğru cevaptır ve bu rehber sizin içindir. Eğer hiçbir yere yazılmamışsa, sahip olmadığınız bir problemi çözmek için bir işletme işi üstleniyorsunuz demektir.

Kuracağınız bileşenler

İki servis:

• hbbs (rendezvous server): ilk el sıkışmayı yönetir. Her iki istemci kısa süreliğine ona bağlanarak birbirlerini keşfeder, açık anahtarları değiştirir ve doğrudan P2P'nin mümkün olup olmadığını belirler. TCP/UDP 21115-21117 üzerinde dinler.
• hbbr (relay server): doğrudan P2P başarısız olduğunda oturumu taşır. TCP 21117 (ve bazı senaryolar için UDP) üzerinde dinler.

Relay sadece P2P işe yaramadığında devreye girer — tüketici NAT'larında yaygın, aynı LAN'da nadirdir. Yani kendi sunucunuzu barındırsanız bile, sadece gerçekten relay gerektiren oturumlar için VPS bant genişliği ödersiniz.

Adım 1: Bir VPS seçin

Bant genişliği en önemli kaynaktır. CPU ve RAM minimumdur; çünkü relay veriyi yönlendirir, işleme yapmaz.

• Hetzner CX22 (€4/ay, 2 vCPU, 4 GB RAM, 20 TB bant genişliği, AB veri merkezleri) — fiyat/bant genişliği oranı en iyi.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bant genişliği) — iyi kullanıcı deneyimi, US/EU bölgeleri.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, sınırsız bant genişliği) — yüksek bant genişliği senaryoları için en uygunu.

Bağlanacak istemcilere yakın bir bölge seçin. Relay trafiği gidiş-dönüş gecikmesine bağlıdır; bu, algılanan gecikme üzerinde sahip olduğunuz en büyük etkendir — ve aşağıda anlatıldığı gibi tek bir VPS bunun en zayıf yanı olur.

Adım 2: Sunucuyu kurun

Yeni bir Ubuntu 22.04 veya Debian 12 VPS oluşturun. root olarak SSH ile bağlanın.

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

Güvenlik duvarını atlamayın. Varsayılan yapılandırma sadece gerekli portları açar; geri kalan her şey kilitli olmalı.

Adım 3: hbbs + hbbr'i Docker ile çalıştırın

/opt/tenvo-relay/docker-compose.yml dosyasını oluşturun:

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

your-server.example.com'u gerçek ana makine adıyla değiştirin, sonra başlatın:

cd /opt/tenvo-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

hbbs ilk başlatmada bir açık anahtar yazdırır. Log'lardan kaydedin (id_ed25519.pub veri hacminde) — istemciler bununla relay'e bağlandıklarını doğrular, sahte bir relay ile değil.

Adım 4: DNS'i yapılandırın

relay.yourdomain.com için bir A kaydı VPS IP'sine yönlendirin. Doğrudan IP de çalışır, ama bir ana makine adı taşınma durumunda hayatı çok daha kolaylaştırır.

Adım 5: İstemcileri relay'inize yönlendirin

Çoğu rehberin üstünden atladığı kısım. Her istemcinin üç değere ihtiyacı var:

• ID server = relay.yourdomain.com:21116
• Relay server = relay.yourdomain.com:21117
• Public key = VPS'inizdeki data/id_ed25519.pub dosyasının içeriği

Windows, macOS ve Linux'ta:

1. Tenvo veya RustDesk istemcisini açın.
2. Ayarlar → Network → ID/Relay server.
3. Yukarıdaki üç değeri girin ve kaydedin.
4. İstemciyi yeniden başlatın.

Durum göstergesi birkaç saniye içinde yeşile dönmelidir. Kırmızı kalırsa, güvenlik duvarı kurallarını ve açık anahtarın tam olarak eşleştiğini kontrol edin — genellikle sorun fazladan bir yeni satırdan kaynaklanır.

Adım 6: TLS ekleyin

Relay portlarının önüne bir reverse proxy koyun. Caddy en kısa yoldur:

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy sizin için Let's Encrypt sertifikasını çıkarır ve yeniler. İstemcileri TLS etkinleştirilmiş 443 portunu kullanacak şekilde güncelleyin — bu ayrıca yalnızca 443'e izin veren kısıtlayıcı çıkış güvenlik duvarlarından geçmenizi sağlar.

Adım 7: Anahtarları yedekleyin

data/ dizini rendezvous sunucusunun anahtar çiftini tutar. Bunları kaybederseniz her istemciyi tek tek yeni bir açık anahtarla yeniden yapılandırmak zorunda kalırsınız — her makinada elle.

# Local backup
rsync -avz vps:/opt/tenvo-relay/data/ ~/tenvo-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/tenvo-relay/data/id_ed25519* ~/tenvo-keys/

Çevrimdışına (offline) saklayın. VPS ele geçirilirse aynı anahtarlarla temiz bir kutuda yeniden kurulum yapmak istersiniz, böylece mevcut istemciler etkilenmeden çalışmaya devam eder.

Eğitimlerin atladığı arıza senaryoları

İstemciler relay'e ulaşamıyor. Neredeyse her zaman sorun güvenlik duvarıdır. ufw status kontrol edin, bulut sağlayıcınızın güvenlik grubunun aynı portlara izin verdiğini doğrulayın ve erişilebilirliği doğrulamak için bir istemciden nc -vz relay.yourdomain.com 21116 çalıştırın.

Her şey relaya düşüyor. Simetrik NAT ve katı kurumsal güvenlik duvarları her oturumu zorunlu olarak relay üzerinden geçirir. Performans dayanır, ama bant genişliği faturanız artık istisna değil hikayenin tamamıdır.

Relay çöküyor ve geri gelmiyor. Docker'daki restart: unless-stopped yaygın durumları kapsar. Tam disk dolması, OOM kill veya kernel panic gibi durumları kapsamaz — bunlar için birinin sizi uyarmasını sağlayan izleme gerekir, ve o biri sizsiniz.

Sertifika süresi doluyor. Caddy ile otomatik. nginx + certbot altında ise bu, hatırlamanız gereken bir cron işi olur; resmi kılavuz için certbot.eff.org'a bakın.

Eğitimlerin göstermediği fatura

€4'lık VPS faturadaki en ucuz kalemdir ve kendi sunucunuzda barındırmanın maliyeti olarak sadece bunu göstermek, bir arabanın satın alma fiyatını sürüş maliyeti diye göstermekle aynı numaradır. Geri kalan:

• Kendi relay'iniz için nöbet sizde. Gece 02:00'de çöktüğünde, uzaktan erişim o anda sizin onarmak zorunda olduğunuz şey değildir.
• OS yamalama, sürekli. İnternete açık bir sunucu, yamaları uygulamakla sizin sorumluluğunuzdadır.
• Anahtar muhafazası. data/'yı kaybederseniz her istemciyi elle yeniden yapılandırırsınız. O yedeğin gerçekten çalıştığını doğrulamak artık bir görevdir, sadece zamanlayacağınız bir iş değil.
• Sertifika yenileme. Otomatik olana kadar otomatik; ama bir gün olmadığında bunu hatırlamanız gerekir.
• Tek bölge, tek kutu. Tek VPS tek bir lokasyondur ve failover yoktur. Dünyanın öbür tarafındaki istemciler bunun gidiş-dönüş gecikmesini öder; kutu kapalıysa herkes kapalıdır.

Bant genişliği tahmin etmesi gerçekten kolay bir maliyettir. Yaklaşık rakamlar, relaya düşen oturum başına:

• Düşük kalite, metin ağırlıklı çalışma: ~50 KB/s = 180 MB/saat
• Orta, genel ofis çalışması: ~200 KB/s = 720 MB/saat
• Yüksek, video ve tasarım çalışması: ~1 MB/s = 3.6 GB/saat

Bir Hetzner CX22'nin 20 TB/ay'ı yüksek kaliteli relaya düşen oturumlar için yaklaşık 5.500 saate denk gelir. Birey veya küçük ekip için bu tavan genellikle bağlayıcı kısıt değildir — tam da bunun noktası budur. Eğer bant genişliği kendi sunucuyu barındırma sebebinizse, iyi bir sebep değildir. Bağlayıcı kısıtlar yukarıdaki dört maddedir.

Yönetilen relay bunun yerine ne yapar

Aynı mimari, farklı işletmeci. Relay filosu tek VPS yerine çok bölgeli olur, böylece istemciler sizin yakınınızdaki bir sunucuya değil kendilerine yakın bir sunucuya bağlanır. İş bu iş için görevli kişiler tarafından izlenir. Anahtar malzemesi, yamalama ve sertifika yenileme sizin probleminiz olmaktan çıkar. Bir şey gece 02:00'de bozulduğunda aranan kişi siz olmazsınız.

İşte abonelik bunun için: Free at $0, Lite at $2.99/mo, Pro at $7.99/mo — her katmanda nelerin olduğunu görmek için pricing'e bakın, ya da ekip olarak dağıtım yapıyorsanız the business plans'a bakın. €4'lık bir VPS'e artı kendi nöbet çizelgenizi koyduğunuzda, çoğu kişi için matematik pek yakın değil.

Kendi sunucunuzda barındırmak gerçekten doğru tercih olduğunda

Bunu gerektiren bir yükümlülük varsa doğru tercihtir: trafiğin üçüncü taraf altyapısından geçmemesi gereken düzenlemeler, dış relay'e ulaşılamayan air-gapped veya kısıtlı ağlar, veya sizi belirli bir yargı kapsamına kilitleyen ikamet kuralları. Bu durumlarda işletme maliyeti artık bir ek yük değil, gerekliliktir ve bu rehber tam olarak ihtiyaç duyduğunuz şeydir.

Ayrıca seçeneğin var olması önemlidir. Tenvo AGPL-3.0 lisanslı ve sunucu yığını açık kaynak olduğundan, yönetilen relay bir kolaylıktır satın aldığınız, kabul etmek zorunda olduğunuz bir kilit değil. Eğer bizi kullanmayı bırakmaya değer bulmazsanız, çıkış yolu yukarıdaki rehberdir — bunu yayımlamanın amacı budur. Yönetilen yapının sade RustDesk ile nasıl karşılaştırıldığını görmek için how the managed build compares to plain RustDesk'e, veya güvenlik modelinin nasıl çalıştığına bakmak için how the security model works'e bakın.

Özet

1. İstemcilere en yakın bölgede bir VPS.
2. Docker, UFW ve hbbs/hbbr konteynerleri.
3. VPS'e işaret eden bir DNS A kaydı.
4. Her istemcide üç yapılandırma değeri: ID server, relay server, public key.
5. Gerçekten bir kez geri yüklediğiniz data/ dizininin çevrimdışı bir yedeği.
6. Caddy ile TLS ve sizi uyaran bir izleme sistemi.

Kurulum 30 dakika; sahip olmak sonsuz. Bir gereklilik sizi bu konuma koyuyorsa, yukarıdaki adımlar tüm iştir. Hiçbir gereklilik yoksa, yönetilen relay ile başlayın — istemciyi indirin, ve bir uyumluluk formu bunu gerekli kıldığında bu sayfaya geri gelin.