הקמת שרת NetBird VPN עצמאי על גבי VPS

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

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

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

אם מה שאתה מחפש בפועל הוא שרת יחיד שדרכו יוצאת כל התעבורה שלך, mesh הוא מנגנון מורכב יותר ממה שהמשימה דורשת. VPN מבוסס WireGuard רגיל על VPS יחיד או צומת יציאה (exit node) של Tailscale יבצעו זאת עם הרבה פחות מאמץ תפעולי.

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

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

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

קיימים שני שירותים נוספים שנשארים כבויים אלא אם תאשר זאת בהנחיה. שירות ה-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 באמצעות סקריפט ה-quickstart

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

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

במקום זאת, קבעו גרסה ספציפית. latest משתנה, לכן אותה פקודה שתורץ בהפרש של שבועיים תייצר שתי התקנות שונות, ושום דבר בדיסק לא יתעד איזו מהן יצרה את ה-config שלכם. הורידו גרסה מתויגת (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, המופעל על ידי ספק זהות (Identity Provider) המוטמע בתוך המכולה netbird-server. אין מעורבות של גורמים חיצוניים. זהו השינוי המשמעותי ביותר בהשוואה לגרסאות ה-self-hosted של NetBird מלפני שנה, שבהן התקנה תקינה דרשה תחילה הקמת Zitadel או Keycloak והעתקת ארבעה ערכי OIDC (OpenID Connect) לתוך setup.env לפני שניתן היה להתחיל בעבודה.

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

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

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

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

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

apt-cache policy netbird

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

כעת, כוונו את הלקוח אל השרת שלכם:

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

אם תשמיטו את --management-url, הלקוח יירשם לשירות המנוהל של 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) וסוכני בנייה זמניים, יש לסמן את המפתח כ-ephemeral בעת היצירה. מכונות שנרשמו באמצעות מפתח זמני יוסרו אוטומטית מהרשת לאחר שהיו במצב לא מקוון במשך יותר מ-10 דקות, מה שמונע הצטברות של רשומות "מתות" ברשימת המכונות.

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

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

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

יש צורך בספק זהות חיצוני כאשר כבר קיים כזה ולא רוצים לנהל רשימת משתמשים שנייה. 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 מתבצע באמצעות הפקודה headscale מול קובץ הגדרות. קיימים ממשקי ניהול קהילתיים, אך הם אינם חלק מהפרויקט. גישה זו מתאימה למי שמעדיף לשמור את המצב בקבצים ולנהל שינויים באמצעות מערכת בקרת גרסאות.

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

הריצו את Headscale אם אתם כבר מושקעים בלקוחות של Tailscale או אם אתם מחפשים את ה-control plane המינימלי ביותר. הריצו את NetBird אם כמה אנשים צריכים לנהל את ה-peers ואתם מעוניינים בקונסול וב-SSO מבלי להרכיב אותם בעצמכם.

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

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

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

ה-relay הוא הרכיב היחיד שאין לוותר עליו. שני עמיתים שמאחורי 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 לבין ה-container, בדרך כלל ב-firewall של ספק התשתית ולא ב-ufw. תקן את הגורם לפני שתנסה שוב בלולאה, כיוון שאימותים שנכשלו מוגבלים ב-rate limit ותיחסם מניסיונות נוספים למשך שעה.

הלקוח מדווח על התחברות אך לוח הבקרה ריק. הלקוח נרשם לשירות המנוהל של 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 הוא המנגנון המאפשר ל-peer ללמוד את כתובת ה-IP הציבורית והפורט שלו. הפקודה netbird status --detail מדפיסה גם את Direct: false ואת סוגי ה-ICE (interactive connectivity establishment) candidate עבור כל peer, מה שמראה עד לאיזה שלב הגיע הניסיון. ברשתות מסוימות, relayed הוא התוצאה היחידה האפשרית ואין בכך תקלה.

peer מצטרף אך לא מצליח להגיע לשום יעד. עצם השהות ב-mesh לא אומרת ששני peer יכולים לתקשר. מדיניות גישה (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

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

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

מדוע כל העמיתים (peers) שלי מופיעים כ-Connection type: Relayed?

חיבורים ישירים אינם נוצרים, ולכן התעבורה עוברת דרך ה-relay בשרת ה-VPS שלך. הסיבה הנפוצה לכך היא חסימה של פורט UDP 3478, שהוא פורט ה-STUN שבו משתמשים עמיתים כדי לגלות את כתובת ה-IP הציבורית והפורט שלהם. פתחו פורט זה ב-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.