SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-13

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

तुमच्या स्वतःच्या VPS वर NetBird मेश VPN सेटअप करण्याची संपूर्ण प्रक्रिया जाणून घ्या. यामध्ये DNS आणि TLS कॉन्फिगरेशन, सेटअप कीज आणि Headscale सोबतची तुलना सविस्तर दिली आहे.

NetBird VPN सर्व्हर स्वतः होस्ट करण्याचे फायदे

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

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

जर तुम्हाला फक्त असा एक सर्व्हर हवा असेल ज्यातून तुमचे सर्व ट्रॅफिक बाहेर पडेल, तर मेश ही गरजेशिवाय केलेली मोठी रचना ठरेल. A plain WireGuard VPN on a single VPS किंवा a Tailscale exit node हे काम खूप कमी कष्टात करते.

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

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

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

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

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

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

सार्वजनिक डोमेन नेम असणे अनिवार्य आहे. डॅशबोर्ड, 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 कार्यान्वित करा.

जर तुम्ही बंडल केलेला रिव्हर्स प्रॉक्सी वगळला तर लागणारे पोर्ट्स

Traefik शिवाय चालवल्यास, वैयक्तिक सेवा थेट उघडल्या जातात आणि पोर्टची यादी वाढते:

  • TCP 80, HTTP रिडायरेक्ट्स
  • TCP 443, HTTPS
  • TCP 33073, मॅनेजमेंट gRPC
  • TCP 10000, सिग्नल gRPC
  • TCP 33080, WebSocket किंवा QUIC द्वारे रिले
  • UDP 3478, STUN

हा पर्याय तेव्हाच निवडा जेव्हा सर्व्हरवर आधीच दुसऱ्या कशासाठी तरी TLS टर्मिनेशन होत असेल. अन्यथा, बंडल केलेला Traefik वापरणे अधिक सोपे आहे, कारण त्यात कमी नियम लागतात आणि चुका होण्याची शक्यता कमी असते.

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

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

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

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

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

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 शी संवाद साधतो आणि चुकीच्या सर्टिफिकेटमुळे विविध गोंधळात टाकणाऱ्या त्रुटी येऊ शकतात.

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

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

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 हा कमांड लाईन क्लायंट आणि डेमन (daemon) आहे. 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) वापरून विना-हस्तक्षेप (unattended) जोडा

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

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

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

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

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

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

जर तुम्ही आधीच Tailscale क्लायंटमध्ये गुंतवणूक केली असेल किंवा तुम्हाला शक्य तितका लहान कंट्रोल प्लेन हवा असेल, तर Headscale वापरा. जर अनेक लोकांना पीअर्सचे (peers) व्यवस्थापन करायचे असेल आणि तुम्हाला कन्सोल व SSO हवे असेल, तर NetBird वापरा.

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

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

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

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

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

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

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

एक पीअर जॉईन होतो पण कशाशीही संपर्क साधू शकत नाही. मेशमध्ये असणे म्हणजे दोन पीअर्स एकमेकांशी बोलू शकतातच असे नाही. ॲक्सेस पॉलिसी (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 असे टॅग असलेल्या कोणत्याही गोष्टीला एका विशिष्ट व्हर्जनवर पिन (pin) केले पाहिजे; याचे कारण तेच आहे ज्यासाठी तुम्ही इन्स्टॉल स्क्रिप्ट पिन केली होती: तुम्हाला काय चालले आहे हे माहित असावे आणि अपग्रेडमध्ये काही बिघाड झाल्यास परत जाण्यासाठी एक व्हर्जन उपलब्ध असावे. क्लायंट्स ज्या पॅकेज मॅनेजरद्वारे इन्स्टॉल केले आहेत, त्याद्वारेच अपग्रेड होतात.

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

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

क्लायंटने तुमच्या सर्व्हरऐवजी NetBird च्या होस्टेड सेवेकडे नोंदणी केली आहे. जेव्हा --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 पेक्षा वेगळे कसे आहे?

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

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

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