VPS پر NetBird VPN server خود کیسے host کریں

خود NetBird VPN server کی میزبانی کرنے سے آپ کو کیا حاصل ہوتا ہے

خود NetBird VPN server کی میزبانی کرنے سے control plane آپ کے اپنے VPS پر آ جاتا ہے۔ یہی حصہ peers کی فہرست رکھتا ہے، طے کرتا ہے کہ کون سی machine کس machine تک پہنچ سکتی ہے، اور NAT (network address translation) کے پیچھے موجود دو peers کو ایک دوسرے کی تلاش میں مدد دیتا ہے۔ Tunnels پھر بھی WireGuard رہتے ہیں اور آپ کی machines کے درمیان براہ راست encrypted ہوتے ہیں۔ تبدیلی یہ آتی ہے کہ کوئی بیرونی کمپنی آپ کے devices کی inventory یا login flow اپنے پاس نہیں رکھتی۔

NetBird دو ایسے تصورات کے درمیان آتا ہے جن سے آپ پہلے ہی واقف ہو سکتے ہیں۔ یہ mesh overlay ہے، اس لیے peers ہر چیز ایک gateway کے ذریعے بھیجنے کے بجائے ایک دوسرے سے connect ہوتے ہیں۔ یہ end to end self-hostable بھی ہے، اس لیے اس کا موازنہ Headscale، self-hosted Tailscale control server سے کیا جا سکتا ہے۔ اگر آپ نے اب تک صرف single-gateway tunnel چلایا ہے تو پہلے plain WireGuard اور mesh overlay کا فرق پڑھیں، کیونکہ یہی ذہنی ماڈل اس صفحے کے باقی حصے کو سمجھنے میں مدد دیتا ہے۔

اگر آپ کا اصل مقصد ایسا server ہے جہاں سے آپ کا تمام traffic باہر نکلے، تو mesh اس کام کے لیے ضرورت سے زیادہ پیچیدہ ہے۔ single VPS پر plain WireGuard VPN یا Tailscale exit node یہ کام بہت کم انتظامی بوجھ کے ساتھ کر دیتا ہے۔

اس stack میں اصل میں کیا چل رہا ہے

یہ layout حال ہی میں تبدیل ہوا ہے، اور زیادہ تر پرانی تحریروں میں پرانا layout بیان کیا گیا ہے۔ August 2026 تک، release v0.76.2 میں quickstart script default طور پر تین services والی Compose file لکھتی ہے۔

• netbird-server management API، signal service، embedded STUN listener والا relay، اور embedded identity provider چلاتا ہے۔ پرانی releases میں یہ الگ containers تھے، جبکہ identity provider ایک الگ Zitadel installation تھا جسے آپ کو پہلے خود تیار کرنا پڑتا تھا۔
• dashboard admin web console ہے۔
• traefik TLS (transport layer security) terminate کرتا ہے اور پہلی بار start ہونے پر Let's Encrypt سے certificate طلب کرتا ہے۔

دو مزید services بھی موجود ہیں، لیکن prompt پر ہاں کہنے تک بند رہتی ہیں۔ NetBird Proxy service internal services کو public hostnames پر شائع کرتی ہے۔ CrowdSec نقصان دہ network traffic کو filter کرتا ہے۔ Working mesh بنانے کے لیے ان میں سے کوئی بھی ضروری نہیں ہے، اور چھوٹے server پر دونوں memory استعمال کرتے ہیں۔

اگر آپ ایک Docker container میں wg-easy سے آ رہے ہیں تو یہ components کی تعداد میں واضح اضافہ ہے۔ اس کے بدلے آپ کو access policies، ہر user کے لیے الگ accounts، اور ایسے peers ملتے ہیں جو ایک gateway کے ذریعے جانے کے بجائے براہ راست ایک دوسرے سے connect ہوتے ہیں۔

شروع کرنے سے پہلے ضروری چیزیں

public domain name اختیاری نہیں ہے۔ dashboard، API اور relay، تینوں HTTPS کے ذریعے port 443 پر چلتے ہیں، اور Traefik اپنا certificate Let's Encrypt سے HTTP challenge کے ذریعے حاصل کرتا ہے۔ اس کے لیے ایسا name ضروری ہے جو public internet سے اس VPS کی طرف resolve ہو۔ اس flow میں صرف IP address کام نہیں کرے گا۔

ایک A record بنائیں، netbird.example.com، اور اسے VPS کے public IPv4 address کی طرف point کریں۔ کسی بھی command کو چلانے سے پہلے DNS propagation کا انتظار کریں۔

dig +short netbird.example.com

اس command کو آپ کے server کا address دکھانا چاہیے۔ DNS propagate ہونے سے پہلے installer چلانے پر پہلے start کے دوران certificate request fail ہو جاتی ہے۔ بار بار ناکام validations ہونے پر Let's Encrypt rate limits لاگو کر دیتا ہے، اس لیے دوبارہ کوشش سے پہلے ایک گھنٹہ انتظار کرنا پڑتا ہے۔

internet سے تین 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 میں بھی یہ ports کھولیں۔ زیادہ تر VPS panels میں یہ الگ control ہوتا ہے۔ اسی وجہ سے ایسا box بھی connections قبول نہیں کرتا جس کا اپنا ufw status درست نظر آتا ہو۔

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 ان سب کی جانچ کرتی ہے اور کسی ایک کے missing ہونے پر رک جاتی ہے۔ اگر اس box پر Docker نیا ہے تو پہلے VPS پر Docker Compose کو فعال کریں۔

NetBird server کو quickstart script کے ذریعے انسٹال کریں

دستاویزی one-liner تازہ ترین release کو براہِ راست shell میں pipe کرتی ہے:

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

اس کے بجائے version کو pin کریں۔ latest تبدیل ہوتا رہتا ہے، اس لیے دو ہفتے کے فرق سے یہی command چلانے پر دو مختلف installations بنتی ہیں، اور disk پر یہ ریکارڈ بھی نہیں رہتا کہ آپ کی configuration کس installation نے لکھی تھی۔ کسی tagged release کو download کریں، اسے پڑھیں، پھر run کریں۔

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 کیسے manage کیا جائے گا:

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] منتخب کریں۔ Options 2 سے 5 تک config snippet لکھتے ہیں اور باقی wiring آپ کے ذمے چھوڑ دیتے ہیں۔ یہ اس machine پر درست ہے جہاں پہلے سے proxy چل رہا ہو، لیکن نئی machine پر درست نہیں۔ Option 0 کے بعد Let's Encrypt email address پوچھا جاتا ہے۔ یہ expiry notices کے لیے استعمال ہوتا ہے۔

پہلی installation پر NetBird Proxy service کے لیے no منتخب کریں۔ اسے دو مزید DNS records، proxy.netbird.example.com اور wildcard *.proxy.netbird.example.com، درکار ہوتے ہیں، اور plain mesh کے لیے یہ کوئی فائدہ نہیں دیتی۔ CrowdSec کے لیے بھی no منتخب کریں۔ دونوں بعد میں شامل کیے جا سکتے ہیں۔

Script موجودہ directory میں یہ files لکھتی ہے: docker-compose.yml، config.yaml جس کا mode 600 ہے، dashboard.env، اور traefik-dynamic.yaml جب آپ نے bundled Traefik منتخب کیا ہو۔ اس directory کو مستقل state سمجھ کر محفوظ رکھیں، کیونکہ config.yaml میں وہ key موجود ہوتی ہے جو store میں data کو encrypt کرتی ہے۔ اسے کھو دینے کا مسئلہ reinstall سے حل نہیں ہوتا۔

docker compose ps
docker compose logs -f netbird-server

ہر service کو running پڑھنا چاہیے، اور server log کو restart loop کے بجائے معمول پر آ جانا چاہیے۔ Certificate کو الگ monitor کریں:

docker compose logs traefik | grep -i acme

ACME (automatic certificate management environment) وہ protocol ہے جسے Traefik certificate حاصل کرنے کے لیے استعمال کرتا ہے۔ یہاں errors تقریباً ہمیشہ DNS یا بند port 80 کی وجہ سے ہوتی ہیں۔

پہلا admin account بنائیں

https://netbird.example.com کھولیں۔ Fresh install میں یہ login form کے بجائے setup page کھولتا ہے۔ Email address، name اور password درج کریں، پھر Create Account پر click کریں۔ یہ پہلا admin account بن جاتا ہے، اور page login form پر redirect ہو جاتا ہے۔

یہ account NetBird کے اپنے user store میں محفوظ ہوتا ہے، جسے netbird-server container میں شامل identity provider چلاتا ہے۔ اس کے لیے کسی external سروس کی ضرورت نہیں ہوتی۔ یہ ایک سال پہلے کے self-hosted NetBird کے مقابلے میں سب سے بڑی تبدیلی ہے۔ اس وقت working install کے لیے پہلے Zitadel یا Keycloak کو deploy کرنا پڑتا تھا، پھر setup.env میں OIDC (OpenID Connect) کی چار values copy کرنا ہوتی تھیں، ورنہ کچھ بھی start نہیں ہوتا تھا۔

اگر setup page کے بجائے browser certificate warning دکھائی دے تو certificate issue نہیں ہوا۔ آگے بڑھنے سے پہلے اسے درست کریں، کیونکہ dashboard اسی hostname کے ذریعے API سے بات کرتا ہے اور خراب certificate کی صورت میں مبہم انداز میں fail ہو جاتا ہے۔

اپنے پہلے peer کو شامل کریں

کلائنٹ کسی بھی Linux مشین پر انسٹال کریں۔ اگر آپ VPS کو بھی mesh میں شامل کرنا چاہتے ہیں تو اسے اسی پر بھی انسٹال کر سکتے ہیں:

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

Debian اور Ubuntu پر یہ script NetBird کا package repository configure کرتی ہے، پھر client کو apt کے ذریعے انسٹال کرتی ہے۔ اس طرح package manager ہی اس کا مالک رہتا ہے۔ اگر script کو shell میں pipe کرنا آپ کو مناسب نہ لگے تو اسے پہلے curl -fsSL -o install.sh https://pkgs.netbird.io/install.sh کے ذریعے محفوظ کریں اور sh install.sh چلانے سے پہلے پڑھ لیں۔ دونوں صورتوں میں تصدیق کریں کہ کیا انسٹال ہوا ہے:

apt-cache policy netbird

netbird command-line client اور daemon ہے۔ netbird-ui desktop tray app ہے، اور headless server پر اس کی ضرورت نہیں ہوتی۔

اب client کو اپنے server سے مربوط کریں:

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 browser میں کھولنے کے لیے ایک URL دکھاتی ہے، جہاں login مکمل کرنا ہوتا ہے۔ اس کے بعد:

netbird status
ip addr show wt0

netbird status سے چار lines پڑھیں: Management: Connected، Signal: Connected، ایک Relays: line جو دستیاب ہر relay کی اطلاع دیتی ہے، اور overlay range میں موجود NetBird IP:۔ wt0 وہ WireGuard interface ہے جسے NetBird بناتا ہے، اور اسے یہی address استعمال کرنا چاہیے۔

دوسری مشین کو setup key کے ذریعے بغیر نگرانی شامل کریں

ایسی مشین کے لیے browser login کام نہیں کرتا جس پر browser موجود نہ ہو اور جس کے سامنے کوئی شخص بھی نہ ہو۔ setup key ایک pre-authentication token ہے جو interactive مرحلے کے بغیر مشین کو register کرتا ہے۔ اسے dashboard میں Setup Keys کے تحت بنائیں۔

اس کی دو اقسام ہیں۔ one-off key بالکل ایک مشین کو authenticate کرتی ہے اور پھر استعمال ہو جاتی ہے۔ reusable key متعدد مشینیں register کرتی ہے، اور اس میں مشینوں کی زیادہ سے زیادہ تعداد کی اختیاری حد مقرر کی جا سکتی ہے۔ دونوں کے لیے expiry مقرر کی جاتی ہے، اور دونوں نئی peer کو خودکار طور پر کسی group میں شامل کر سکتی ہیں۔ اس طرح اس group کے access rules مشین کے ظاہر ہوتے ہی لاگو ہو جاتے ہیں۔

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

--hostname dashboard میں دکھایا جانے والا نام مقرر کرتا ہے۔ اس کے بغیر peer وہی نام اختیار کرتی ہے جو مشین خود استعمال کرتی ہے، اور ایسی entries کی پوری فہرست جن کا نام ubuntu ہو، کسی کے لیے مفید نہیں ہوتی۔

containers اور مختصر مدت کے build agents کے لیے key بناتے وقت اسے ephemeral مقرر کریں۔ ephemeral key کے ذریعے register ہونے والی peers اس وقت خودکار طور پر ہٹا دی جاتی ہیں جب وہ 10 منٹ سے زیادہ عرصے تک offline رہیں۔ اس سے peer list میں غیر فعال entries جمع نہیں ہوتیں۔

setup keys کے بارے میں منصوبہ بندی سے پہلے ایک حد سمجھ لیں: key کے expire ہونے یا حذف کیے جانے سے نئی registrations رک جاتی ہیں، لیکن اس key کے ذریعے پہلے سے register ہونے والی مشینیں disconnect نہیں ہوتیں۔ کسی مشین کا access ختم کرنے کے لیے اس peer کو ہٹانا ضروری ہے۔

کیا آپ کو اب بھی ایک الگ identity provider درکار ہے؟

چھوٹی تنصیب کے لیے نہیں۔ built-in user store dashboard سے بنائے گئے accounts سنبھالتا ہے، اور چند افراد کے لیے یہ کافی ہے۔

آپ کو external identity provider اس وقت چاہیے جب آپ کے پاس پہلے سے ایسا provider موجود ہو اور آپ users کی دوسری فہرست نہیں رکھنا چاہتے۔ NetBird ایسے ہر provider کو قبول کرتا ہے جو OIDC استعمال کرتا ہو۔ اپنے provider میں ایک confidential OIDC client register کریں، پھر اسے NetBird dashboard میں 4 values کے ساتھ شامل کریں: name، client ID، client secret اور issuer۔ NetBird آپ کو ایک redirect URL دے گا، جسے provider میں واپس paste کرنا ہوگا۔ Google، Microsoft Entra ID، Okta، Zitadel، Keycloak، Authentik اور Pocket ID کے لیے named integrations موجود ہیں؛ باقی providers کو generic OIDC کے طور پر شامل کیا جاتا ہے۔ اگر آپ پہلے ہی Authentik کو اپنے self-hosted single sign-on کے طور پر چلا رہے ہیں، تو یہی طریقہ استعمال کریں تاکہ users کی 2 فہرستوں کے بجائے ایک ہی account list برقرار رہے۔

provider شامل کرنے کے بعد local login دستیاب رہتا ہے، اور ہر configured provider login page پر ظاہر ہوتا ہے۔ ایک local admin account مضبوط password کے ساتھ برقرار رکھیں۔ اس طرح OIDC configuration خراب ہونے کی صورت میں بھی آپ کے پاس login کرنے کا راستہ موجود رہے گا۔

NetBird یا Headscale: آپ کو کون سا control plane چلانا چاہیے؟

دونوں ایک ہی dependency ختم کرتے ہیں: hosted control server، جس سے آپ کے clients بصورتِ دیگر رابطہ کرتے رہتے۔ تاہم، دونوں projects کی ساخت ایک جیسی نہیں ہے۔

Headscale، Tailscale control server کو دوبارہ implement کرتا ہے، اور آپ official Tailscale clients ہی استعمال کرتے رہتے ہیں۔ اس میں official web console موجود نہیں ہے۔ آپ config file کے خلاف headscale command سے users اور pre-authentication keys manage کرتے ہیں۔ Community web interfaces موجود ہیں، لیکن وہ project کا حصہ نہیں ہیں۔ یہ طریقہ ان لوگوں کے لیے موزوں ہے جو اپنی state کو files میں رکھنا اور تبدیلیوں کو version control میں manage کرنا چاہتے ہیں۔

NetBird پورا product فراہم کرتا ہے: اپنا client، اپنا dashboard، embedded identity provider، اور browser میں edit کی جانے والی access policies۔ اس سے آپ کے VPS پر زیادہ components شامل ہوتے ہیں، لیکن ایسے colleague کو کام سونپنا بہت آسان ہو جاتا ہے جو terminal کھولنے والا نہیں ہے۔

اگر آپ پہلے ہی Tailscale clients استعمال کر رہے ہیں یا کم سے کم control plane چاہتے ہیں تو Headscale چلائیں۔ اگر کئی لوگوں کو peers manage کرنے ہیں اور آپ خود اسے assemble کیے بغیر console اور SSO چاہتے ہیں تو NetBird چلائیں۔

یہ کتنے کم وسائل والے VPS پر چل سکتا ہے؟

دستاویزی کم از کم ضرورت 1 CPU اور 2 GB میموری ہے۔ NetBird کے اپنے نوٹس کے مطابق اب کم از کم ضرورت تقریباً 1 GB RAM ہے، کیونکہ user management اب مقامی ہے۔ اس کے مقابلے میں پرانے layout کو 2 GB سے 4 GB تک میموری درکار ہوتی تھی، جب stack میں مکمل Zitadel deployment شامل تھا۔ 2 GB والا VPS خریدیں۔ اضافی گنجائش upgrade کے دوران نئی images pull کرنے میں مدد دیتی ہے، جبکہ پرانی images ابھی disk پر موجود ہوتی ہیں۔

چھوٹے سرور پر تین چیزیں شامل نہ کرنا محفوظ ہے۔ NetBird Proxy service کو مسترد کریں۔ یہ internal services کو public hostnames پر شائع کرنے کے لیے ہے اور peers کے باہم connect ہونے سے اس کا کوئی تعلق نہیں۔ CrowdSec کو بھی مسترد کریں۔ اسے exposed سرور پر بعد میں شامل کرنا مفید ہے، لیکن پہلے دن نہیں۔ netbird_data volume میں موجود default SQLite store برقرار رکھیں۔ PostgreSQL پر صرف اس وقت منتقل ہوں جب deployment کو متعدد machines میں تقسیم کریں یا حقیقی concurrency کا سامنا ہو۔ یہ منتقلی بعد میں کی جا سکتی ہے اور اس کا طریقہ دستاویزی ہے۔

Relay وہ واحد component ہے جسے آپ ہٹا نہیں سکتے۔ جن دو peers کے NAT کی طرف سے ہر destination کے لیے مختلف port مقرر ہوتا ہے، وہ کبھی direct tunnel قائم نہیں کر سکتے۔ اس لیے relay ہی وہ واحد راستہ ہے جو انہیں کام کرنے کے قابل بناتا ہے۔ اسے disable کرنے سے memory بہت کم بچتی ہے، لیکن connections ایسے انداز میں ناکام ہو جاتے ہیں جس کی وجہ تلاش کرنا مشکل ہوتا ہے۔

جب ایک سرور کافی نہ رہے تو سب سے پہلے relays کو اس سرور سے الگ کریں۔ Standalone relay NB_LISTEN_ADDRESS، NB_EXPOSED_ADDRESS، NB_AUTH_SECRET اور NB_ENABLE_STUN کے ساتھ چلتا ہے۔ Shared secret relay اور main server دونوں پر یکساں ہونا چاہیے، ورنہ clients اس relay کے سامنے authenticate نہیں کر پائیں گے۔

خرابی کی صورتیں، اور آپ کو کیا نظر آئے گا

ڈیش بورڈ certificate warning دکھاتا ہے۔ Traefik نے certificate حاصل نہیں کیا۔ docker compose logs traefik | grep -i acme چلائیں۔ اس کی 2 وجوہات ہو سکتی ہیں۔ یا تو dig +short netbird.example.com ابھی اس VPS پر resolve نہیں ہو رہا، یا Let's Encrypt اور container کے درمیان کہیں TCP 80 بند ہے۔ عموماً یہ مسئلہ ufw پر نہیں بلکہ provider کے network firewall میں ہوتا ہے۔ دوبارہ مسلسل کوشش کرنے سے پہلے اصل وجہ دور کریں، کیونکہ ناکام validations پر rate limit لاگو ہوتی ہے اور آپ 1 گھنٹے تک دوبارہ کوشش نہیں کر سکیں گے۔

client کہتا ہے کہ connection قائم ہو گیا ہے، لیکن dashboard خالی ہے۔ client نے NetBird کی hosted service کے ساتھ register کیا ہے، کیونکہ --management-url موجود نہیں تھا۔ netbird status --detail چلائیں اور Management: لائن پڑھیں۔ اس میں اس server کا نام ہوتا ہے جس سے client حقیقت میں رابطہ کر رہا ہے۔ Management: Connected to https://api.netbird.io:443 نظر آنے کا مطلب ہے کہ client 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 بھی دکھاتا ہے۔ اس سے معلوم ہوتا ہے کہ کوشش کہاں تک پہنچی۔ بعض networks میں relayed ہی واحد دستیاب نتیجہ ہوتا ہے، اور اس صورت میں کوئی خرابی نہیں ہوتی۔

ایک peer شامل ہوتا ہے، لیکن کسی چیز تک رسائی نہیں ملتی۔ Mesh میں شامل ہونا اس بات کی ضمانت نہیں دیتا کہ 2 peers ایک دوسرے سے بات کر سکتے ہیں۔ اس کا فیصلہ access policies کرتی ہیں، اور جس group کے ساتھ کوئی policy منسلک نہ ہو وہ کسی چیز تک رسائی نہیں دے سکتا۔ Routes اور firewalls کی debugging شروع کرنے سے پہلے dashboard میں policy چیک کریں۔

netbird status daemon problem کی اطلاع دیتا ہے۔ 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 میں جمع کرتا ہے۔

بیک اپس اور اپ گریڈز

پورے انسٹالیشن کے لیے دو چیزیں اہم ہیں: وہ ڈائریکٹری جس میں docker-compose.yml اور config.yaml موجود ہیں، اور وہ Docker volume جس میں database اور encryption keys محفوظ ہیں۔ دونوں کا ایک ساتھ بیک اپ لیں۔ config.yaml وہ key رکھتا ہے جو store میں موجود data کو encrypt کرتی ہے، اس لیے اس کے بغیر database کی copy بحال کرنے پر کوئی قابلِ مطالعہ data دستیاب نہیں ہوگا۔

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 volume names کے آگے project directory کا نام لگاتا ہے، اس لیے netbird_data کے طور پر دستاویزی volume عموماً netbird_netbird_data کے نام سے ظاہر ہوتا ہے۔ پہلے docker volume ls چلائیں اور جو نام ظاہر ہو اسے استعمال کریں، ورنہ اوپر دیا گیا docker run خاموشی سے ایک empty volume بنا دے گا اور کچھ بھی archive نہیں کرے گا۔ Archives کو VPS سے باہر رکھیں۔ اگر آپ کے پاس پہلے سے backup tool موجود ہے تو restic یا BorgBackup offsite بیک اپ سنبھال سکتا ہے۔

Server کو upgrade کرنے کے لیے pull اور recreate کریں:

docker compose pull
docker compose up -d
docker compose ps

اس طریقے پر انحصار کرنے سے پہلے docker compose config | grep image: چلائیں۔ latest پڑھنے والے کسی بھی tag کو version پر pin کریں۔ اس کی وجہ وہی ہے جس کے باعث آپ نے install script کو pin کیا تھا: آپ جاننا چاہتے ہیں کہ کیا چل رہا ہے، اور upgrade میں مسئلہ آنے پر واپس جانے کے لیے ایک version بھی دستیاب ہونا چاہیے۔ Clients اسی package manager کے ذریعے upgrade ہوتے ہیں جس سے وہ install کیے گئے تھے۔

FAQ

کیا self-hosted NetBird کے لیے اپنا identity provider ضروری ہے؟

نہیں۔ موجودہ releases میں built-in user store شامل ہے، اس لیے آپ https://netbird.example.com پر browser میں پہلا 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 کا blocked ہونا ہے۔ یہ STUN port ہے جسے peers اپنا public address اور port معلوم کرنے کے لیے استعمال کرتے ہیں۔ اسے VPS firewall اور provider کے الگ network firewall، دونوں میں کھولیں۔ پھر دوبارہ netbird status --detail چلائیں اور Direct: line پڑھیں۔ ایسے network میں جس کا NAT ہر destination کے لیے مختلف port مقرر کرتا ہے، relayed ہی واحد ممکنہ نتیجہ ہے اور configuration میں کوئی خرابی نہیں۔

میرا client connect ہو گیا، لیکن dashboard میں کوئی peer نہیں دکھ رہا۔ کیا ہوا؟

client نے آپ کے server کے بجائے NetBird کی hosted service کے ساتھ register کیا۔ یہ اس وقت ہوتا ہے جب --management-url شامل نہ ہو۔ netbird status --detail اس server کو Management: line پر دکھاتا ہے جس سے client رابطہ کر رہا ہے، اس لیے 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 کو control کرتا ہے۔ NetBird اپنے client، admin dashboard اور identity provider integration کو اسی stack میں فراہم کرتا ہے۔ Headscale چلانے کے لیے چھوٹا ہے اور اپنی state files میں محفوظ رکھتا ہے۔ NetBird ایسے لوگوں کو دینا آسان ہے جو terminal استعمال نہیں کریں گے۔

self-hosted NetBird server کے لیے کس سائز کا VPS درکار ہے؟

دستاویزی minimum 1 CPU اور 2 GB memory ہے، اور خریدنے کے لیے 2 GB ہی مناسب مقدار ہے۔ حالیہ releases میں عملی minimum تقریباً 1 GB رہ گیا ہے، کیونکہ identity provider اب الگ deployment کے بجائے embedded ہے۔ install کے دوران optional proxy اور CrowdSec services کو رد کریں، اور جب تک واقعی PostgreSQL کی ضرورت نہ ہو، default SQLite store استعمال کرتے رہیں۔