הקמת שרת RustDesk עצמאי: מדריך הגדרה ל-hbbs ו-hbbr

מהו שרת ממסר (relay) עצמאי של RustDesk

שרת ממסר עצמאי של RustDesk מורכב משני תהליכי רקע (daemons) הפועלים על שרת VPS יחיד. hbbs הוא שרת ה-ID והמפגש (rendezvous): הוא רושם כל מזהה לקוח ומקשר בין שני לקוחות. hbbr הוא שרת הממסר: הוא מעביר את נתוני הסשן, אך ורק עבור סשנים שלא הצליחו ליצור תקשורת ישירה. רוב המדריכים מתקינים את שניהם, מוודאים שהצמדת הלקוחות עובדת, ועוצרים שם. מה שמופיע להלן הוא השלמת העבודה: המפתח המשמש כבקרת הגישה שלכם, הפורטים, השדרוג ורוחב הפס.

שני התהליכים מגיעים באותה תמונה (image), rustdesk/rustdesk-server, ושניהם קוראים את אותו זוג מפתחות Ed25519 מאותה תיקייה. Ed25519 הוא מנגנון חתימה במפתח ציבורי. זוג מפתחות זה קובע מול אילו לקוחות השרת שלכם יתקשר, ואין מאחוריו מסד נתונים של משתמשים.

hbbs ו-hbbr: איזה daemon צורך רוחב פס

התעבורה של hbbs היא קטנה וקבועה: רישום מזהים (ID) ואותות חיים (heartbeats), בתוספת חילופי מידע קצרים המקשרים בין שני צדדים. הוא רץ לאורך כל היום וצורך משאבים זניחים.

התעבורה של hbbr היא הסשן עצמו. פריימים של מסך עוברים בכיוון אחד, קלט מקלדת ועכבר בכיוון השני, וכל בייט שעובר דרך ה-relay מגיע ל-VPS שלכם ואז יוצא ממנו שוב. אם ספק התשתית שלכם מחייב רק על תעבורה יוצאת (egress), סשן מתווך יעלה לכם בערך כקצב הסשן. אם הוא מחייב על סך התעבורה, העלות היא בערך כפולה.

ה-relay הוא מוצא אחרון, לא נתיב העבודה הרגיל. hbbs מנסה תחילה לחבר את שני הלקוחות ישירות, באמצעות hole punching דרך כל NAT (תרגום כתובות רשת) שנמצא לפני כל אחד מהם. כאשר זה מצליח, הסשן לעולם לא נוגע ב-hbbr ומכסת התעבורה שלכם נשארת ללא שינוי. כאשר צד אחד נמצא מאחורי NAT שמקצה פורט חדש לכל יעד, או מאחורי firewall שחוסם את הנתיב שנוצר, הסשן עובר ל-hbbr וכל פריים עובר דרך ה-VPS שלכם.

משתנה סביבה אחד מבטל את הבחירה הזו. ALWAYS_USE_RELAY=Y ב-hbbs מכריח כל סשן לעבור דרך hbbr. התיעוד של RustDesk מציג זאת באחת מדוגמאות ה-Compose שלו, ולכן הוא מועתק לעיתים קרובות. הוא הופך חיבורים לצפויים יותר והופך את התעבורה היוצאת שלכם למוחשית. הגדירו אותו כי החלטתם כך, לא כי העתקתם אותו.

אילו פורטים נדרשים עבור שרת RustDesk באירוח עצמי

מספרי הפורטים להלן נבדקו מול תיעוד שרת RustDesk ומול המאגר rustdesk-server בתאריך 17 באוגוסט 2026.

• TCP 21115, ב-hbbs: בדיקת סוג ה-NAT.
• UDP 21116, ב-hbbs: רישום מזהה (ID) ו-heartbeat. ללא פורט זה הלקוח לא יתחבר לעולם, ללא קשר לפורטים אחרים שפתוחים.
• TCP 21116, ב-hbbs: ביצוע TCP hole punching ושירות החיבור.
• TCP 21117, ב-hbbr: ה-relay. זהו הפורט שמעביר את נתוני הסשן, ולכן זהו הפורט שצורך רוחב פס.
• TCP 21118 ב-hbbs ו-TCP 21119 ב-hbbr: פרוטוקול WebSocket, המשמש את לקוח הדפדפן. השאירו את שניהם סגורים אם אינכם משתמשים בו.
• TCP 21114 הוא ה-web console בגרסת RustDesk Server Pro. גרסת ה-open source אינה מאזינה בפורט זה.

התקנת 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. ודאו שהמאזינים קיימים לפני שתגדירו את ה-firewall.

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

עליכם לראות מאזיני TCP בפורטים 21115, 21116 ו-21117, ומאזין UDP בפורט 21116. שורה חסרה של UDP מעידה על כך ש-hbbs אינו פועל, שכן זהו המאזין שאליו הלקוחות נרשמים.

ארבעה דברים בקובץ זה מכוונים. התג הוא 1.1.16, הגרסה העדכנית נכון לאוגוסט 2026, שפורסמה ב-20 ביולי 2026, ולא latest, כיוון ש-latest משמעותו כל מה שהועלה לאחרונה, ו-docker compose pull בעוד שישה חודשים עלול לספק לכם שרת שמעולם לא בדקתם. network_mode: "host" קושר את ממשקי המארח ישירות, כפי שממליץ התיעוד של RustDesk, וזה מה שקובע כיצד ה-firewall שלכם יתנהג. ./data:/root ממפה את תיקיית העבודה של ה-image אל המארח, כך שזוג המפתחות נשמר במקום שניתן לגבות. ו-hbbr -k _ הוא השינוי היחיד מהדוגמה המקורית, כיוון שברירת המחדל משאירה את ה-relay שלכם פתוח לכל אחד. אם Docker Compose חדש לכם, הרצת Docker Compose על גבי VPS מכסה את מבנה הקובץ ופקודות מחזור החיים.

אם hbbr עובר לשרת שני, יש להגדיר ל-hbbs לאן הוא עבר: העבירו את -r relay.example.com:21117, או הגדירו את משתנה הסביבה RELAY-SERVERS. בשרת יחיד אין בכך צורך.

זוג המפתחות Ed25519 הוא בקרת הגישה

בהפעלה הראשונה, hbbs מייצר את id_ed25519 ואת id_ed25519.pub בתיקיית העבודה שלו. עם ה-mount שצוין לעיל, שני הקבצים יופיעו על המארח (host).

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

הקובץ id_ed25519.pub מכיל מחרוזת base64 אחת. מחרוזת זו מוזנת לשדה Key בכל לקוח. הקובץ id_ed25519 הוא החצי הפרטי ואינו עוזב את השרת לעולם. המפתח הציבורי אינו סוד, כיוון שהוא מועתק ממילא לכל הגדרות הלקוח. המפתח הפרטי הוא סוד: כל מי שמחזיק בו יכול להקים שרת שהלקוחות שלכם יבטחו בו.

גבו את שני הקבצים כעת, לפני שתגדירו עשרים לקוחות.

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.

המפתח אינו סיסמת ההתחברות (session password), ובלבול בין השניים מוביל משתמשים לדלג על אחד מהם. המפתח קובע אילו לקוחות יתקשרו עם השרת שלכם. הסיסמה הקבועה או הקוד החד-פעמי במכונה הנשלטת קובעים למי מותר לפתוח session באותה מכונה. אתם זקוקים לשניהם, והחזקה באחד אינה מפצה על חולשתו של האחר.

מדוע ממסר (relay) ללא אימות מהווה בעיה

כברירת מחדל, hbbr אינו מבצע שום בדיקה. תיעוד התצורה של RustDesk מציין זאת במפורש: מפתח ריק מאפשר ללקוחות ללא מפתח תואם להשתמש בממסר. ברירת המחדל הריקה קיימת כדי שמשתמשים חדשים לא ייתקלו בכשלים של אי-התאמת מפתחות בהרצה הראשונה. המחיר הוא שכל מי שמוצא את הכתובת שלכם בפורט TCP 21117 יכול להעביר את תעבורת הסשן שלו דרך ה-VPS שלכם, על חשבון מכסת התעבורה שלכם, ומכתובת ה-IP שלכם.

command: hbbr -k _ סוגר את הפרצה הזו. הארגומנט _ מורה ל-hbbr לטעון זוג מפתחות מתיקיית העבודה שלו, ומכיוון ששני הקונטיינרים מעגנים (mount) את אותו ./data, זהו הזוג ש-hbbs כבר יצר. שום דבר לא מועתק ידנית, ולכן לא יכול להיווצר חוסר סנכרון.

הנפח (volume) המשותף הוא החלק שאנשים טועים בו. אם תתנו ל-hbbr תיקייה משלו, הוא ייצור זוג מפתחות שונה. במצב כזה hbbs ו-hbbr לא יסכימו ביניהם, כל סשן שעובר דרך ממסר ייכשל, וסשנים ישירים ימשיכו לעבוד. התסמין מבלבל: RustDesk מצליח להגיע לחלק מהעמיתים (peers) ולא לאחרים, בהתאם לשאלה אם ה-hole punching הצליח. פקודת ls -l ~/rustdesk/data/ אחת שמציגה זוג id_ed25519 יחיד שוללת את האפשרות הזו.

הפניית הלקוחות אל השרת שלכם

בכל מכונה, פתחו את RustDesk, עברו אל Settings, לאחר מכן אל Network, ולבסוף אל ID/Relay Server.

• ID Server: שם המארח (hostname) שלכם, לדוגמה rustdesk.example.com. הלקוח משתמש בפורט 21116 אלא אם ציינתם פורט אחר.
• Relay Server: השאירו ריק כאשר hbbr רץ על אותו מארח כמו hbbs.
• API Server: השאירו ריק. גרסת ה-open source של השרת אינה מספקת שירות זה.
• Key: מחרוזת ה-base64 מתוך id_ed25519.pub. יש להדביק אותה במדויק, ללא רווחים בסוף.

החלון הראשי אמור להציג כעת שהלקוח מוכן. אם לא, סימן שפורט UDP 21116 אינו מגיע אל hbbs, שכן תהליכי הרישום וה-heartbeat מתבצעים על גבי UDP, וזהו התנאי היחיד להעלאת ה-ID לרשת.

הגבלת פורטים כדי למנוע מצב של relay פתוח

מכיוון שהמכולות משתמשות ב-host networking, אין חוקי NAT של Docker לפניהן, ולכן חוקי 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 רק אם אתם מריצים את לקוח הדפדפן. השאירו סשן SSH שני פתוח בזמן הפעלת ufw, כדי שטעות בחוק ה-SSH לא תנעל אתכם מחוץ לשרת. המדריך יסודות חומת האש ufw עבור VPS מכסה את מדיניות ברירת המחדל ואת סדר החוקים.

כעת, המלכוד: אם תעברו לפרסום פורטים באמצעות בלוק ports:, כפי שמשמש בדוגמת ה-image החלופי של RustDesk supervisor,‏ Docker כותב חוקי DNAT משלו והחבילות מגיעות למכולה מבלי לעבור בשרשרת שבה נמצאים חוקי ה-ufw שלכם. במקרה כזה, פקודת ufw deny על פורט 21117 לא תשפיע, וה-relay יהיה פתוח לאינטרנט למרות ש-ufw status מציג מצב אחר. המאמר פורטים מפורסמים ב-Docker עוקפים את ufw מסביר את סדר השרשראות. שימוש ב-host networking מונע את הבעיה לחלוטין. אם בכל זאת בחרתם לפרסם פורט, בצעו bind לכתובת אחת בלבד, כפי שמוצג ב-"127.0.0.1:21118:21118" מאחורי reverse proxy.

הגבלה לפי כתובת מקור עובדת רק כאשר ללקוחות שלכם יש כתובות קבועות.

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 מבצע כאן עבודה משמעותית יותר מחומת האש.

שדרוג stack שמחזיק את המפתח שלכם

המפתח נמצא בתוך ה-bind mount ולא בתוך ה-container, לכן שדרוג הוא בטוח כל עוד לא נוגעים ב-./data.

1. בצעו גיבוי של תיקיית הנתונים תחילה: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. קראו את הערות השחרור (release notes) עבור ה-tag החדש בדף ה-releases של rustdesk-server.
3. ערכו את compose.yml ושנו את שתי שורות ה-image: ל-tag החדש.
4. הריצו את sudo docker compose pull, ולאחר מכן את sudo docker compose up -d.
5. הריצו את sudo cat ~/rustdesk/data/id_ed25519.pub וודאו שהמחרוזת היא אכן זו שהלקוחות שלכם כבר מחזיקים.

שלב 5 הוא הבדיקה הקריטית, כיוון שמפתח שהשתנה לא יפיק שגיאה בשרת, אך ישבור את החיבור של כל הלקוחות בו-זמנית. חזרה לגרסה קודמת (rollback) מתבצעת על ידי החזרת ה-tag הישן והרצה חוזרת של up -d; זה עובד רק כי ביצעתם הצמדה (pinning): עם latest, הפקודה docker compose pull העבירה את השם לתמונה (image) החדשה, כך שלא נשאר tag שמצביע על הישנה.

הדרך הנפוצה לאבד את המפתח היא לא דרך docker compose down, שמשאירה את ה-bind mount ללא שינוי. אובדן קורה בעת הגירה ל-VPS חדש והעתקה של compose.yml בלבד. הקפידו להעתיק גם את ./data יחד איתו.

ניטור תעבורה יוצאת (egress) בתוכנית עם מכסת העברת נתונים

hbbr הוא הרכיב היחיד בסט הזה שיכול לצרוך ממכסת העברת הנתונים. ה־FAQ של RustDesk מציין שחיבור מתווך (relayed) יחיד על מסך ברזולוציית 1920x1080 צורך בין 30 KB/s ל־3 MB/s, ועבודה משרדית רגילה צורכת כ־100 KB/s. אלו נתונים רשמיים עבור סשן בודד, ולא מדידה של ההתקנה הספציפית שלכם. בחישוב של שישים שעות בחודש, שעתיים ביום, התוצאות נראות כך.

[
  {
    "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 בחודש, כמות שאף תוכנית אירוח לא תזהה כחריגה. בקצה העליון של הטווח המוצהר, אותן שישים שעות עולות 648 GB, ושני סשנים מקבילים בקצב הזה ינצלו מכסה של 1 TB בתוך החודש. הקצה התחתון הוא 6.5 GB. גיגה-בייט כאן מחושבים כ-1000 MB, שזו הדרך המקובלת למדידת מכסות העברת נתונים.

docker stats לא יפרק לכם את הנתונים האלו, כיוון שמכולה המשתמשת ב-host networking חולקת את ה-network namespace של המארח, ולכן המונים שלה הם המונים של המארח. שני כלים אחרים כן עובדים. vnstat מודד את כל השרת:

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

כל השרת אומר כל השרת: אם ה-VPS הזה מריץ גם משהו שמעביר נתונים משמעותיים, למשל אחד משרתי ה-photo servers בניהול עצמי שמושך ספריות מהטלפון בכל לילה, ה-uploads שלו יופיעו באותה שורה חודשית כמו תעבורת ה-relay שלכם. שרת מדיה הוא סיפור דומה מהצד השני, שכן משהו כמו Halcyon, שהופך ספריית Jellyfin לחנות וידאו בסגנון שנות ה-90 מזרים תוכן לכל מי שצופה, וה-egress הזה חולק את המכסה שה-relay שלכם צורך.

מונה nftables מודד את ה-relay באופן ספציפי:

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

לחוק הזה אין verdict, לכן הוא סופר חבילות ובייטים מבלי לשנות את מה שמותר, והוא יושב בטבלה משלו כדי לא להפריע ל-ufw. הוא אינו נשמר לאחר אתחול: הכניסו את אותן שורות ל-/etc/nftables.conf אם אתם רוצים שהוא יחזור לאחר reboot. המונה גדל רק בזמן שסשן אכן מועבר ב-relay. מונה שממשיך לעלות בזמן שאף מכונה שלכם לא מחוברת אומר שמישהו אחר מצא את ה-relay שלכם, וזה המקרה ש-hbbr -k _ נועד למנוע. מכיוון שלא תקראו את nft list בכל בוקר, הגדירו עליו cron job שמשווה את ספירת הבייטים מול סף מסוים ושולח התראה (push alert) כאשר הוא נחצה, וזו משימה עבור שרת ה-ntfy שלכם.

ל-hbbr יש גם מגבלות קצב (rate limits) שניתן להנמיך. ברירת המחדל של SINGLE_BANDWIDTH היא 128 Mb/s לכל חיבור relay, ושל TOTAL_BANDWIDTH היא 1024 Mb/s עבור כולם יחד. הגדרת SINGLE_BANDWIDTH=8 מגבילה סשן אחד לאזור ה-1 MB/s. זה מגביל את המהירות, לא את הסך החודשי, לכן התייחסו לזה כאל דרך למנוע מסשן אחד להרוות את רוחב הפס, ולא כאל כלי לבקרת תקציב.

מתי אין צורך ב-relay כלל

עבור הגדרה אישית, התשובה הכנה היא שייתכן שכלל אינכם זקוקים לכל זה. חברו את שני המחשבים ל-mesh VPN והתחברו ישירות לכתובת ה-tunnel. במצב זה אין צורך ב-hbbs, ב-hbbr, ב-relay egress, ואין מכולה ב-VPS שצריך לעדכן.

במחשב שברצונכם לשלוט בו, הפעילו גישת IP ישירה בהגדרות האבטחה של RustDesk. שדה הפורט מוגדר כברירת מחדל ל-21118. ודאו שהוא מאזין לפני שתנסו להתחבר:

ss -tlnp | grep 21118

לאחר מכן, התחברו לכתובת ה-VPN של אותו peer במקום ל-ID. ה-FAQ של RustDesk מציין לגבי מצב זה שהחיבור אינו מוצפן, לכן הריצו אותו בתוך ה-tunnel ולעולם לא ישירות מול האינטרנט הפתוח. ה-tunnel הוא זה שמספק את ההצפנה.

בחרו לפי הבעלות על המחשבים. שימוש ב-hbbs ו-hbbr בניהול עצמי מתאים כאשר אתם תומכים במחשבים שאינם שלכם, או באנשים שלעולם לא יתקינו לקוח VPN, כיוון שהצד שלהם בהגדרה מסתכם ב-ID ובסיסמה. mesh VPN עם גישת IP ישירה מתאים כאשר כל המחשבים שייכים לכם ויכולים לשאת מפתח. השוואה בין WireGuard ל-Tailscale מכסה את שתי הדרכים הנפוצות לבניית mesh כזה, ו-הרצת שולחן עבודה מרוחק על Linux VPS מכסה את המקרה האחר, שבו המחשב שאתם רוצים גישה למסך שלו הוא השרת עצמו.

FAQ

האם כל סשן של RustDesk עובר דרך ה-relay שלי?

לא. hbbs מנסה תחילה לחבר בין שני הלקוחות ישירות, תוך שימוש ב-hole punching דרך ה-NAT שנמצא לפני כל אחד מהם. רק סשנים שבהם ניסיון זה נכשל עוברים ל-hbbr, ורק הם צורכים את רוחב הפס שלך. היוצא מן הכלל הוא ALWAYS_USE_RELAY=Y ב-hbbs, אשר מכריח כל סשן לעבור דרך hbbr ללא קשר לשאלה אם היה מסלול ישיר זמין. אם משתנה זה מוגדר בקובץ ה-Compose שלך, כל בייט מכל סשן יופיע בחשבון התעבורה שלך.

היכן נשמר מפתח השרת של RustDesk, ומה קורה אם אאבד אותו?

hbbs מייצר את id_ed25519 ו-id_ed25519.pub בתיקיית העבודה שלו בעת ההפעלה הראשונה. תיקייה זו היא /root בתוך ה-image הרשמי, לכן עם ה-volume mount המוצג לעיל, הקבצים יופיעו ב-./data על המארח (host). בצע גיבוי לשני הקבצים מחוץ לשרת. אם הם אובדים, hbbs ייצר זוג חדש בהפעלה הבאה, וכל לקוח שעדיין מחזיק במפתח הציבורי הישן יידחה. אין דרך שחזור מלבד עריכה ידנית של שדה ה-Key בכל לקוח.

אילו פורטים עלי לפתוח עבור שרת RustDesk בניהול עצמי?

TCP 21115, 21116 ו-21117, בתוספת UDP 21116. hbbs משתמש ב-21115 עבור בדיקת סוג ה-NAT, וב-21116 עבור רישום ID ו-heartbeat על גבי UDP, ועבור hole punching על גבי TCP. hbbr משתמש ב-21117 עבור ה-relay. הפורטים TCP 21118 ו-21119 הם פורטי ה-WebSocket עבור לקוח הדפדפן, לכן השאר אותם סגורים אם אינך משתמש בו. הפורט TCP 21114 שייך ל-Pro web console והגרסה בקוד פתוח אינה זקוקה לו.

האם זרים יכולים להשתמש ב-relay של RustDesk בניהול עצמי שלי?

כן, אם תריץ את hbbr עם הגדרות ברירת המחדל שלו. התיעוד של RustDesk מציין שמפתח ריק מאפשר ללקוחות ללא מפתח תואם להשתמש ב-relay, לכן כל מי שלומד את שם המארח (hostname) והפורט 21117 שלך יכול להעביר תעבורה דרך השרת שלך. הרץ את hbbr עם -k _ כך שהוא יטען את אותו זוג מפתחות ש-hbbs יצר ב-volume המשותף ./data. לאחר מכן, רק לקוחות שהוגדרו עם המפתח הציבורי שלך יוכלו להשתמש ב-relay שלך.