NetBird VPN सर्वर को VPS पर self-host कैसे करें

NetBird VPN सर्वर को self-host करने के लाभ

NetBird VPN सर्वर को self-host करने से control plane आपके अपने VPS पर आ जाता है: यह वह हिस्सा है जो peer list को रखता है, यह तय करता है कि कौन सी मशीन किससे जुड़ सकती है, और NAT (network address translation) के पीछे मौजूद दो peers को एक-दूसरे को खोजने में मदद करता है। tunnels स्वयं WireGuard ही रहती हैं, जो सीधे आपकी मशीनों के बीच encrypted होती हैं। बदलाव यह होता है कि कोई बाहरी कंपनी आपकी device inventory या login flow को नियंत्रित नहीं करती। यह स्पष्ट रखें कि इससे आपको क्या मिलता है, क्योंकि एक hosted control plane भी आपके traffic को encrypt करने वाली keys को कभी नहीं रखता, और यदि coordination server breach हो जाए तो वह वास्तव में क्या कर सकता है इसकी सूची उतनी सीमित है जितनी अधिकांश लोग इसे पढ़ने से पहले नहीं समझते।

NetBird उन दो चीजों के बीच स्थित है जिन्हें आप शायद पहले से जानते हैं। यह एक mesh overlay है, इसलिए peers एक gateway के माध्यम से सब कुछ भेजने के बजाय सीधे एक-दूसरे से जुड़ते हैं। यह end-to-end self-hostable भी है, जो इसे Headscale, self-hosted Tailscale control server के समकक्ष खड़ा करता है। यदि आपने अब तक केवल single-gateway tunnel ही चलाई है, तो पहले plain WireGuard और mesh overlay के बीच का अंतर पढ़ें, क्योंकि वही mental model इस पृष्ठ के बाकी हिस्सों को उपयोगी बनाता है।

यदि आप वास्तव में एक ऐसा सर्वर चाहते हैं जहाँ से आपका सारा traffic बाहर निकले, तो mesh की आवश्यकता से अधिक जटिलता बढ़ जाती है। एक single VPS पर plain WireGuard VPN या Tailscale exit node कम मेहनत में यह काम कर देते हैं। और यदि लक्ष्य मशीनों को एक-दूसरे से जोड़ने के बजाय एक private network तक पहुँचना है, तो VPS पर Tailscale subnet router नीचे दिए गए पूरे stack के बिना ही उस range को आपके मौजूदा tailnet में advertise कर देता है।

स्टैक वास्तव में क्या चलाता है

लेआउट हाल ही में बदल गया है, और अधिकांश पुराने लेख पुराने लेआउट का वर्णन करते हैं। अक्टूबर 2026 में v0.80.0 और v0.76.2 के विरुद्ध जाँच की गई, जो कि वह release है जिसे यह गाइड पिन करती है, quickstart script डिफ़ॉल्ट रूप से तीन services के साथ एक Compose file लिखती है।

• netbird-server में management API, signal service, एम्बेडेड STUN listener के साथ relay, और एक एम्बेडेड identity provider शामिल है। पुराने releases में ये अलग containers थे और identity provider एक अलग Zitadel install था जिसे आपको पहले build करना पड़ता था।
• dashboard एडमिन वेब कंसोल है।
• traefik TLS (transport layer security) को terminate करता है और पहली बार start होने पर Let's Encrypt से certificate का अनुरोध करता है।

दो और services मौजूद हैं और जब तक आप प्रॉम्प्ट पर हाँ नहीं कहते, तब तक वे बंद रहती हैं। NetBird Proxy service आंतरिक services को public hostnames पर प्रकाशित करती है। CrowdSec अपमानजनक traffic को फ़िल्टर करता है। एक कार्यशील मेश बनाने के लिए इनमें से किसी की भी आवश्यकता नहीं है, और दोनों ही एक छोटे बॉक्स पर memory की खपत करते हैं।

यदि आप एक ही Docker container में wg-easy से आ रहे हैं, तो यह भागों की संख्या में एक बड़ी वृद्धि है। यह आपको access policies, प्रति-उपयोगकर्ता खाते, और ऐसे peers प्रदान करता है जो एक gateway के बजाय सीधे एक-दूसरे से जुड़ते हैं।

शुरू करने से पहले आपकी आवश्यकताएं

एक public domain name अनिवार्य है। Dashboard, API और relay सभी port 443 पर HTTPS का उपयोग करते हैं। Traefik, Let's Encrypt से TLS-ALPN-01 challenge का उपयोग करके certificate प्राप्त करता है, जिसे port 443 पर पूरा किया जाता है। इसके लिए एक ऐसे नाम की आवश्यकता होती है जो public internet से आपके VPS पर resolve हो सके। इस प्रक्रिया में केवल IP address काम नहीं करेगा।

एक A record बनाएं, netbird.example.com जो आपके VPS के public IPv4 address की ओर इशारा करता हो, और कुछ भी चलाने से पहले इसके propagate होने की प्रतीक्षा करें।

dig +short netbird.example.com

यह आपके सर्वर का address दिखाना चाहिए। DNS propagate होने से पहले installer चलाने का अर्थ है कि certificate request पहली बार में ही विफल हो जाएगी। बार-बार विफल validation के कारण Let's Encrypt की rate limits लग सकती हैं, जिसके बाद आपको पुनः प्रयास करने के लिए limit के reset होने का इंतज़ार करना होगा।

इंटरनेट से तीन ports तक पहुंच होनी चाहिए: HTTPS पर redirect के लिए TCP 80, dashboard, API, signal, relay traffic और certificate challenge के लिए TCP 443, और STUN के लिए UDP 3478।

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

इन्हें अपने provider के network firewall पर भी खोलें। अधिकांश VPS panels में यह एक अलग नियंत्रण होता है, और यही कारण है कि जिस सर्वर का ufw status सही दिखता है, वह भी connections को अस्वीकार कर देता है।

STUN (session traversal utilities for NAT) वह तरीका है जिससे एक peer उस public address और port को जान पाता है जो उसके NAT ने उसे assign किया है, ताकि दो peers एक direct tunnel बनाने का प्रयास कर सकें। यदि आप UDP 3478 को block करते हैं, तो भी peers TCP 443 पर relay के माध्यम से connect हो जाएंगे, इसलिए कुछ भी टूटा हुआ नहीं लगेगा। इसके बजाय आपको हर peer पर Connection type: Relayed दिखाई देगा, और सारा traffic peer-to-peer जाने के बजाय आपके VPS से होकर गुजरेगा।

Software के स्तर पर आपको Docker के साथ Compose v2 plugin, और साथ ही jq और curl की आवश्यकता होगी। Script Docker, Compose और jq की जाँच करती है और यदि इनमें से कोई भी मौजूद न हो तो रुक जाती है। यह curl का उपयोग करती है, लेकिन उसकी जाँच नहीं करती, इसलिए उसे पहले install करें। यदि इस सर्वर पर Docker नया है, तो पहले Docker Compose को VPS पर कार्यशील बनाएं।

Quickstart script के साथ NetBird सर्वर इंस्टॉल करें

दस्तावेजीकृत one-liner नवीनतम release को सीधे shell में पाइप करता है:

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

इसके बजाय इसे पिन करें। latest बदलता रहता है, इसलिए दो सप्ताह के अंतराल पर चलाई गई एक ही command दो अलग-अलग install तैयार करती है, और disk पर ऐसा कुछ भी रिकॉर्ड नहीं होता जो यह बताए कि किसने आपकी 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

script सबसे पहले domain के बारे में पूछती है:

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

फिर यह पूछती है कि TLS को कैसे handle किया जाएगा:

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 से 4 एक config snippet लिखते हैं और wiring आप पर छोड़ देते हैं, और विकल्प 5 केवल Compose file लिखता है और setup documentation को terminal पर print करता है। यह उस box पर सही है जो पहले से ही proxy चला रहा है, लेकिन एक नए सर्वर पर यह गलत है। विकल्प 0 फिर एक email address मांगता है, जिसे Traefik आपके Let's Encrypt account के साथ register करता है। prompt अभी भी इसे certificate notifications के लिए एक address कहता है, लेकिन Let's Encrypt ने 4 जून, 2025 को expiry emails भेजना बंद कर दिया है, इसलिए renewal की समस्याएं आपके inbox के बजाय Traefik log में दिखाई देती हैं।

पहली बार install करते समय NetBird Proxy service के लिए मना कर दें। इसे एक और DNS record चाहिए, एक wildcard *.netbird.example.com CNAME जो netbird.example.com की ओर इशारा करता हो, और यह एक साधारण mesh के लिए कुछ नहीं करता है। CrowdSec prompt केवल तभी दिखाई देता है जब proxy सक्षम होता है, इसलिए proxy को अस्वीकार करने से यह भी skip हो जाता है। दोनों को बाद में जोड़ा जा सकता है।

script वर्तमान directory में लिखती है: docker-compose.yml, config.yaml (mode 600 के साथ), और dashboard.env। bundled Traefik के साथ, यह traefik-dynamic.yaml और proxy.env को केवल तभी जोड़ती है जब आप NetBird Proxy को सक्षम करते हैं। उस directory को ऐसी state मानें जिसे आपको संभाल कर रखना है, क्योंकि config.yaml में वह key होती है जो store में डेटा को encrypt करती है। इसे खो देना ऐसी समस्या नहीं है जिसे reinstall करके ठीक किया जा सके।

docker compose ps
docker compose logs -f netbird-server

हर service को running पढ़ना चाहिए, और सर्वर log को loop में restart होने के बजाय स्थिर हो जाना चाहिए। certificate को अलग से monitor करें:

docker compose logs traefik | grep -i acme

ACME (automatic certificate management environment) वह protocol है जिसका उपयोग Traefik certificate प्राप्त करने के लिए करता है। यहाँ होने वाली त्रुटियां लगभग हमेशा DNS या बंद port 443 के कारण होती हैं।

पहला एडमिन अकाउंट बनाएँ

https://netbird.example.com खोलें। नए इंस्टॉलेशन पर यह लॉगिन फॉर्म के बजाय सेटअप पेज पर ले जाता है। एक ईमेल पता, नाम और पासवर्ड दर्ज करें, फिर Create Account पर क्लिक करें। यह पहला एडमिन बन जाता है और पेज लॉगिन फॉर्म पर रीडायरेक्ट हो जाता है।

यह अकाउंट NetBird के अपने यूजर स्टोर में रहता है, जो netbird-server कंटेनर में एम्बेडेड आइडेंटिटी प्रोवाइडर द्वारा संचालित होता है। इसमें कोई बाहरी चीज़ शामिल नहीं है। यह एक साल पहले के सेल्फ-होस्टेड NetBird से सबसे बड़ा बदलाव है, जब एक वर्किंग इंस्टॉलेशन का मतलब था कि पहले Zitadel या Keycloak को खड़ा करना और कुछ भी शुरू होने से पहले setup.env में चार OIDC (OpenID Connect) वैल्यूज को कॉपी करना।

यदि आपको सेटअप पेज के बजाय ब्राउज़र सर्टिफिकेट चेतावनी मिलती है, तो सर्टिफिकेट जारी नहीं हुआ है। आगे बढ़ने से पहले इसे ठीक करें, क्योंकि डैशबोर्ड उसी होस्टनेम पर API से बात करता है और खराब सर्टिफिकेट के कारण भ्रमित करने वाले तरीकों से विफल हो जाता है।

अपने पहले peer को जोड़ें

किसी भी Linux मशीन पर client install करें, जिसमें VPS स्वयं भी शामिल है यदि आप इसे mesh में रखना चाहते हैं:

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

Debian और Ubuntu पर वह script NetBird की package repository को configure करती है और फिर apt के माध्यम से client install करती है, इसलिए package manager ही अंततः इसका प्रबंधन करता है। यदि किसी script को सीधे shell में pipe करना आपको असुरक्षित लगता है, तो पहले इसे curl -fsSL -o install.sh https://pkgs.netbird.io/install.sh के साथ save करें और sh install.sh चलाने से पहले इसे पढ़ लें। किसी भी स्थिति में, पुष्टि करें कि क्या install हुआ है:

apt-cache policy netbird

netbird command line client और daemon है। netbird-ui desktop tray app है, और headless server के लिए इसकी कोई आवश्यकता नहीं है।

अब client को अपने server की ओर point करें:

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

--management-url को न छोड़ें, अन्यथा client NetBird की hosted service के साथ register हो जाएगा, क्योंकि यह compiled-in default है। command तब भी सफल होगी, मशीन को एक address भी मिल जाएगा, लेकिन आपका self-hosted dashboard खाली रहेगा। लगभग हर कोई एक बार इस गलती में फंस जाता है।

command login पूरा करने के लिए browser में खोलने हेतु एक URL print करती है। उसके बाद:

netbird status
ip addr show wt0

netbird status से चार line पढ़ें: Management: Connected, Signal: Connected, प्रत्येक उपलब्ध relay की जानकारी देने वाली एक Relays: line, और overlay range में एक NetBird IP:। wt0 वह WireGuard interface है जिसे NetBird बनाता है, और इसमें वही address होना चाहिए।

एक दूसरी मशीन को setup key के साथ unattended तरीके से जोड़ना

जिस मशीन पर browser नहीं है और जिसे कोई इस्तेमाल नहीं कर रहा, उस पर browser login काम नहीं करता। Setup key एक pre-authentication token है जो interactive step के बिना मशीन को register करता है। इसे dashboard में Setup Keys के अंतर्गत बनाएँ।

ये दो प्रकार की होती हैं। एक one-off key केवल एक मशीन को authenticate करती है और फिर समाप्त हो जाती है। एक reusable key कई मशीनों को register करती है, जिसमें आप संख्या की सीमा भी तय कर सकते हैं। दोनों की एक expiry होती है, और दोनों ही नई peer को अपने आप एक group में assign कर सकती हैं, ताकि मशीन के जुड़ते ही उस group के access rules लागू हो जाएँ।

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

--hostname dashboard में दिखने वाले नाम को set करता है। इसके बिना, peer वही नाम ले लेती है जो मशीन का अपना नाम है, और ubuntu नाम वाली बहुत सारी entries किसी के काम नहीं आतीं।

Containers और कम समय तक चलने वाले build agents के लिए, key बनाते समय उसे ephemeral के रूप में mark करें। Ephemeral key के साथ register की गई peers 10 मिनट से अधिक offline रहने पर अपने आप हटा दी जाती हैं, जिससे peer list में मृत entries नहीं रहतीं।

Setup keys का उपयोग करने से पहले एक सीमा को समझना जरूरी है: key की expiry या उसे revoke करने से नए registrations रुक जाते हैं, लेकिन इससे वे मशीनें disconnect नहीं होतीं जिन्होंने पहले ही इसके जरिए register कर लिया है। किसी मशीन का access हटाने का मतलब उस peer को हटाना है।

क्या आपको अभी भी एक अलग identity provider की आवश्यकता है?

छोटे इंस्टॉलेशन के लिए, नहीं। इन-बिल्ट user store डैशबोर्ड से बनाए गए खातों को संभालता है, और यह कुछ लोगों के लिए पर्याप्त है।

आपको एक बाहरी identity provider की आवश्यकता तब होती है जब आपके पास पहले से ही एक provider हो और आप उपयोगकर्ताओं की दूसरी सूची नहीं बनाना चाहते। NetBird OIDC का समर्थन करने वाले किसी भी provider को स्वीकार करता है। अपने provider में एक confidential OIDC client रजिस्टर करें, फिर इसे NetBird डैशबोर्ड में चार मानों के साथ जोड़ें: name, client ID, client secret और issuer। NetBird आपको एक redirect URL देता है जिसे आपको वापस provider में पेस्ट करना होता है। Google, Microsoft Entra ID, Okta, Zitadel, Keycloak, Authentik और Pocket ID के लिए विशेष integrations मौजूद हैं, और बाकी सभी को generic OIDC के रूप में जोड़ा जा सकता है। यदि आप पहले से ही अपने self-hosted single sign-on के रूप में Authentik का उपयोग कर रहे हैं, तो यह वह तरीका है जिससे आप दो के बजाय एक ही खाता सूची बनाए रख सकते हैं।

provider जोड़ने के बाद भी local login उपलब्ध रहता है, और प्रत्येक कॉन्फ़िगर किया गया provider लॉगिन पेज पर दिखाई देता है। एक मजबूत पासवर्ड के साथ एक local admin खाता सुरक्षित रखें। इससे OIDC कॉन्फ़िगरेशन खराब होने पर भी आपके पास सिस्टम में प्रवेश करने का एक रास्ता बना रहेगा।

NetBird या Headscale: आपको कौन सा control plane चलाना चाहिए?

दोनों एक ही dependency को हटाते हैं, यानी वह hosted control server जिससे आपके clients अन्यथा संपर्क करते। ये दोनों एक ही तरह के project नहीं हैं।

Headscale, Tailscale control server को फिर से implement करता है, और आप आधिकारिक Tailscale clients का उपयोग करना जारी रखते हैं। इसमें कोई आधिकारिक web console नहीं है। आप users और pre-authentication keys को config file के विरुद्ध headscale command से manage करते हैं। Community web interfaces मौजूद हैं, लेकिन वे project का हिस्सा नहीं हैं। यह उन लोगों के लिए उपयुक्त है जो अपनी state को files में और अपने बदलावों को version control में रखना चाहते हैं।

NetBird पूरा product प्रदान करता है: इसका अपना client, अपना dashboard, एक embedded identity provider, और browser में edit की जाने वाली access policies। आपके VPS पर इसमें अधिक components होते हैं, और किसी ऐसे सहयोगी को सौंपने के लिए यह बहुत कम मेहनत वाला काम है जो कभी terminal नहीं खोलेगा।

यदि आप पहले से ही Tailscale clients में निवेशित हैं या आप सबसे छोटा संभव control plane चाहते हैं, तो Headscale चलाएं। यदि कई लोगों को peers को manage करने की आवश्यकता है और आप बिना कुछ अलग से जोड़े एक console और SSO चाहते हैं, तो NetBird चलाएं। किसी एक को चुनने से पहले, Tailscale का free plan वास्तव में क्या कवर करता है देखें, क्योंकि छह users के भीतर आने वाला एक गैर-व्यावसायिक समूह hosted control plane के लिए कुछ भी भुगतान नहीं करता है, जिसमें असीमित user devices और शुरुआत के लिए 50 tagged resources मिलते हैं, और हो सकता है कि उन्हें इसे चलाने का कोई कारण ही न हो। उस सीमा के बाद, बिल मशीनों की संख्या के बजाय लोगों की संख्या के साथ बढ़ता है, इसलिए Tailscale आपके समूह से क्या शुल्क लेगा, इसका हिसाब लगाना आपको एक ऐसा आंकड़ा देता है जिसकी तुलना आप VPS और इस stack पर खर्च होने वाले घंटों से कर सकते हैं।

यह सेटअप चलाने के लिए VPS कितना छोटा हो सकता है?

दस्तावेजीकरण के अनुसार न्यूनतम आवश्यकता 1 CPU और 2 GB मेमोरी है। NetBird के अपने नोट्स के अनुसार, अब जब user management स्थानीय (local) है, तो न्यूनतम आवश्यकता लगभग 1 GB RAM है। पुराने लेआउट में, जब पूरा Zitadel deployment स्टैक का हिस्सा था, तब 2 GB से 4 GB की आवश्यकता होती थी। 2 GB वाला VPS खरीदें। अतिरिक्त headroom होने से upgrade के दौरान नए images pull करना संभव होता है, जबकि पुराने images अभी भी disk पर मौजूद रहते हैं।

छोटे सर्वर पर तीन चीजों को छोड़ना सुरक्षित है। NetBird Proxy service को न चुनें; यह internal services को public hostnames पर publish करने के लिए है और इसका peers के connect होने से कोई लेना-देना नहीं है। CrowdSec को छोड़ दें, जिसे script केवल proxy के साथ ही offer करती है। इसे पहले दिन के बजाय बाद में किसी exposed सर्वर पर जोड़ना बेहतर है। default SQLite store को netbird_data volume में ही रहने दें। PostgreSQL पर केवल तब जाएँ जब आप deployment को अलग-अलग मशीनों पर बाँटें या वास्तविक concurrency की समस्या आए। इसे बाद में migration के जरिए किया जा सकता है, जैसा कि दस्तावेज़ों में बताया गया है।

Relay वह एकमात्र component है जिसे आप हटा नहीं सकते। यदि दो peers का NAT हर destination के लिए अलग port assign करता है, तो वे कभी भी direct tunnel स्थापित नहीं कर पाएंगे। इसलिए, relay ही एकमात्र रास्ता है जो उन्हें काम करने योग्य बनाता है। इसे disable करने से बहुत कम मेमोरी बचती है और यह कनेक्शन को इस तरह तोड़ देता है जिसे ट्रैक करना कठिन होता है।

जब एक सर्वर पर्याप्त न रहे, तो सबसे पहले relays को वहां से हटाकर अलग करें। एक standalone relay NB_LISTEN_ADDRESS, NB_EXPOSED_ADDRESS, NB_AUTH_SECRET और NB_ENABLE_STUN के साथ चलता है। shared secret का relay और main server दोनों पर एक समान होना अनिवार्य है, अन्यथा clients उस पर authenticate नहीं हो पाएंगे।

विफलता के प्रकार और आपको क्या दिखाई देगा

डैशबोर्ड पर certificate warning दिखाई देती है। Traefik ने certificate प्राप्त नहीं किया है। docker compose logs traefik | grep -i acme चलाएँ। इसके दो कारण हो सकते हैं। या तो dig +short netbird.example.com अभी तक इस VPS को point नहीं कर रहा है, या TCP 443 पोर्ट Let's Encrypt और container के बीच कहीं बंद है, जो आमतौर पर ufw के बजाय प्रदाता के नेटवर्क फायरवॉल पर होता है। challenge का उत्तर 443 पर दिया जाता है, इसलिए खुला हुआ पोर्ट 80 यहाँ मदद नहीं करता है। लूप में पुनः प्रयास करने से पहले कारण को ठीक करें, क्योंकि Let's Encrypt प्रति hostname प्रति घंटे केवल पाँच विफल validation की अनुमति देता है, और एक लूप आपको उस सीमा के फिर से भरने तक पुनः प्रयास करने से रोक देगा।

client कहता है कि वह connect हो गया है और डैशबोर्ड खाली है। client ने NetBird की hosted service के साथ register किया है, क्योंकि --management-url गायब था। netbird status --detail चलाएँ और Management: लाइन को पढ़ें, जो उस सर्वर का नाम बताती है जिससे वह वास्तव में बात कर रहा है। Management: Connected to https://api.netbird.io:443 देखने का मतलब है कि यह cloud पर चला गया है। sudo netbird down चलाएँ, फिर दोबारा sudo netbird up --management-url https://netbird.example.com चलाएँ।

प्रत्येक peer Connection type: Relayed दिखाता है। कोई direct tunnel नहीं बन रही है, इसलिए सारा traffic आपके VPS से होकर गुजरता है और latency का एक hop जुड़ जाता है। VPS फायरवॉल और प्रदाता फायरवॉल पर UDP 3478 की जाँच करें, क्योंकि STUN ही वह माध्यम है जो एक peer को अपना public address और port जानने देता है। netbird status --detail प्रत्येक peer के लिए Direct: false और ICE (interactive connectivity establishment) candidate प्रकार भी print करता है, जो दिखाता है कि प्रयास कहाँ तक पहुँचा। कुछ नेटवर्क पर relayed ही एकमात्र उपलब्ध परिणाम होता है और इसमें कुछ भी गलत नहीं है।

एक peer जुड़ता है और कुछ भी access नहीं कर पाता है। mesh में होने का मतलब यह नहीं है कि दो peer आपस में बात कर सकते हैं। access policies यह तय करती हैं, और जिस group के साथ कोई policy नहीं जुड़ी होती, वह कुछ भी access नहीं कर पाता है। routes और firewalls को debug करना शुरू करने से पहले डैशबोर्ड में policy की जाँच करें।

netbird status daemon समस्या की रिपोर्ट करता है। service चल नहीं रही है। sudo netbird service status और sudo netbird service start का उपयोग करें। client logs /var/log/netbird/client.log पर उपलब्ध हैं। ऐसी किसी भी चीज़ के लिए जिसे आप समझ नहीं पा रहे हैं, netbird debug bundle --anonymize --system-info logs, status, routes, DNS settings और फायरवॉल स्थिति को एक archive में collect करता है।

Backups and upgrades

पूरे इंस्टॉलेशन को सुरक्षित रखने के लिए दो चीजें आवश्यक हैं: वह डायरेक्टरी जिसमें docker-compose.yml और config.yaml मौजूद हैं, और वह Docker volume जिसमें डेटाबेस और एन्क्रिप्शन कीज़ (encryption keys) होती हैं। इनका बैकअप एक साथ लें। config.yaml में वह की (key) होती है जो स्टोर में मौजूद डेटा को एन्क्रिप्ट करती है, इसलिए इसके बिना डेटाबेस की कॉपी को रिस्टोर करने पर आप डेटा नहीं पढ़ पाएंगे।

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 वॉल्यूम के नामों के आगे प्रोजेक्ट डायरेक्टरी का नाम जोड़ देता है, इसलिए जिस वॉल्यूम को netbird_data के रूप में डॉक्यूमेंट किया गया है, वह आमतौर पर netbird_netbird_data के रूप में दिखाई देता है। पहले docker volume ls चलाएं और उसके द्वारा प्रिंट किए गए नाम का उपयोग करें, अन्यथा ऊपर दिया गया docker run विफल हो जाएगा और चुपचाप एक खाली वॉल्यूम बनाकर कुछ भी आर्काइव नहीं करेगा। आर्काइव्स को VPS से बाहर रखें। यदि आपके पास पहले से कोई बैकअप टूल है, तो restic या BorgBackup ऑफसाइट बैकअप की प्रक्रिया को संभाल सकते हैं।

सर्वर को अपग्रेड करने के लिए इमेज को pull करें और कंटेनर को recreate करें:

docker compose pull
docker compose up -d
docker compose ps

इस पर भरोसा करने से पहले, docker compose config | grep image: चलाएं। latest पढ़ने वाले किसी भी टैग को एक विशिष्ट वर्ज़न पर पिन किया जाना चाहिए, उसी कारण से जिस कारण आपने इंस्टॉलेशन स्क्रिप्ट को पिन किया था: आप यह जानना चाहते हैं कि क्या चल रहा है, और अपग्रेड के दौरान गड़बड़ी होने पर आप वापस पुराने वर्ज़न पर जाना चाहते हैं। क्लाइंट्स उस पैकेज मैनेजर के माध्यम से अपग्रेड होते हैं जिससे उन्हें इंस्टॉल किया गया था।

FAQ

क्या NetBird को self-host करने के लिए मुझे अपने स्वयं के identity provider की आवश्यकता है?

नहीं। वर्तमान releases में एक built-in user store शामिल है, इसलिए आप ब्राउज़र में https://netbird.example.com पर पहला admin account बनाते हैं और उसके बाद dashboard से users जोड़ते हैं। एक बाहरी OIDC provider वैकल्पिक है और इसे बाद में चार values के साथ जोड़ा जा सकता है: name, client ID, client secret और issuer। जो guides आपको NetBird से पहले Zitadel या Keycloak deploy करने के लिए कहती हैं, वे एक ऐसे setup का वर्णन करती हैं जिसकी अब आवश्यकता नहीं है, और उनका पालन करने से आपको एक अतिरिक्त service चलानी पड़ती है।

मेरे सभी peers Connection type: Relayed क्यों दिखाते हैं?

Direct connections नहीं बन पा रहे हैं, इसलिए traffic आपके VPS पर मौजूद relay के माध्यम से जाता है। इसका सामान्य कारण UDP 3478 का block होना है, जो वह STUN port है जिसका उपयोग peers अपने public address और port को खोजने के लिए करते हैं। इसे VPS firewall और अपने provider के अलग network firewall पर खोलें, फिर netbird status --detail को दोबारा चलाएं और Direct: line को पढ़ें। ऐसे network पर जहाँ NAT प्रत्येक destination के लिए एक अलग port assign करता है, relayed ही एकमात्र संभावित परिणाम है और कुछ भी गलत configure नहीं है।

मेरा client connect हो गया है लेकिन dashboard पर कोई peer नहीं दिख रहा है। क्या हुआ?

Client ने आपके सर्वर के बजाय NetBird की hosted service के साथ register किया है, जो तब होता है जब --management-url को छोड़ दिया जाता है। netbird status --detail उस सर्वर को print करता है जिससे वह बात कर रहा है, जो Management: line पर दिखता है, इसलिए https://api.netbird.io:443 जैसी value इसकी पुष्टि करती है। sudo netbird down चलाएं, फिर sudo netbird up --management-url https://netbird.example.com चलाएं, और peer आपके dashboard में दिखाई देगा।

Self-hosted NetBird, Headscale से किस प्रकार भिन्न है?

दोनों एक hosted control server को आपके द्वारा चलाए जाने वाले सर्वर से बदलते हैं। Headscale केवल एक control plane है: आप इसे headscale command और एक config file के साथ manage करते हैं, इसमें कोई official web console नहीं है, और यह official Tailscale clients को चलाता है। NetBird अपना स्वयं का client, एक admin dashboard और identity provider integration को एक ही stack में प्रदान करता है। Headscale को चलाना छोटा है और यह अपनी state को files में रखता है। NetBird को उन लोगों को देना आसान है जो terminal का उपयोग नहीं करेंगे।

Self-hosted NetBird सर्वर के लिए किस आकार के VPS की आवश्यकता है?

दस्तावेजीकृत न्यूनतम 1 CPU और 2 GB memory है, और 2 GB ही वह संख्या है जिसे खरीदना चाहिए। हाल के releases में व्यावहारिक न्यूनतम सीमा लगभग 1 GB तक गिर गई है क्योंकि identity provider अब एक अलग deployment के बजाय embedded है। Install के दौरान वैकल्पिक proxy service को अस्वीकार करें, जो CrowdSec prompt को भी छोड़ देता है, और तब तक default SQLite store पर रहें जब तक आपको वास्तव में PostgreSQL की आवश्यकता न हो।