אירוח עצמי של שרת NetBird VPN על גבי VPS: מדריך מלא

מה מעניק לך אירוח עצמי של שרת ה-VPN מסוג NetBird

אירוח עצמי של שרת ה-NetBird VPN מעביר את מישור הבקרה (control plane) לשרת VPS שבבעלותך: זהו הרכיב שמחזיק את רשימת ה-peers, מחליט איזה מחשב רשאי לתקשר עם איזה, ומסייע לשני peers למצוא זה את זה מאחורי NAT (תרגום כתובות רשת). המנהרות עצמן נותרות מבוססות WireGuard, ומוצפנות ישירות בין המחשבים שלך. השינוי הוא ששום חברה חיצונית אינה מחזיקה במלאי המכשירים שלך או בתהליך ההתחברות שלך. חשוב להבין מה זה מקנה לך, שכן גם במישור בקרה מנוהל (hosted), הספק אינו מחזיק במפתחות שמצפינים את התעבורה שלך, ו-מה שרת תיאום יכול לעשות בפועל אם הוא נפרץ הוא רשימה מצומצמת יותר ממה שרוב האנשים מניחים לפני שהם קוראים על כך.

NetBird ממוקם בין שני דברים שאולי כבר מוכרים לך. זהו mesh overlay, כך ש-peers מתחברים זה לזה במקום להעביר את כל התעבורה דרך gateway יחיד. הוא גם ניתן לאירוח עצמי מקצה לקצה, מה שמעמיד אותו מול Headscale, שרת הבקרה לאירוח עצמי של Tailscale. אם הרצת בעבר רק מנהרה עם gateway יחיד, קרא תחילה את ההבדל בין WireGuard פשוט לבין mesh overlay, כיוון שהמודל המחשבתי הזה הוא מה שהופך את שאר הדף הזה לשימושי.

אם מה שאתה באמת רוצה הוא שרת יחיד שדרכו יוצאת כל התעבורה שלך, mesh הוא מנגנון מורכב יותר ממה שהמשימה דורשת. VPN מבוסס WireGuard פשוט על VPS יחיד או exit node של Tailscale עושים זאת עם הרבה פחות תחזוקה. ואם המטרה היא גישה לרשת פרטית אחת במקום קישור מחשבים זה לזה, subnet router של Tailscale על גבי VPS מפרסם את טווח הכתובות הזה ל-tailnet שכבר יש לך, ללא צורך בכל ה-stack המפורט להלן.

מה ה-stack מריץ בפועל

המבנה השתנה לאחרונה, ורוב המדריכים הישנים מתארים את המבנה הקודם. נכון לאוגוסט 2026, בגרסה v0.76.2, סקריפט ה-quickstart יוצר קובץ Compose עם שלושה שירותים כברירת מחדל.

• netbird-server מריץ את ה-management API, את שירות ה-signal, את ה-relay עם מאזין STUN מוטמע, וספק זהות (identity provider) מוטמע. בגרסאות ישנות יותר אלו היו מכולות נפרדות, וספק הזהות היה התקנת Zitadel נפרדת שהיה עליך לבנות תחילה.
• dashboard הוא ממשק הניהול מבוסס ה-web.
• traefik מבצע TLS termination ומבקש תעודה מ-Let's Encrypt בעת ההפעלה הראשונה.

קיימים שני שירותים נוספים שנשארים כבויים אלא אם תאשר זאת בהנחיה (prompt). שירות ה-NetBird Proxy מפרסם שירותים פנימיים תחת שמות מתחם ציבוריים. CrowdSec מסנן תעבורה עוינת. אף אחד מהם אינו נדרש כדי לבנות mesh תקין, ושניהם צורכים זיכרון בשרת קטן.

אם הגעת מ-wg-easy במכולת Docker יחידה, מדובר בקפיצה במספר הרכיבים. מה שאתה מקבל בתמורה הוא מדיניות גישה, חשבונות לכל משתמש, וצמתים (peers) שמתחברים ישירות זה לזה במקום דרך gateway יחיד.

דרישות קדם

שם מתחם (domain name) ציבורי הוא הכרחי. לוח הבקרה, ה-API וה-relay כולם פועלים על HTTPS בפורט 443, ו-Traefik מנפיק את התעודה מ-Let's Encrypt באמצעות HTTP challenge, מה שמחייב שם מתחם שמתרגם לכתובת ה-VPS מהאינטרנט הציבורי. כתובת IP חשופה לא תעבוד בתהליך זה.

צרו רשומה מסוג A אחת, netbird.example.com, המצביעה על כתובת ה-IPv4 הציבורית של ה-VPS, והמתינו להפצתה לפני שתריצו דבר מה.

dig +short netbird.example.com

הפקודה חייבת להציג את כתובת השרת שלכם. הרצת המתקין לפני הפצת ה-DNS תגרום לכשל בבקשת התעודה בהפעלה הראשונה, וניסיונות אימות כושלים חוזרים ונשנים יובילו למגבלות קצב (rate limits) של Let's Encrypt, מה שיחייב אתכם להמתין שעה לפני ניסיון נוסף.

שלושה פורטים חייבים להיות נגישים מהאינטרנט: TCP 80 עבור ה-certificate challenge והפניה ל-HTTPS, TCP 443 עבור לוח הבקרה, ה-API, תעבורת ה-signal וה-relay, ו-UDP 3478 עבור STUN.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 3478/udp
sudo ufw reload
sudo ufw status

פתחו אותם גם ב-firewall הרשתי של ספק השרתים שלכם. זהו רכיב ניהול נפרד ברוב לוחות הבקרה של VPS, וזו הסיבה ששרת שהגדרות ה-ufw status שלו נראות תקינות עדיין מסרב לקבל חיבורים.

STUN (ראשי תיבות של session traversal utilities for NAT) הוא האופן שבו עמית (peer) לומד את הכתובת הציבורית והפורט שה-NAT שלו הקצה לו, כדי ששני עמיתים יוכלו לנסות ליצור מנהרה ישירה. חסימת UDP 3478 לא תמנע מהעמיתים להתחבר, שכן הם יעשו זאת דרך ה-relay ב-TCP 443, כך ששום דבר לא ייראה שבור. עם זאת, תקבלו Connection type: Relayed בכל עמית, וכל התעבורה תעבור דרך ה-VPS שלכם במקום ישירות בין העמיתים.

בצד התוכנה, עליכם להתקין Docker עם תוסף Compose v2, בנוסף ל-jq ו-curl. הסקריפט בודק את קיומם של כולם ועוצר אם אחד מהם חסר. אם Docker חדש בשרת זה, ודאו תחילה ש-Docker Compose עובד על ה-VPS.

התקנת שרת NetBird באמצעות סקריפט ההתקנה המהירה

הפקודה המתועדת בשורה אחת מעבירה את הגרסה העדכנית ביותר ישירות לתוך ה-shell:

curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash

במקום זאת, קבעו גרסה ספציפית. latest משתנה, לכן אותה פקודה שתורץ בהפרש של שבועיים תייצר שתי התקנות שונות, ושום דבר על הדיסק לא יתעד איזו מהן יצרה את התצורה שלכם. הורידו גרסה מתויגת (tagged release), קראו אותה, ורק אז הריצו אותה.

mkdir -p ~/netbird
cd ~/netbird
curl -fsSL -o getting-started.sh \
  https://github.com/netbirdio/netbird/releases/download/v0.76.2/getting-started.sh
less getting-started.sh
bash getting-started.sh

הסקריפט מבקש תחילה את שם המתחם:

Enter the domain you want to use for NetBird (e.g. netbird.my-domain.com):

לאחר מכן הוא שואל כיצד יטופל ה-TLS:

Which reverse proxy will you use?
  [0] Traefik (recommended - automatic TLS, included in Docker Compose)
  [1] Existing Traefik (labels for external Traefik instance)
  [2] Nginx (generates config template)
  [3] Nginx Proxy Manager (generates config + instructions)
  [4] External Caddy (generates Caddyfile snippet)
  [5] Other/Manual (displays setup documentation)
Enter choice [0-5] (default: 0):

בחרו ב-[0]. אפשרויות 2 עד 5 כותבות מקטע תצורה ומשאירות את החיבורים לטיפולכם; זה נכון בשרת שכבר מריץ proxy, אך שגוי בשרת חדש. אפשרות 0 תבקש לאחר מכן כתובת דוא"ל עבור Let's Encrypt, המשמשת להתראות על פקיעת תוקף.

סרבו לשירות ה-NetBird Proxy בהתקנה ראשונה. הוא דורש שני רשומות DNS נוספות, proxy.netbird.example.com ורשומת wildcard ב-*.proxy.netbird.example.com, והוא אינו תורם דבר לרשת mesh פשוטה. סרבו גם ל-CrowdSec. ניתן להוסיף את שניהם במועד מאוחר יותר.

הסקריפט כותב לתיקייה הנוכחית: docker-compose.yml, config.yaml עם הרשאות 600, dashboard.env, ו-traefik-dynamic.yaml אם בחרתם ב-Traefik המצורף. התייחסו לתיקייה זו כאל מצב (state) שיש לשמור, כיוון ש-config.yaml מכיל את המפתח שמצפין את הנתונים במאגר. אובדן שלו אינו דבר שהתקנה מחדש יכולה לתקן.

docker compose ps
docker compose logs -f netbird-server

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

docker compose logs traefik | grep -i acme

ACME (ראשי תיבות של automatic certificate management environment) הוא הפרוטוקול ש-Traefik משתמש בו כדי לקבל את התעודה. שגיאות כאן נובעות כמעט תמיד מבעיות DNS או מפורט 80 סגור.

יצירת חשבון מנהל המערכת הראשון

פתחו את https://netbird.example.com. בהתקנה חדשה, דף זה מוביל לדף הגדרה במקום לטופס התחברות. הזינו כתובת דוא"ל, שם וסיסמה, ולאחר מכן לחצו על Create Account. חשבון זה הופך לחשבון מנהל המערכת הראשון, והדף יפנה אתכם לטופס ההתחברות.

חשבון זה מאוחסן במאגר המשתמשים הפנימי של NetBird, המופעל על ידי ספק זהות המוטמע בתוך המכולה netbird-server. אין מעורבות של גורמים חיצוניים. זהו השינוי המשמעותי ביותר בגרסאות ה-self-hosted של NetBird בהשוואה לשנה שעברה, אז התקנה תקינה דרשה הקמה מוקדמת של Zitadel או Keycloak והעתקה של ארבעה ערכי OIDC (OpenID Connect) לתוך setup.env לפני שניתן היה להתחיל בתהליך כלשהו.

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

חיבור ה-peer הראשון שלכם

התקינו את ה-client על כל מכונת Linux, כולל ה-VPS עצמו אם ברצונכם לצרף אותו ל-mesh:

curl -fsSL https://pkgs.netbird.io/install.sh | sh

ב-Debian וב-Ubuntu, הסקריפט מגדיר את מאגר החבילות של NetBird ומתקין את ה-client באמצעות apt, כך שמנהל החבילות מנהל את התוכנה בכל מקרה. אם הרצת סקריפט ישירות ל-shell אינה נוחה לכם, שמרו אותו תחילה באמצעות curl -fsSL -o install.sh https://pkgs.netbird.io/install.sh וקראו את תוכנו לפני הרצה עם sh install.sh. כך או כך, ודאו שההתקנה הושלמה:

apt-cache policy netbird

netbird הוא ה-client של שורת הפקודה וה-daemon. netbird-ui הוא אפליקציית ה-tray לשולחן העבודה, ואין בה צורך בשרת ללא ממשק גרפי (headless).

כעת, כוונו את ה-client לשרת שלכם:

sudo netbird up --management-url https://netbird.example.com

השמטה של --management-url תגרום ל-client להירשם לשירות המנוהל של NetBird, כיוון שזו ברירת המחדל המקודדת בתוכנה. הפקודה תצליח, המכונה תקבל כתובת, אך ה-dashboard שלכם בשרת העצמי יישאר ריק. זו טעות נפוצה מאוד.

הפקודה תציג URL לפתיחה בדפדפן לצורך השלמת ההתחברות. לאחר מכן:

netbird status
ip addr show wt0

קראו ארבע שורות מתוך netbird status: Management: Connected, Signal: Connected, שורת Relays: המדווחת על כל ה-relay הזמינים, ו-NetBird IP: בטווח ה-overlay. wt0 הוא ממשק ה-WireGuard ש-NetBird יוצר, והוא אמור לשאת את אותה הכתובת.

צירוף מכונה שנייה ללא השגחה באמצעות מפתח הגדרה (setup key)

התחברות דרך דפדפן אינה אפשרית במכונה ללא ממשק גרפי או ללא משתמש נוכח. מפתח הגדרה (setup key) הוא אסימון אימות מוקדם המאפשר לרשום מכונה ללא צורך בשלב אינטראקטיבי. ניתן ליצור מפתח כזה בלוח הבקרה תחת Setup Keys.

קיימים שני סוגים של מפתחות. מפתח חד-פעמי מאמת מכונה אחת בלבד ולאחר מכן הופך ללא תקף. מפתח רב-פעמי מאפשר לרשום מכונות רבות, עם אפשרות להגדיר מכסה למספר המכונות. לשני הסוגים יש תאריך תפוגה, ושניהם מאפשרים שיוך אוטומטי של המכונה החדשה לקבוצה מסוימת, כך שחוקי הגישה של אותה קבוצה יחולו עליה ברגע שהיא תופיע ברשת.

sudo netbird up --setup-key <SETUP-KEY> \
  --management-url https://netbird.example.com \
  --hostname build-runner-01

הדגל --hostname קובע את השם שיוצג בלוח הבקרה. ללא הגדרה זו, המכונה תשתמש בשם המארח (hostname) שלה, ורשימה של מכונות שכולן נקראות ubuntu אינה מועילה לניהול.

עבור מכולות (containers) וסוכני בנייה (build agents) בעלי אורך חיים קצר, יש לסמן את המפתח כ-ephemeral בעת היצירה. מכונות שנרשמו באמצעות מפתח ephemeral יוסרו אוטומטית לאחר שהיו במצב לא מקוון במשך יותר מ-10 דקות, מה שמונע הצטברות של רשומות מתות ברשימת המכונות.

מגבלה אחת שיש להכיר לפני תכנון השימוש במפתחות הגדרה: תפוגה או מחיקה של מפתח עוצרת רישומים חדשים, אך אינה מנתקת מכונות שכבר נרשמו באמצעותו. כדי לבטל גישה של מכונה, יש להסיר את המכונה עצמה מהרשת.

האם עדיין נדרש ספק זהות נפרד?

עבור התקנה קטנה, לא. מאגר המשתמשים המובנה מטפל בחשבונות שנוצרו מלוח הבקרה, וזה מספיק עבור קומץ אנשים.

יש צורך בספק זהות חיצוני כאשר כבר קיים כזה ולא מעוניינים ברשימת משתמשים שנייה. NetBird מקבלת כל ספק התומך ב־OIDC. יש לרשום לקוח OIDC סודי (confidential) אצל הספק שלכם, ולאחר מכן להוסיף אותו בלוח הבקרה של NetBird עם ארבעה ערכים: שם, client ID, client secret ו־issuer. NetBird תספק לכם כתובת URL להפניה (redirect URL) שעליכם להדביק בחזרה אצל הספק. קיימות אינטגרציות מוגדרות מראש עבור Google, Microsoft Entra ID, Okta, Zitadel, Keycloak, Authentik ו־Pocket ID, וכל שירות אחר יוגדר כ־OIDC גנרי. אם אתם כבר מריצים Authentik כפתרון ה־single sign-on המארח את עצמו, זהו הנתיב שיאפשר לכם לשמור על רשימת חשבונות אחת במקום שתיים.

התחברות מקומית נשארת זמינה לאחר הוספת ספק, וכל ספק שהוגדר יופיע בדף ההתחברות. שמרו חשבון מנהל מקומי אחד עם סיסמה חזקה. כך, במקרה של תצורת OIDC שבורה, עדיין תהיה לכם דרך גישה למערכת.

NetBird או Headscale: איזה control plane כדאי להריץ?

שניהם מסירים את אותה תלות: שרת הניהול המרוחק שאליו הלקוחות שלכם היו מתקשרים כברירת מחדל. עם זאת, מדובר בפרויקטים בעלי אופי שונה.

Headscale הוא מימוש מחדש של שרת הניהול של Tailscale, ואתם ממשיכים להשתמש בלקוחות הרשמיים של Tailscale. אין לו ממשק ניהול גרפי רשמי. ניהול משתמשים ומפתחות אימות מוקדם (pre-authentication keys) מתבצע באמצעות הפקודה headscale מול קובץ הגדרות. קיימים ממשקי ניהול קהילתיים, אך הם אינם חלק מהפרויקט. גישה זו מתאימה למי שמעדיף לשמור את מצב המערכת בקבצים ולנהל שינויים באמצעות בקרת גרסאות.

NetBird מספקת את המוצר המלא: לקוח ייעודי, לוח בקרה (dashboard), ספק זהות (identity provider) מובנה, ומדיניות גישה המנוהלת דרך הדפדפן. המשמעות היא יותר רכיבים שצריך לתחזק על ה-VPS, אך העבודה הנדרשת פחותה משמעותית אם עליכם להעביר את הניהול לעמית שאינו עובד עם ה-terminal.

הריצו את Headscale אם אתם כבר מושקעים בלקוחות של Tailscale או אם אתם מעוניינים ב-control plane מינימלי ככל האפשר. הריצו את NetBird אם כמה אנשים צריכים לנהל את ה-peers ואתם זקוקים לממשק ניהול ו-SSO ללא צורך בהרכבת פתרון עצמאי. לפני שתחליטו, בדקו מה כוללת התוכנית החינמית של Tailscale, שכן קבוצה המונה עד שישה משתמשים עם מספר בלתי מוגבל של מכשירים אינה משלמת דבר על שרת ניהול מרוחק, וייתכן שאין לה כל סיבה להריץ אחד כזה בעצמה. מעבר לרף זה, העלות גדלה לפי מספר האנשים ולא לפי מספר המכונות, לכן חישוב העלות של Tailscale עבור הקבוצה שלכם יספק לכם נתון שתוכלו לשקול מול עלות ה-VPS והזמן שנדרש לתחזוקת המערכת הזו.

מהו גודל ה-VPS המינימלי להרצת המערכת?

המינימום המתועד הוא 1 CPU ו-2 GB זיכרון. לפי ההערות של NetBird, הרף הנוכחי עומד על כ-1 GB RAM כעת, מאחר שניהול המשתמשים הוא מקומי, זאת לעומת 2 GB עד 4 GB שנדרשו במבנה הישן שכלל פריסה מלאה של Zitadel כחלק מה-stack. מומלץ לרכוש 2 GB. מרווח הפעולה הנוסף מאפשר לשדרג ולמשוך images חדשים בזמן שהישנים עדיין תופסים מקום בדיסק.

ישנם שלושה רכיבים שניתן לוותר עליהם בבטחה בשרת קטן. ניתן לוותר על שירות ה-NetBird Proxy, שנועד לפרסם שירותים פנימיים תחת שמות מתחם ציבוריים ואינו קשור לחיבור בין ה-peers. ניתן לוותר גם על CrowdSec, שמומלץ להוסיף לשרת חשוף בשלב מאוחר יותר ולא ביום הראשון. מומלץ להישאר עם מאגר ה-SQLite המוגדר כברירת מחדל ב-volume מסוג netbird_data, ולעבור ל-PostgreSQL רק כאשר מפצלים את הפריסה בין כמה מכונות או כאשר מגיעים לעומסי עבודה משמעותיים; זהו תהליך הגירה שניתן לבצע בהמשך.

ה-relay הוא הרכיב היחיד שאין לוותר עליו. שני peers שמאחורי NAT המקצה פורט שונה לכל יעד לעולם לא יצליחו ליצור מנהרה ישירה, ולכן ה-relay הוא הנתיב היחיד שמאפשר להם לעבוד. השבתתו חוסכת מעט מאוד זיכרון וגורמת לניתוקים שקשה לאתר את מקורם.

כאשר שרת אחד כבר אינו מספיק, ה-relays הם הרכיב הראשון שכדאי להעביר למכונה נפרדת. relay עצמאי רץ עם NB_LISTEN_ADDRESS, NB_EXPOSED_ADDRESS, NB_AUTH_SECRET ו-NB_ENABLE_STUN. ה-shared secret חייב להיות זהה ב-relay ובשרת הראשי, אחרת הלקוחות לא יצליחו לבצע אימות מולו.

מצבי כשל ומה תראו

לוח הבקרה מציג אזהרת תעודה. Traefik לא הצליח להנפיק תעודה. הריצו את docker compose logs traefik | grep -i acme. יש לכך שתי סיבות. או ש-dig +short netbird.example.com עדיין לא מפנה ל-VPS הזה, או שפורט TCP 80 חסום איפשהו בין Let's Encrypt לבין המכולה, בדרך כלל ב-firewall של ספק התשתית ולא ב-ufw. תקנו את מקור הבעיה לפני ניסיון חוזר בלולאה, כיוון שאימותים שנכשלו מוגבלים בקצב (rate limited) ותיחסמו מביצוע ניסיונות נוספים למשך שעה.

הלקוח מדווח על חיבור, אך לוח הבקרה ריק. הלקוח נרשם לשירות המנוהל של NetBird, כיוון ש---management-url היה חסר. הריצו את netbird status --detail וקראו את השורה Management:, המציינת את השרת שאליו הוא מתחבר בפועל. אם מופיע Management: Connected to https://api.netbird.io:443, סימן שהחיבור מופנה לענן. הריצו את sudo netbird down, ולאחר מכן שוב את sudo netbird up --management-url https://netbird.example.com.

כל עמית (peer) מציג Connection type: Relayed. לא נוצרים מנהרות ישירות, ולכן כל התעבורה עוברת דרך ה-VPS שלכם ומוסיפה השהיה (latency). בדקו את פורט UDP 3478 ב-firewall של ה-VPS וב-firewall של ספק התשתית, שכן STUN הוא המנגנון המאפשר לעמית ללמוד את כתובת ה-IP הציבורית והפורט שלו. הפקודה netbird status --detail מציגה גם את Direct: false ואת סוגי ה-ICE (interactive connectivity establishment) candidate עבור כל עמית, מה שמעיד על השלב אליו הגיע הניסיון. ברשתות מסוימות, relayed הוא התוצאה היחידה האפשרית ואין בכך תקלה.

עמית מצטרף אך לא מצליח להגיע לשום יעד. הימצאות ב-mesh אינה מבטיחה ששני עמיתים יכולים לתקשר. מדיניות גישה (access policies) קובעת זאת, וקבוצה ללא מדיניות משויכת לא תגיע לשום מקום. בדקו את המדיניות בלוח הבקרה לפני שאתם מתחילים לנפות שגיאות בניתובים וב-firewall.

netbird status מדווח על בעיית daemon. השירות אינו רץ. השתמשו ב-sudo netbird service status וב-sudo netbird service start. לוגים של הלקוח נמצאים ב-/var/log/netbird/client.log. לכל בעיה שאינכם מצליחים לאתר, netbird debug bundle --anonymize --system-info אוספת לוגים, סטטוס, ניתובים, הגדרות DNS ומצב ה-firewall לארכיון אחד.

גיבויים ושדרוגים

שני רכיבים מרכיבים את כל ההתקנה: הספרייה המכילה את docker-compose.yml ואת config.yaml, וה-volume של Docker המכיל את מסד הנתונים ואת מפתחות ההצפנה. יש לגבות אותם יחד. config.yaml מכיל את המפתח שמצפין את הנתונים במאגר, לכן עותק של מסד הנתונים ללא מפתח זה ישוחזר למצב שבו לא ניתן לקרוא דבר.

docker volume ls
docker compose down
sudo tar czf netbird-config.tgz -C ~ netbird
docker run --rm -v netbird_netbird_data:/data -v "$PWD":/backup \
  alpine tar czf /backup/netbird-data.tgz -C /data .
docker compose up -d

Compose מוסיף תחילית של שם ספריית הפרויקט לשמות ה-volumes, לכן ה-volume המתועד כ-netbird_data מופיע בדרך כלל כ-netbird_netbird_data. הריצו תחילה את docker volume ls והשתמשו בשם שהוא מציג, אחרת ה-docker run שלעיל ייכשל בכך שייצור בשקט volume ריק ולא יגבה דבר. שמרו את הארכיונים מחוץ ל-VPS. אם כבר יש לכם כלי גיבוי, restic או BorgBackup יטפלו בחלק של הגיבוי מחוץ לאתר.

שדרוג השרת מתבצע באמצעות משיכה (pull) ויצירה מחדש (recreate):

docker compose pull
docker compose up -d
docker compose ps

לפני שתסתמכו על כך, הריצו את docker compose config | grep image:. כל תגית (tag) שכתוב בה latest צריכה להיות מקובעת לגרסה ספציפית, מאותה סיבה שקיבעתם את סקריפט ההתקנה: אתם רוצים לדעת מה רץ, ואתם רוצים גרסה לחזור אליה כאשר שדרוג משתבש. לקוחות משתדרגים דרך מנהל החבילות שדרכו הותקנו.

FAQ

האם אני זקוק לספק זהות (Identity Provider) משלי כדי לארח את NetBird בעצמי?

לא. הגרסאות הנוכחיות כוללות מאגר משתמשים מובנה, כך שניתן ליצור את חשבון הניהול הראשון בדפדפן בכתובת https://netbird.example.com ולהוסיף משתמשים מלוח הבקרה לאחר מכן. ספק OIDC חיצוני הוא אופציונלי וניתן להוסיף אותו מאוחר יותר באמצעות ארבעה ערכים: שם, client ID, client secret ו-issuer. מדריכים המורים לפרוס את Zitadel או Keycloak לפני NetBird מתארים הגדרה שכבר אינה נדרשת, וביצועם מחייב הרצה של שירות נוסף ללא צורך.

מדוע כל העמיתים (Peers) שלי מציגים Connection type: Relayed?

חיבורים ישירים אינם נוצרים, ולכן התעבורה עוברת דרך ה-relay בשרת ה-VPS שלך. הסיבה הנפוצה לכך היא חסימה של פורט UDP 3478, שהוא פורט ה-STUN שבו עמיתים משתמשים כדי לגלות את הכתובת והפורט הציבוריים שלהם. פתח פורט זה ב-firewall של ה-VPS וב-firewall הרשתי של ספק הענן שלך, לאחר מכן הרץ שוב את netbird status --detail וקרא את השורה Direct:. ברשת שבה ה-NAT מקצה פורט שונה לכל יעד, מצב relayed הוא התוצאה האפשרית היחידה ואין מדובר בתקלה בתצורה.

הלקוח שלי התחבר אך לוח הבקרה לא מציג עמיתים. מה קרה?

הלקוח נרשם לשירות המנוהל של NetBird במקום לשרת שלך, דבר שקורה כאשר --management-url אינו מוגדר. הפקודה netbird status --detail מדפיסה את השרת שאליו הלקוח מתקשר בשורה Management:, כך שערך כמו https://api.netbird.io:443 מאשר זאת. הרץ את sudo netbird down, לאחר מכן את sudo netbird up --management-url https://netbird.example.com, והעמית יופיע בלוח הבקרה שלך.

במה שונה NetBird באירוח עצמי מ-Headscale?

שניהם מחליפים שרת בקרה מנוהל בשרת שאתה מריץ בעצמך. Headscale הוא מישור בקרה (control plane) בלבד: אתה מנהל אותו באמצעות הפקודה headscale וקובץ תצורה, אין לו ממשק ניהול רשמי, והוא מפעיל את לקוחות Tailscale הרשמיים. NetBird מספקת לקוח משלה, לוח בקרה לניהול ואינטגרציה עם ספקי זהות באותה חבילה. Headscale קל יותר להרצה ושומר את המצב שלו בקבצים. NetBird קל יותר למסירה לאנשים שאינם משתמשים בטרמינל.

איזה גודל VPS נדרש עבור שרת NetBird באירוח עצמי?

המינימום המתועד הוא 1 CPU ו-2 GB זיכרון, ו-2 GB הוא הערך המומלץ לרכישה. הרף המעשי ירד לאזור ה-1 GB בגרסאות האחרונות, כיוון שספק הזהות מוטמע כעת בתוך המערכת ולא כפריסה נפרדת. וותר על שירותי ה-proxy ו-CrowdSec האופציונליים במהלך ההתקנה, והישאר עם מאגר הנתונים SQLite המוגדר כברירת מחדל עד שתזדקק באמת ל-PostgreSQL.