NetBird VPN सर्व्हर स्वतःच्या VPS वर कसा सेट करावा

NetBird VPN सर्व्हर स्वतः होस्ट केल्याने काय मिळते

NetBird VPN सर्व्हर स्वतः होस्ट केल्यामुळे कंट्रोल प्लेन तुमच्या मालकीच्या VPS वर राहते. यामध्ये पीअरची यादी (peer list) असते, कोणते मशीन कोणाशी संपर्क साधू शकते हे ठरवले जाते आणि NAT (network address translation) च्या मागे असलेल्या दोन पीअर्सना एकमेकांना शोधण्यास मदत केली जाते. टनेल स्वतः WireGuard चे असतात आणि ते थेट तुमच्या मशीन्समध्ये एनक्रिप्ट केलेले असतात. बदल एवढाच होतो की, कोणतीही बाह्य कंपनी तुमच्या उपकरणांची यादी किंवा लॉगिन प्रक्रिया नियंत्रित करत नाही. यामुळे तुम्हाला नक्की काय मिळते हे समजून घेणे महत्त्वाचे आहे, कारण होस्ट केलेल्या कंट्रोल प्लेनकडेही तुमचा ट्रॅफिक एनक्रिप्ट करणाऱ्या की (keys) नसतात आणि जर कोऑर्डिनेशन सर्व्हर कॉम्प्रमाइज झाला तर तो नक्की काय करू शकतो याची व्याप्ती बऱ्याच लोकांच्या कल्पनेपेक्षा कमी असते.

NetBird हे तुम्हाला कदाचित माहित असलेल्या दोन गोष्टींच्या मध्ये येते. हे एक मेश ओव्हरले (mesh overlay) आहे, त्यामुळे सर्व ट्रॅफिक एका गेटवेवरून पाठवण्याऐवजी पीअर्स एकमेकांशी थेट जोडले जातात. हे पूर्णपणे स्वतः होस्ट करता येते, ज्यामुळे याची तुलना Headscale, जो एक self-hosted Tailscale कंट्रोल सर्व्हर आहे याच्याशी केली जाते. जर तुम्ही आतापर्यंत फक्त सिंगल-गेटवे टनेल वापरले असेल, तर आधी plain WireGuard आणि मेश ओव्हरले मधील फरक वाचा, कारण तो दृष्टिकोन समजल्याशिवाय या पानावरील पुढील माहिती उपयुक्त ठरणार नाही.

जर तुम्हाला फक्त असा एक सर्व्हर हवा असेल ज्यातून तुमचा सर्व ट्रॅफिक बाहेर पडेल, तर मेश ही गरजेपेक्षा जास्त क्लिष्ट रचना आहे. एका VPS वर plain WireGuard VPN किंवा Tailscale exit node हे काम खूप कमी कष्टात करते. आणि जर तुमचे ध्येय मशीन्सना एकमेकांशी जोडण्याऐवजी फक्त एका खाजगी नेटवर्कपर्यंत पोहोचणे असेल, तर VPS वरील Tailscale subnet router खालील कोणतीही क्लिष्ट रचना न वापरता ती रेंज तुमच्या विद्यमान tailnet मध्ये समाविष्ट करतो.

स्टॅक प्रत्यक्षात काय चालवतो

याची रचना अलीकडेच बदलली आहे आणि बहुतेक जुन्या लेखांमध्ये जुन्या रचनेचे वर्णन आहे. ऑगस्ट 2026 पर्यंत, v0.76.2 या रिलीजमध्ये, quickstart स्क्रिप्ट डीफॉल्टनुसार तीन सर्व्हिसेस असलेली एक Compose फाईल तयार करते.

• netbird-server मध्ये management API, signal service, एम्बेडेड STUN listener असलेला relay आणि एक एम्बेडेड identity provider असतो. जुन्या रिलीजमध्ये हे स्वतंत्र कंटेनर होते आणि identity provider हे एक वेगळे Zitadel इन्स्टॉल होते जे तुम्हाला आधी बिल्ड करावे लागत असे.
• dashboard हे ॲडमिन वेब कन्सोल आहे.
• traefik हे TLS (transport layer security) टर्मिनेट करते आणि पहिल्यांदा सुरू झाल्यावर Let's Encrypt कडून प्रमाणपत्राची विनंती करते.

अजून दोन सर्व्हिसेस अस्तित्वात आहेत आणि जोपर्यंत तुम्ही प्रॉम्प्टवर होकार देत नाही तोपर्यंत त्या बंद राहतात. NetBird Proxy सर्व्हिस अंतर्गत सर्व्हिसेसना सार्वजनिक होस्टनेमवर प्रकाशित करते. CrowdSec हानिकारक ट्रॅफिक फिल्टर करते. कार्यक्षम मेश तयार करण्यासाठी यापैकी कशाचीही गरज नाही आणि दोन्हीमुळे लहान सर्व्हरवर मेमरीचा वापर वाढतो.

जर तुम्ही एकाच Docker कंटेनरमधील wg-easy वरून येत असाल, तर भागांच्या संख्येत झालेली ही वाढ मोठी आहे. या बदल्यात तुम्हाला ॲक्सेस पॉलिसीज, प्रति-वापरकर्ता खाती आणि एकमेकांशी थेट जोडले जाणारे पीअर्स मिळतात, जे एका गेटवेवरून जाण्याऐवजी थेट एकमेकांशी कनेक्ट होतात.

सुरुवात करण्यापूर्वी आवश्यक गोष्टी

सार्वजनिक डोमेन नेम असणे अनिवार्य आहे. डॅशबोर्ड, API आणि रिले हे सर्व पोर्ट 443 वर HTTPS वापरतात. Traefik हे Let's Encrypt कडून HTTP चॅलेंज वापरून प्रमाणपत्र मिळवते, ज्यासाठी सार्वजनिक इंटरनेटवरून तुमच्या VPS कडे निर्देशित होणारे डोमेन नेम आवश्यक असते. केवळ IP ॲड्रेस या प्रक्रियेत काम करणार नाही.

एक A record तयार करा, netbird.example.com जो तुमच्या VPS च्या सार्वजनिक IPv4 ॲड्रेसकडे निर्देशित असेल, आणि कोणतीही प्रक्रिया सुरू करण्यापूर्वी DNS प्रोपॅगेशन पूर्ण होण्याची वाट पहा.

dig +short netbird.example.com

या कमांडने तुमच्या सर्व्हरचा ॲड्रेस दिसला पाहिजे. DNS प्रोपॅगेट होण्यापूर्वी इंस्टॉलर चालवल्यास, पहिल्यांदाच प्रमाणपत्र मिळवण्याची विनंती अयशस्वी होईल. वारंवार अयशस्वी व्हॅलिडेशनमुळे Let's Encrypt चे रेट लिमिट लागू होते, ज्यामुळे तुम्हाला पुन्हा प्रयत्न करण्यासाठी एक तास थांबावे लागेल.

इंटरनेटवरून तीन पोर्ट्स उपलब्ध असणे आवश्यक आहे: प्रमाणपत्र चॅलेंज आणि HTTPS वर रिडायरेक्ट करण्यासाठी TCP 80, डॅशबोर्ड, API, सिग्नल आणि रिले ट्रॅफिकसाठी 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

तुमच्या प्रोव्हायडरच्या नेटवर्क फायरवॉलवरही हे पोर्ट्स उघडा. बहुतेक VPS पॅनेलमध्ये हे एक स्वतंत्र नियंत्रण असते आणि अनेकदा सर्व्हरचे स्वतःचे ufw status बरोबर असूनही कनेक्शन नाकारले जाण्याचे हेच मुख्य कारण असते.

STUN (session traversal utilities for NAT) द्वारे पीअरला स्वतःच्या NAT ने नियुक्त केलेला सार्वजनिक ॲड्रेस आणि पोर्ट समजते, जेणेकरून दोन पीअर्स थेट टनेल तयार करण्याचा प्रयत्न करू शकतील. जर UDP 3478 ब्लॉक असेल, तर पीअर्स तरीही TCP 443 वरील रिलेद्वारे कनेक्ट होतात, त्यामुळे काहीही बिघडल्यासारखे वाटत नाही. मात्र, त्याऐवजी तुम्हाला प्रत्येक पीअरवर Connection type: Relayed दिसेल आणि सर्व ट्रॅफिक पीअर-टू-पीअर जाण्याऐवजी तुमच्या VPS मधून जाईल.

सॉफ्टवेअरच्या बाजूने तुम्हाला Docker सोबत Compose v2 प्लगइन, तसेच jq आणि curl ची आवश्यकता आहे. स्क्रिप्ट या सर्वांची तपासणी करते आणि एखादी गोष्ट गहाळ असल्यास थांबते. जर या सर्व्हरवर Docker नवीन असेल, तर आधी VPS वर Docker Compose कार्यान्वित करा.

Quickstart स्क्रिप्ट वापरून NetBird सर्व्हर इन्स्टॉल करा

दस्तऐवजीकरण केलेली one-liner कमांड थेट सर्वात नवीन release ला शेलमध्ये पाईप करते:

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

त्याऐवजी, विशिष्ट व्हर्जन पिन करा. latest मध्ये बदल होत असतात, त्यामुळे दोन आठवड्यांच्या अंतराने तीच कमांड चालवल्यास दोन भिन्न इन्स्टॉलेशन्स मिळतात आणि तुमच्या कॉन्फिगरेशनमध्ये नेमके कोणते व्हर्जन वापरले आहे याची नोंद डिस्कवर राहत नाही. त्याऐवजी टॅग केलेले 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 एक कॉन्फिगरेशन स्निपेट लिहितात आणि जोडणीची जबाबदारी तुमच्यावर सोडतात. जर सर्व्हरवर आधीच प्रॉक्सी चालू असेल तर हे योग्य आहे, परंतु नवीन सर्व्हरसाठी हे चुकीचे आहे. पर्याय 0 निवडल्यास, एक्सपायरी नोटिसेससाठी Let's Encrypt ईमेल ॲड्रेस विचारला जातो.

पहिल्या इन्स्टॉलेशनच्या वेळी NetBird Proxy सेवेसाठी 'no' निवडा. यासाठी दोन अतिरिक्त DNS रेकॉर्ड्स, proxy.netbird.example.com आणि वाइल्डकार्ड *.proxy.netbird.example.com ची आवश्यकता असते आणि साध्या मेश (mesh) साठी याचा काहीही उपयोग होत नाही. CrowdSec साठी सुद्धा 'no' निवडा. या दोन्ही गोष्टी नंतर कधीही जोडता येतात.

ही स्क्रिप्ट सध्याच्या डिरेक्टरीमध्ये फाईल्स लिहिते: 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 वाचले पाहिजे आणि सर्व्हर लॉग लूपमध्ये रीस्टार्ट होण्याऐवजी स्थिर झाला पाहिजे. प्रमाणपत्रावर (certificate) स्वतंत्रपणे लक्ष ठेवा:

docker compose logs traefik | grep -i acme

ACME (automatic certificate management environment) हा Traefik द्वारे प्रमाणपत्र मिळवण्यासाठी वापरला जाणारा प्रोटोकॉल आहे. यामध्ये येणाऱ्या त्रुटींचे कारण बहुतेक वेळा DNS किंवा बंद असलेले पोर्ट 80 हेच असते.

पहिले ॲडमिन खाते तयार करा

https://netbird.example.com उघडा. नवीन इन्स्टॉलेशनवर, लॉगिन फॉर्मऐवजी हे थेट सेटअप पेजवर जाते. एक ईमेल पत्ता, नाव आणि पासवर्ड प्रविष्ट करा, त्यानंतर Create Account वर क्लिक करा. हे पहिले ॲडमिन खाते बनते आणि पेज लॉगिन फॉर्मवर रिडायरेक्ट होते.

हे खाते NetBird च्या स्वतःच्या युजर स्टोअरमध्ये असते, जे netbird-server कंटेनरमध्ये एम्बेड केलेल्या आयडेंटिटी प्रोव्हायडरद्वारे चालते. यामध्ये बाह्य कशाचाही समावेश नसतो. एका वर्षापूर्वीच्या सेल्फ-होस्टेड NetBird च्या तुलनेत हा सर्वात मोठा बदल आहे; तेव्हा काम करणारी इन्स्टॉलेशन मिळवण्यासाठी आधी Zitadel किंवा Keycloak उभे करावे लागत असे आणि कोणतीही गोष्ट सुरू होण्यापूर्वी चार OIDC (OpenID Connect) व्हॅल्यूज setup.env मध्ये कॉपी कराव्या लागत असत.

जर तुम्हाला सेटअप पेजऐवजी ब्राउझर सर्टिफिकेट वॉर्निंग दिसत असेल, तर सर्टिफिकेट इश्यू झालेले नाही. पुढे जाण्यापूर्वी ते दुरुस्त करा, कारण डॅशबोर्ड त्याच होस्टनेमद्वारे API शी संवाद साधतो आणि चुकीच्या सर्टिफिकेटमुळे गोंधळात टाकणाऱ्या त्रुटी निर्माण होतात.

तुमचा पहिला पीअर जोडा

कोणत्याही Linux मशीनवर क्लायंट इंस्टॉल करा, जर तुम्हाला तो मेशमध्ये हवा असेल तर VPS वर देखील हे करता येईल:

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

Debian आणि Ubuntu वर, ती स्क्रिप्ट NetBird ची पॅकेज रिपॉझिटरी कॉन्फिगर करते आणि त्यानंतर apt द्वारे क्लायंट इंस्टॉल करते, त्यामुळे पॅकेज मॅनेजरकडे त्याचे नियंत्रण राहते. जर तुम्हाला स्क्रिप्ट थेट शेलमध्ये पाइप करणे सुरक्षित वाटत नसेल, तर ती आधी curl -fsSL -o install.sh https://pkgs.netbird.io/install.sh वापरून सेव्ह करा आणि sh install.sh चालवण्यापूर्वी ती वाचून घ्या. दोन्ही प्रकारे, काय इंस्टॉल झाले आहे ते तपासा:

apt-cache policy netbird

netbird हा कमांड लाइन क्लायंट आणि डेमन आहे. netbird-ui हे डेस्कटॉप ट्रे ॲप आहे, आणि हेडलेस सर्व्हरसाठी त्याचा काहीही उपयोग नाही.

आता क्लायंटला तुमच्या सर्व्हरकडे निर्देशित करा:

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

--management-url वगळल्यास क्लायंट NetBird च्या होस्टेड सर्व्हिससह रजिस्टर होतो, कारण ते डीफॉल्ट सेटिंग आहे. कमांड यशस्वी होते, मशीनला पत्ता मिळतो, परंतु तुमचा सेल्फ-होस्टेड डॅशबोर्ड रिकामा राहतो. ही चूक जवळजवळ प्रत्येकाकडून एकदा तरी होते.

लॉगिन पूर्ण करण्यासाठी कमांड एक URL प्रिंट करते, ती ब्राउझरमध्ये उघडा. त्यानंतर:

netbird status
ip addr show wt0

netbird status मधून चार ओळी वाचा: Management: Connected, Signal: Connected, प्रत्येक उपलब्ध रिलेची माहिती देणारी Relays: ओळ, आणि ओव्हरले रेंजमधील एक NetBird IP:. wt0 हा NetBird द्वारे तयार केलेला WireGuard इंटरफेस आहे आणि त्यावर तोच पत्ता असणे आवश्यक आहे.

दुसरे मशीन अनअटेंडेड पद्धतीने सेटअप की (setup key) वापरून जोडा

ज्या मशीनवर ब्राउझर नाही आणि समोर कोणीही उपलब्ध नाही, अशा ठिकाणी ब्राउझर-आधारित लॉगिन काम करत नाही. सेटअप की (setup key) हे एक प्री-ऑथेंटिकेशन टोकन आहे, जे इंटरअॅक्टिव्ह पायरीशिवाय मशीनची नोंदणी करते. डॅशबोर्डवरील Setup Keys विभागात तुम्ही अशी की तयार करू शकता.

याचे दोन प्रकार आहेत. 'वन-ऑफ' (one-off) की फक्त एकाच मशीनला ऑथेंटिकेट करते आणि त्यानंतर ती वापरली जाते (spent). 'रीयुझेबल' (reusable) की अनेक मशीनची नोंदणी करू शकते, ज्यावर तुम्ही आवश्यक असल्यास मर्यादेची अट घालू शकता. दोन्ही प्रकारच्या की साठी एक्सपायरी सेट करता येते आणि दोन्ही नवीन पीअरला (peer) आपोआप एका ग्रुपमध्ये समाविष्ट करू शकतात, जेणेकरून मशीन दिसताच त्यावर त्या ग्रुपचे ॲक्सेस नियम लागू होतील.

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

--hostname डॅशबोर्डवर दिसणारे नाव सेट करते. याशिवाय, मशीन स्वतःला जे नाव देते तेच नाव पीअरला मिळते आणि जर सर्व मशीनची नावे ubuntu अशी असतील, तर ते गोंधळात टाकणारे ठरते.

कंटेनर आणि अल्पकाळ टिकणाऱ्या बिल्ड एजंट्ससाठी, की तयार करताना तिला 'इफेमेरल' (ephemeral) म्हणून मार्क करा. इफेमेरल की वापरून नोंदणी केलेले पीअर्स 10 मिनिटांपेक्षा जास्त काळ ऑफलाइन राहिल्यास आपोआप काढून टाकले जातात, ज्यामुळे पीअर लिस्टमध्ये मृत नोंदी राहत नाहीत.

सेटअप की वापरण्यापूर्वी एक मर्यादा समजून घेणे आवश्यक आहे: की एक्सपायर करणे किंवा डिलीट करणे यामुळे नवीन नोंदणी थांबते, परंतु ज्या मशीनची नोंदणी आधीच झाली आहे, त्यांचे कनेक्शन तुटत नाही. मशीनचा ॲक्सेस काढून टाकण्यासाठी तो पीअर काढून टाकणे आवश्यक आहे.

तुम्हाला अजूनही स्वतंत्र identity provider ची गरज आहे का?

लहान इन्स्टॉलेशनसाठी, नाही. डॅशबोर्डवरून तयार केलेली खाती हाताळण्यासाठी इन-बिल्ट user store पुरेसा आहे आणि काही मोजक्या लोकांसाठी हे पुरेसे ठरते.

जेव्हा तुमच्याकडे आधीच एक identity provider असतो आणि तुम्हाला वापरकर्त्यांची दुसरी यादी तयार करायची नसते, तेव्हा तुम्हाला बाह्य identity 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 साठी तयार इंटिग्रेशन्स उपलब्ध आहेत, तर इतर कोणत्याही provider साठी तुम्ही generic OIDC चा वापर करू शकता. जर तुम्ही आधीच Authentik चा वापर self-hosted single sign-on म्हणून करत असाल, तर हा मार्ग वापरून तुम्ही दोन ऐवजी एकाच खात्यांची यादी ठेवू शकता.

provider जोडल्यानंतरही local login सुविधा उपलब्ध राहते आणि कॉन्फिगर केलेले सर्व providers लॉगिन पेजवर दिसतात. एक local admin खाते मजबूत पासवर्डसह नेहमी ठेवा. यामुळे OIDC कॉन्फिगरेशनमध्ये काही बिघाड झाल्यास, तुमच्याकडे सिस्टिममध्ये प्रवेश करण्याचा एक मार्ग शिल्लक राहतो.

NetBird की Headscale: तुम्ही कोणता कंट्रोल प्लेन चालवावा?

दोन्ही पर्याय एकच अवलंबित्व (dependency) काढून टाकतात, ते म्हणजे होस्ट केलेला कंट्रोल सर्व्हर, ज्याच्याशी तुमचे क्लायंट अन्यथा संपर्क साधत असतात. हे दोन्ही प्रकल्प एकाच स्वरूपाचे नाहीत.

Headscale हे Tailscale कंट्रोल सर्व्हरची पुनर्रचना करते आणि तुम्ही अधिकृत Tailscale क्लायंट वापरणे सुरू ठेवता. यामध्ये कोणतीही अधिकृत वेब कन्सोल नाही. तुम्ही वापरकर्ते आणि प्री-ऑथेंटिकेशन की (pre-authentication keys) यांचे व्यवस्थापन कॉन्फिगरेशन फाईलच्या संदर्भात headscale कमांड वापरून करता. समुदायाने विकसित केलेले वेब इंटरफेस उपलब्ध आहेत, परंतु ते या प्रकल्पाचा भाग नाहीत. ज्यांना आपली स्थिती (state) फाईल्समध्ये आणि बदल व्हर्जन कंट्रोलमध्ये ठेवायचे आहेत, त्यांच्यासाठी हे योग्य आहे.

NetBird संपूर्ण उत्पादन देते: स्वतःचा क्लायंट, स्वतःचा डॅशबोर्ड, एक एम्बेडेड आयडेंटिटी प्रोव्हायडर आणि ब्राउझरमध्ये संपादित करता येणारी ॲक्सेस पॉलिसी. तुमच्या VPS वर हे अधिक घटक (moving parts) आहेत, परंतु ज्या सहकाऱ्याला टर्मिनल उघडायचे नाही, त्याला हे सोपवणे खूप सोपे आहे.

जर तुम्ही आधीच Tailscale क्लायंटमध्ये गुंतवणूक केली असेल किंवा तुम्हाला शक्य तितका लहान कंट्रोल प्लेन हवा असेल, तर Headscale वापरा. जर अनेक लोकांना पीअर्सचे (peers) व्यवस्थापन करायचे असेल आणि तुम्हाला कन्सोल व SSO हवे असेल, तर NetBird वापरा. यापैकी कोणताही पर्याय निवडण्यापूर्वी, Tailscale चा मोफत प्लॅन नक्की काय कव्हर करतो हे तपासा, कारण सहा वापरकर्ते आणि अमर्यादित उपकरणांच्या मर्यादेत बसणाऱ्या गटाला होस्ट केलेल्या कंट्रोल प्लेनसाठी काहीही पैसे द्यावे लागत नाहीत आणि कदाचित तो चालवण्याचे कोणतेही कारण नसेल. या मर्यादेच्या पलीकडे, बिल मशीनच्या संख्येपेक्षा लोकांच्या संख्येनुसार वाढते, त्यामुळे Tailscale तुमच्या गटाकडून किती शुल्क आकारेल हे काढल्यास तुम्हाला VPS आणि या स्टॅकसाठी लागणारा वेळ यांच्या तुलनेत एक निश्चित आकडा मिळेल.

हे चालवण्यासाठी किती लहान VPS पुरेसा आहे?

दस्तऐवजीकरणानुसार किमान 1 CPU आणि 2 GB मेमरी आवश्यक आहे. NetBird च्या स्वतःच्या नोंदींनुसार, आता युजर मॅनेजमेंट स्थानिक पातळीवर असल्याने, सध्याची किमान गरज 1 GB RAM च्या जवळ आली आहे. जुन्या रचनेत Zitadel चे पूर्ण डिप्लॉयमेंट समाविष्ट असल्याने 2 GB ते 4 GB ची गरज भासत असे. 2 GB चा पर्याय निवडा. अतिरिक्त मेमरीमुळे अपग्रेड करताना जुन्या इमेजेस डिस्कवर असतानाच नवीन इमेजेस डाऊनलोड करणे शक्य होते.

लहान सर्व्हरवर तीन गोष्टी वगळणे सुरक्षित आहे. NetBird Proxy सेवा नाकारा; ही सेवा अंतर्गत सेवांना सार्वजनिक होस्टनेमवर प्रकाशित करण्यासाठी असते आणि पीअर्सच्या (peers) जोडणीशी तिचा काहीही संबंध नाही. CrowdSec नाकारा; हे सुरुवातीच्या पहिल्या दिवशी लावण्यापेक्षा, सर्व्हर सार्वजनिकरीत्या उघड झाल्यावर नंतर जोडणे अधिक योग्य ठरेल. डीफॉल्ट SQLite स्टोअर netbird_data व्हॉल्यूममध्येच ठेवा आणि जेव्हा तुम्ही डिप्लॉयमेंट वेगवेगळ्या मशीनवर विभागता किंवा खऱ्या अर्थाने एकाच वेळी अनेक विनंत्या (concurrency) हाताळता, तेव्हाच PostgreSQL कडे वळा. हे नंतर करता येण्यासारखे मायग्रेशन म्हणून दस्तऐवजीकरण केलेले आहे.

रिले (relay) हा असा घटक आहे जो तुम्ही वगळू शकत नाही. ज्या दोन पीअर्सचे NAT प्रत्येक डेस्टिनेशनसाठी वेगळा पोर्ट नियुक्त करते, ते कधीही थेट टनेल (direct tunnel) प्रस्थापित करू शकत नाहीत. त्यामुळे रिले हाच एकमेव मार्ग आहे ज्यामुळे ते काम करू शकतात. रिले बंद केल्याने मेमरीची फारशी बचत होत नाही, परंतु त्यामुळे कनेक्शन अशा प्रकारे खंडित होते की ज्याचा शोध घेणे कठीण असते.

जेव्हा एक सर्व्हर अपुरा पडू लागतो, तेव्हा रिले हा सर्वात आधी हलवण्याचा घटक असतो. एक स्वतंत्र रिले NB_LISTEN_ADDRESS, NB_EXPOSED_ADDRESS, NB_AUTH_SECRET आणि NB_ENABLE_STUN सह चालतो. रिले आणि मुख्य सर्व्हरवर शेअर केलेले सिक्रेट (shared secret) एकसारखेच असणे आवश्यक आहे, अन्यथा क्लायंट्सना ऑथेंटिकेट करण्यात अपयश येईल.

अपयशाचे प्रकार आणि तुम्हाला दिसणारी लक्षणे

डॅशबोर्डवर प्रमाणपत्राबाबत (certificate) चेतावणी दिसते. Traefik ने प्रमाणपत्र मिळवलेले नाही. docker compose logs traefik | grep -i acme चालवा. याची दोन मुख्य कारणे असू शकतात. एकतर dig +short netbird.example.com अजून या VPS कडे पॉइंट करत नाही, किंवा Let's Encrypt आणि कंटेनरच्या दरम्यान TCP 80 पोर्ट बंद आहे. हे सहसा प्रोव्हायडरच्या नेटवर्क फायरवॉलवर असते, ufw वर नाही. पुन्हा पुन्हा प्रयत्न करण्यापूर्वी मूळ कारण दुरुस्त करा, कारण अयशस्वी पडताळणीवर (failed validations) दर मर्यादा (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 दर्शवतो. कोणतेही थेट टनेल (direct tunnels) तयार होत नाहीत, त्यामुळे सर्व ट्रॅफिक तुमच्या VPS मधून जाते आणि लॅटन्सी (latency) वाढते. VPS फायरवॉल आणि प्रोव्हायडर फायरवॉलवर UDP 3478 तपासा, कारण STUN मुळेच पीअरला स्वतःचा सार्वजनिक पत्ता आणि पोर्ट समजते. netbird status --detail कमांड प्रत्येक पीअरसाठी Direct: false आणि ICE (interactive connectivity establishment) कॅंडिडेट प्रकार देखील प्रिंट करते, ज्यावरून प्रयत्न किती यशस्वी झाला हे समजते. काही नेटवर्कवर 'relayed' हाच एकमेव पर्याय उपलब्ध असतो आणि त्यात काहीही चूक नसते.

एक पीअर जॉईन होतो पण कशाशीही संपर्क साधू शकत नाही. मेशमध्ये (mesh) असणे म्हणजे दोन पीअर्स एकमेकांशी बोलू शकतात असा अर्थ होत नाही. ॲक्सेस पॉलिसीज (access policies) हे ठरवतात आणि ज्या ग्रुपला कोणतीही पॉलिसी जोडलेली नाही, तो कशाशीही संपर्क साधू शकत नाही. राउट्स आणि फायरवॉल तपासण्यापूर्वी डॅशबोर्डमधील पॉलिसी तपासा.

netbird status डेमन (daemon) समस्येचा अहवाल देते. सेवा सुरू नाही. sudo netbird service status आणि sudo netbird service start वापरा. क्लायंटचे लॉग्स /var/log/netbird/client.log वर असतात. तुम्हाला जी गोष्ट सापडत नाही, त्यासाठी netbird debug bundle --anonymize --system-info लॉग्स, स्टेटस, राउट्स, DNS सेटिंग्ज आणि फायरवॉलची स्थिती एका आर्काइव्हमध्ये गोळा करते.

बॅकअप आणि अपग्रेड्स

संपूर्ण इन्स्टॉल दोन गोष्टींवर अवलंबून असते: docker-compose.yml आणि config.yaml असलेली डिरेक्टरी, आणि डेटाबेस व एन्क्रिप्शन कीज असलेला 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 व्हॉल्यूमच्या नावांना प्रोजेक्ट डिरेक्टरीचे प्रीफिक्स जोडते, त्यामुळे netbird_data म्हणून नमूद केलेला व्हॉल्यूम सहसा netbird_netbird_data या नावाने दिसतो. आधी docker volume ls चालवा आणि ते जे नाव दाखवेल त्याचा वापर करा, अन्यथा वरील docker run कमांड अयशस्वी होईल आणि ती रिकामी व्हॉल्यूम तयार करून काहीही आर्काइव्ह करणार नाही. आर्काइव्ह्ज VPS वर ठेवू नका. जर तुमच्याकडे आधीच बॅकअप टूल असेल, तर restic किंवा BorgBackup ऑफसाइट बॅकअपची सोय पाहू शकतात.

सर्व्हर अपग्रेड करणे म्हणजे इमेज पुल करणे आणि कंटेनर पुन्हा तयार करणे:

docker compose pull
docker compose up -d
docker compose ps

त्यावर अवलंबून राहण्यापूर्वी, docker compose config | grep image: चालवा. latest असे वाचले जाणारे कोणतेही टॅग एका विशिष्ट व्हर्जनवर पिन केलेले असावेत. इन्स्टॉल स्क्रिप्ट पिन करण्यामागचे जे कारण आहे, तेच इथेही लागू होते: तुम्हाला काय रन होत आहे हे माहित असावे आणि अपग्रेडमध्ये काही बिघाड झाल्यास परत जाण्यासाठी एक व्हर्जन उपलब्ध असावे. क्लायंट्स ज्या पॅकेज मॅनेजरद्वारे इन्स्टॉल केले आहेत, त्याद्वारेच अपग्रेड होतात.

FAQ

NetBird self-host करण्यासाठी मला स्वतःच्या identity provider ची गरज आहे का?

नाही. सध्याच्या releases मध्ये इन-बिल्ट user store समाविष्ट आहे. त्यामुळे तुम्ही ब्राउझरमध्ये https://netbird.example.com वर पहिले admin खाते तयार करू शकता आणि त्यानंतर डॅशबोर्डवरून इतर वापरकर्त्यांना जोडू शकता. बाह्य OIDC provider ऐच्छिक आहे आणि तो नंतर चार मूल्यांसह (name, client ID, client secret आणि issuer) जोडता येतो. NetBird पूर्वी Zitadel किंवा Keycloak तैनात करण्यास सांगणारी मार्गदर्शिका आता कालबाह्य झाली आहे; अशा सेटअपची आता गरज नाही आणि त्याचे पालन केल्यास तुम्हाला एक अतिरिक्त सेवा चालवावी लागेल.

माझे सर्व peers Connection type: Relayed असे का दर्शवत आहेत?

थेट कनेक्शन (direct connections) तयार होत नसल्यामुळे, ट्रॅफिक तुमच्या VPS वरील relay द्वारे जात आहे. याचे सामान्य कारण म्हणजे UDP 3478 पोर्ट ब्लॉक असणे. हे STUN पोर्ट आहे, ज्याचा वापर peers स्वतःचा सार्वजनिक पत्ता आणि पोर्ट शोधण्यासाठी करतात. ते तुमच्या VPS फायरवॉलवर आणि तुमच्या प्रोव्हायडरच्या नेटवर्क फायरवॉलवर उघडा. त्यानंतर पुन्हा netbird status --detail चालवा आणि Direct: ओळ वाचा. ज्या नेटवर्कवर NAT प्रत्येक destination साठी वेगळा पोर्ट नियुक्त करते, तिथे 'relayed' हाच एकमेव पर्याय असतो आणि त्यात कोणतीही चूक नसते.

माझा क्लायंट कनेक्ट झाला आहे, पण डॅशबोर्डवर एकही peer दिसत नाही. काय झाले?

क्लायंटने तुमच्या सर्व्हरऐवजी NetBird च्या hosted सेवेसोबत नोंदणी केली आहे. जेव्हा --management-url वगळले जाते तेव्हा असे घडते. netbird status --detail कमांड Management: ओळीवर तो कोणत्या सर्व्हरशी संवाद साधत आहे हे दर्शवते, त्यामुळे https://api.netbird.io:443 सारखे मूल्य असल्यास खात्री पटते. sudo netbird down चालवा, त्यानंतर sudo netbird up --management-url https://netbird.example.com करा, म्हणजे peer तुमच्या डॅशबोर्डवर दिसेल.

self-hosted NetBird हे Headscale पेक्षा वेगळे कसे आहे?

दोन्ही पर्याय hosted control server ला तुम्ही चालवत असलेल्या सर्व्हरने बदलतात. Headscale हे फक्त control plane आहे: तुम्ही ते headscale कमांड आणि कॉन्फिगरेशन फाईलद्वारे व्यवस्थापित करता, त्यात अधिकृत वेब कन्सोल नाही आणि ते अधिकृत Tailscale क्लायंट्स चालवते. NetBird चा स्वतःचा क्लायंट, admin डॅशबोर्ड आणि identity provider इंटिग्रेशन एकाच स्टॅकमध्ये उपलब्ध आहे. Headscale चालवण्यासाठी हलके आहे आणि त्याची स्थिती (state) फाईल्समध्ये ठेवते. ज्यांना टर्मिनल वापरणे कठीण वाटते, अशा लोकांसाठी NetBird वापरणे अधिक सोपे आहे.

self-hosted NetBird सर्व्हरसाठी किती आकाराचा VPS आवश्यक आहे?

दस्तऐवजीकरणानुसार किमान 1 CPU आणि 2 GB मेमरी आवश्यक आहे आणि 2 GB मेमरी घेणेच योग्य ठरेल. अलीकडील releases मध्ये identity provider आता वेगळ्या deployment ऐवजी एम्बेड केलेले असल्याने, प्रत्यक्ष गरज 1 GB पर्यंत खाली आली आहे. इन्स्टॉलेशन दरम्यान ऐच्छिक proxy आणि CrowdSec सेवा नाकारा आणि जोपर्यंत तुम्हाला खरोखर PostgreSQL ची गरज भासत नाही, तोपर्यंत डीफॉल्ट SQLite store वापरा.