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 तक, release v0.76.2 पर, quickstart script डिफ़ॉल्ट रूप से तीन services के साथ एक Compose file लिखती है।

• netbird-server में management API, signal service, embedded STUN listener के साथ relay, और एक embedded 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 को फ़िल्टर करता है। एक कार्यशील mesh बनाने के लिए इनमें से किसी की भी आवश्यकता नहीं है, और दोनों ही एक छोटे बॉक्स पर मेमोरी की खपत करते हैं।

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

शुरू करने से पहले आपको क्या चाहिए

एक public domain name अनिवार्य है। Dashboard, API और relay सभी port 443 पर HTTPS का उपयोग करते हैं, और Traefik, Let's Encrypt से HTTP challenge का उपयोग करके अपना certificate प्राप्त करता है। इसके लिए एक ऐसे नाम की आवश्यकता होती है जो 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 लग सकती हैं, जिससे आपको दोबारा प्रयास करने के लिए एक घंटे तक प्रतीक्षा करनी पड़ सकती है।

इंटरनेट से तीन ports तक पहुँच होनी चाहिए: certificate challenge और HTTPS पर redirect के लिए TCP 80, dashboard, API, signal और relay traffic के लिए 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 में यह एक अलग control होता है, और यही कारण है कि जिस box का अपना 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 side पर आपको Compose v2 plugin के साथ Docker की आवश्यकता है, साथ ही jq और curl भी चाहिए। Script इन सभी की जाँच करती है और यदि कोई एक भी missing हो तो रुक जाती है। यदि इस box पर Docker नया है, तो पहले VPS पर Docker Compose को काम करने योग्य बनाएँ।

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

दस्तावेजीकृत one-liner सबसे नए release को सीधे 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

स्क्रिप्ट सबसे पहले domain के लिए पूछती है:

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 ईमेल पते के लिए पूछता है, जिसका उपयोग समाप्ति सूचनाओं (expiry notices) के लिए किया जाता है।

पहले इंस्टॉलेशन पर NetBird Proxy सर्विस के लिए मना कर दें। इसे दो और DNS रिकॉर्ड्स की आवश्यकता होती है, proxy.netbird.example.com और wildcard *.proxy.netbird.example.com, और यह एक साधारण मेश (plain mesh) के लिए कुछ नहीं करता है। CrowdSec के लिए भी मना कर दें। दोनों को बाद में जोड़ा जा सकता है।

स्क्रिप्ट वर्तमान डायरेक्टरी में लिखती है: docker-compose.yml, 600 मोड के साथ config.yaml, dashboard.env, और जब आप बंडल किए गए Traefik को चुनते हैं तो traefik-dynamic.yaml। उस डायरेक्टरी को ऐसी स्थिति (state) के रूप में मानें जिसे आप सुरक्षित रखते हैं, क्योंकि config.yaml में वह key होती है जो स्टोर में डेटा को एन्क्रिप्ट करती है। इसे खो देना ऐसी समस्या नहीं है जिसे रीइंस्टॉल करने से ठीक किया जा सके।

docker compose ps
docker compose logs -f netbird-server

प्रत्येक सर्विस को running पढ़ना चाहिए, और सर्वर लॉग को लूप में रीस्टार्ट होने के बजाय स्थिर हो जाना चाहिए। सर्टिफिकेट को अलग से मॉनिटर करें:

docker compose logs traefik | grep -i acme

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

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

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) तरीके से जोड़ना

जिस मशीन पर ब्राउज़र नहीं है और जिसे कोई संचालित नहीं कर रहा है, उस पर ब्राउज़र लॉगिन काम नहीं करता है। एक सेटअप की (setup key) एक प्री-ऑथेंटिकेशन टोकन है जो इंटरैक्टिव चरण के बिना मशीन को रजिस्टर करता है। इसे डैशबोर्ड में Setup Keys के अंतर्गत बनाएँ।

ये दो प्रकार की होती हैं। एक वन-ऑफ (one-off) की ठीक एक मशीन को प्रमाणित करती है और उसके बाद समाप्त हो जाती है। एक रियूजेबल (reusable) की कई मशीनों को रजिस्टर करती है, जिसमें कितनी मशीनों को जोड़ना है, इसकी सीमा तय की जा सकती है। दोनों की एक समाप्ति अवधि (expiry) होती है, और दोनों नए पीयर (peer) को स्वचालित रूप से एक ग्रुप में असाइन कर सकती हैं, ताकि मशीन के जुड़ते ही उस ग्रुप पर लागू एक्सेस नियम उस पर भी प्रभावी हो जाएँ।

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

--hostname डैशबोर्ड में दिखाई देने वाले नाम को सेट करता है। इसके बिना, पीयर वही नाम ले लेता है जो मशीन का अपना नाम है, और ubuntu नाम वाली कई प्रविष्टियों से किसी को कोई मदद नहीं मिलती।

कंटेनर और कम समय तक चलने वाले बिल्ड एजेंटों के लिए, की (key) बनाते समय उसे ephemeral के रूप में चिह्नित करें। ephemeral की के साथ रजिस्टर किए गए पीयर 10 मिनट से अधिक समय तक ऑफलाइन रहने पर स्वचालित रूप से हटा दिए जाते हैं, जिससे पीयर सूची में मृत प्रविष्टियाँ नहीं रहतीं।

सेटअप की के आधार पर योजना बनाने से पहले एक सीमा को समझना आवश्यक है: की को एक्सपायर या डिलीट करने से नए रजिस्ट्रेशन रुक जाते हैं, लेकिन यह उन मशीनों को डिस्कनेक्ट नहीं करता है जो पहले ही इसके साथ रजिस्टर हो चुकी हैं। किसी मशीन का एक्सेस हटाने का अर्थ उस पीयर को हटाना है।

क्या आपको अभी भी एक अलग 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 को फिर से लागू करता है, और आप आधिकारिक Tailscale clients का उपयोग करना जारी रखते हैं। इसमें कोई आधिकारिक web console नहीं है। आप headscale command का उपयोग करके एक config file के माध्यम से users और pre-authentication keys को manage करते हैं। सामुदायिक 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 और असीमित devices के भीतर आता है, उसे hosted control plane के लिए कुछ भी भुगतान नहीं करना पड़ता है और हो सकता है कि उसे इसे चलाने की कोई आवश्यकता न हो। उस सीमा के बाद, बिल मशीनों की संख्या के बजाय लोगों की संख्या के साथ बढ़ता है, इसलिए Tailscale आपके समूह से कितना शुल्क लेगा, इसका हिसाब लगाना आपको एक ऐसी राशि देगा जिसकी तुलना आप VPS और इस stack पर खर्च होने वाले समय से कर सकते हैं।

इसे चलाने के लिए न्यूनतम VPS कितना छोटा हो सकता है?

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

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

Relay वह एकमात्र घटक है जिसे आप हटा नहीं सकते। दो 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 और मुख्य सर्वर पर समान होना अनिवार्य है, अन्यथा clients उस पर authenticate होने में विफल हो जाएंगे।

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

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

Client कहता है कि वह connect हो गया है, लेकिन डैशबोर्ड खाली है। Client ने NetBird की hosted service के साथ register किया है, क्योंकि --management-url गायब था। netbird status --detail चलाएँ और Management: line को पढ़ें, जो उस server का नाम बताती है जिससे वह वास्तव में बात कर रहा है। 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 firewall और provider firewall पर UDP 3478 की जाँच करें, क्योंकि STUN ही वह माध्यम है जिससे peer को अपना public address और port पता चलता है। netbird status --detail प्रत्येक peer के लिए Direct: false और ICE (interactive connectivity establishment) candidate types भी print करता है, जिससे पता चलता है कि प्रयास कहाँ तक पहुँचा। कुछ networks पर relayed ही एकमात्र परिणाम होता है और इसमें कुछ भी गलत नहीं है।

एक peer जुड़ता है लेकिन किसी भी चीज़ तक नहीं पहुँच पाता। Mesh में होने का मतलब यह नहीं है कि दो peers आपस में बात कर सकते हैं। Access policies यह तय करती हैं, और जिस group के साथ कोई policy नहीं जुड़ी होती, वह कहीं नहीं पहुँच सकता। 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 और firewall state को एक 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 जोड़ते हैं। एक external 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 ने आपके server के बजाय NetBird की hosted service के साथ register किया है, जो तब होता है जब --management-url को छोड़ दिया जाता है। netbird status --detail उस server को 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 को आपके द्वारा चलाए जाने वाले 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 server को किस size के VPS की आवश्यकता है?

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