NetBird VPN سرور کو اپنے VPS پر کیسے ہوسٹ کریں

NetBird VPN سرور کو self-host کرنے کے فوائد

NetBird VPN سرور کو self-host کرنے سے control plane آپ کے اپنے VPS پر آ جاتا ہے: یہ وہ حصہ ہے جو peer list کو برقرار رکھتا ہے، یہ فیصلہ کرتا ہے کہ کون سی مشین کس تک رسائی حاصل کر سکتی ہے، اور NAT (network address translation) کے پیچھے موجود دو peers کو ایک دوسرے کو تلاش کرنے میں مدد کرتا ہے۔ ٹنلز اب بھی WireGuard ہی رہتی ہیں، جو براہ راست آپ کی مشینوں کے درمیان انکرپٹ ہوتی ہیں۔ تبدیلی یہ آتی ہے کہ کوئی بیرونی کمپنی آپ کی ڈیوائسز کی انوینٹری یا آپ کے لاگ ان کے عمل کو کنٹرول نہیں کرتی۔ اس بات کو واضح رکھیں کہ اس سے آپ کو کیا حاصل ہوتا ہے، کیونکہ ایک hosted control plane بھی کبھی وہ keys نہیں رکھتا جو آپ کے ٹریفک کو انکرپٹ کرتی ہیں، اور اگر coordination server compromised ہو جائے تو وہ درحقیقت کیا کر سکتا ہے اس کی فہرست اس سے کہیں مختصر ہے جتنا زیادہ تر لوگ اسے پڑھنے سے پہلے سمجھتے ہیں۔

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

اگر آپ درحقیقت ایک ایسا سرور چاہتے ہیں جہاں سے آپ کا تمام ٹریفک باہر نکلے، تو mesh اس کام کے لیے ضرورت سے زیادہ پیچیدہ ہے۔ ایک سنگل VPS پر plain WireGuard VPN یا Tailscale exit node یہ کام بہت کم محنت سے کر دیتے ہیں۔ اور اگر مقصد مشینوں کو ایک دوسرے سے جوڑنے کے بجائے کسی ایک پرائیویٹ نیٹ ورک تک رسائی حاصل کرنا ہو، تو VPS پر Tailscale subnet router اس رینج کو اس tailnet میں مشتہر کر دیتا ہے جو آپ کے پاس پہلے سے موجود ہے، بغیر نیچے دیے گئے کسی بھی stack کے۔

اسٹیک دراصل کیا چلاتا ہے

لے آؤٹ حال ہی میں تبدیل ہوا ہے، اور زیادہ تر پرانی تحریریں پرانے لے آؤٹ کی وضاحت کرتی ہیں۔ اگست 2026 تک، release v0.76.2 پر، quickstart اسکرپٹ بطور ڈیفالٹ تین سروسز کے ساتھ ایک Compose فائل لکھتا ہے۔

• netbird-server میں مینجمنٹ API، سگنل سروس، ایمبیڈڈ STUN لسنر کے ساتھ ریلے، اور ایک ایمبیڈڈ شناخت فراہم کنندہ (identity provider) شامل ہے۔ پرانی releases میں یہ الگ الگ کنٹینرز تھے اور شناخت فراہم کنندہ ایک الگ Zitadel انسٹالیشن تھی جسے آپ کو پہلے بنانا پڑتا تھا۔
• dashboard ایڈمن ویب کنسول ہے۔
• traefik TLS (ٹرانسپورٹ لیئر سیکیورٹی) کو ٹرمینیٹ کرتا ہے اور پہلی بار اسٹارٹ ہونے پر Let's Encrypt سے سرٹیفکیٹ کی درخواست کرتا ہے۔

دو مزید سروسز موجود ہیں جو تب تک بند رہتی ہیں جب تک آپ پرامپٹ پر 'yes' نہ کہیں۔ NetBird پراکسی سروس داخلی سروسز کو عوامی ہوسٹ ناموں پر شائع کرتی ہے۔ CrowdSec نقصان دہ ٹریفک کو فلٹر کرتا ہے۔ ایک فعال میش بنانے کے لیے ان میں سے کسی کی بھی ضرورت نہیں ہے، اور دونوں ہی چھوٹے باکس پر میموری کا خرچ بڑھاتے ہیں۔

اگر آپ wg-easy in a single Docker container سے آ رہے ہیں، تو یہ حصوں کی تعداد میں ایک بڑی چھلانگ ہے۔ یہ آپ کو رسائی کی پالیسیاں، فی صارف اکاؤنٹس، اور ایسے پیئرز فراہم کرتا ہے جو ایک گیٹ وے کے بجائے براہ راست ایک دوسرے سے جڑتے ہیں۔

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

ایک پبلک ڈومین نام کا ہونا لازمی ہے۔ ڈیش بورڈ، API اور ریلے سبھی port 443 پر HTTPS استعمال کرتے ہیں، اور Traefik اپنا سرٹیفکیٹ Let's Encrypt سے HTTP challenge کے ذریعے حاصل کرتا ہے، جس کے لیے ایک ایسے نام کی ضرورت ہوتی ہے جو پبلک انٹرنیٹ سے اس VPS تک پہنچ سکے۔ صرف IP ایڈریس اس عمل میں کام نہیں کرے گا۔

ایک A record بنائیں، netbird.example.com جو VPS کے پبلک IPv4 ایڈریس کی طرف اشارہ کرتا ہو، اور کچھ بھی چلانے سے پہلے اس کے فعال ہونے کا انتظار کریں۔

dig +short netbird.example.com

اس کمانڈ کو آپ کے سرور کا ایڈریس ظاہر کرنا چاہیے۔ DNS کے پھیلنے (propagate) سے پہلے انسٹالر چلانے کا مطلب یہ ہے کہ پہلی بار شروع ہوتے ہی سرٹیفکیٹ کی درخواست ناکام ہو جائے گی، اور بار بار ناکام تصدیق کی وجہ سے Let's Encrypt کی ریٹ لمٹس (rate limits) لگ جائیں گی، جس کے بعد آپ کو دوبارہ کوشش کرنے کے لیے ایک گھنٹہ انتظار کرنا پڑے گا۔

انٹرنیٹ سے تین پورٹس تک رسائی ہونی چاہیے: سرٹیفکیٹ چیلنج اور 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) وہ طریقہ ہے جس سے ایک پیئر (peer) اس پبلک ایڈریس اور پورٹ کو جانتا ہے جو اس کے اپنے NAT نے تفویض کیا ہے، تاکہ دو پیئرز براہ راست ٹنل بنانے کی کوشش کر سکیں۔ اگر UDP 3478 بلاک ہو تو پیئرز پھر بھی TCP 443 پر ریلے کے ذریعے جڑ جاتے ہیں، اس لیے کچھ بھی ٹوٹا ہوا محسوس نہیں ہوتا۔ اس کے بجائے آپ کو ہر پیئر پر Connection type: Relayed ملتا ہے، اور تمام ٹریفک پیئر ٹو پیئر جانے کے بجائے آپ کے VPS سے گزرتی ہے۔

سافٹ ویئر کی طرف آپ کو Docker کے ساتھ Compose v2 پلگ ان، اور اس کے علاوہ jq اور curl کی ضرورت ہے۔ اسکرپٹ ان سب کو چیک کرتا ہے اور اگر کوئی ایک بھی موجود نہ ہو تو رک جاتا ہے۔ اگر اس باکس پر Docker نیا ہے، تو پہلے Docker Compose کو VPS پر فعال کریں۔

NetBird سرور کو کوئیک اسٹارٹ اسکرپٹ کے ساتھ انسٹال کریں

دستاویزی ون لائنر (one-liner) تازہ ترین ریلیز کو براہ راست شیل میں پائپ کرتا ہے:

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

اس کے بجائے اسے پن (pin) کریں۔ 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 پراکسی سروس کے لیے 'no' کہیں۔ اسے مزید دو DNS ریکارڈز درکار ہوتے ہیں، proxy.netbird.example.com اور وائلڈ کارڈ *.proxy.netbird.example.com، اور یہ سادہ میش (mesh) کے لیے کچھ نہیں کرتی۔ CrowdSec کے لیے بھی 'no' کہیں۔ دونوں کو بعد میں شامل کیا جا سکتا ہے۔

اسکرپٹ موجودہ ڈائریکٹری میں لکھتا ہے: docker-compose.yml، config.yaml (600 موڈ کے ساتھ)، dashboard.env، اور traefik-dynamic.yaml (جب آپ بنڈل شدہ Traefik کا انتخاب کرتے ہیں)۔ اس ڈائریکٹری کو ایسی اسٹیٹ سمجھیں جسے آپ کو محفوظ رکھنا ہے، کیونکہ config.yaml میں وہ کلید (key) موجود ہوتی ہے جو اسٹور میں موجود ڈیٹا کو انکرپٹ کرتی ہے۔ اسے کھو دینا ایسی چیز نہیں ہے جسے ری انسٹال سے ٹھیک کیا جا سکے۔

docker compose ps
docker compose logs -f netbird-server

ہر سروس کو running پڑھنا چاہیے، اور سرور لاگ کو لوپ میں ری اسٹارٹ ہونے کے بجائے مستحکم ہو جانا چاہیے۔ سرٹیفکیٹ کو الگ سے مانیٹر کریں:

docker compose logs traefik | grep -i acme

ACME (آٹومیٹک سرٹیفکیٹ مینجمنٹ انوائرمنٹ) وہ پروٹوکول ہے جسے Traefik سرٹیفکیٹ حاصل کرنے کے لیے استعمال کرتا ہے۔ یہاں غلطیاں تقریباً ہمیشہ DNS یا بند پورٹ 80 کی وجہ سے ہوتی ہیں۔

پہلا ایڈمن اکاؤنٹ بنائیں

https://netbird.example.com کھولیں۔ ایک نئی تنصیب (fresh install) پر یہ لاگ ان فارم کے بجائے سیٹ اپ کے صفحے پر لے جاتا ہے۔ ایک ای میل ایڈریس، نام اور پاس ورڈ درج کریں، پھر Create Account پر کلک کریں۔ یہ پہلا ایڈمن بن جاتا ہے، اور صفحہ خود بخود لاگ ان فارم پر ری ڈائریکٹ ہو جاتا ہے۔

یہ اکاؤنٹ NetBird کے اپنے یوزر اسٹور میں رہتا ہے، جو netbird-server کنٹینر میں ایمبیڈڈ شناخت فراہم کرنے والے (identity provider) کے ذریعے چلتا ہے۔ اس میں کوئی بیرونی چیز شامل نہیں ہے۔ یہ ایک سال پہلے کے سیلف ہوسٹڈ NetBird سے سب سے بڑی تبدیلی ہے، جب ایک فعال تنصیب کا مطلب یہ ہوتا تھا کہ پہلے Zitadel یا Keycloak کو کھڑا کیا جائے اور کسی بھی چیز کے شروع ہونے سے پہلے چار OIDC (OpenID Connect) ویلیوز کو setup.env میں کاپی کیا جائے۔

اگر آپ کو سیٹ اپ صفحے کے بجائے براؤزر سرٹیفکیٹ کی وارننگ ملے، تو اس کا مطلب ہے کہ سرٹیفکیٹ جاری نہیں ہوا۔ مزید آگے بڑھنے سے پہلے اسے ٹھیک کریں، کیونکہ ڈیش بورڈ اسی ہوسٹ نیم پر API سے بات کرتا ہے اور خراب سرٹیفکیٹ کے پیچھے الجھا دینے والے طریقوں سے ناکام ہو جاتا ہے۔

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

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

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 ڈیسک ٹاپ ٹرے ایپ ہے، اور ہیڈلیس (headless) سرور کو اس کی ضرورت نہیں ہوتی۔

اب کلائنٹ کو اپنے سرور کی طرف پوائنٹ کریں:

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: لائن جو ہر دستیاب ریلے (relay) کی اطلاع دیتی ہے، اور اوورلے رینج میں ایک NetBird IP:۔ wt0 وہ WireGuard انٹرفیس ہے جو NetBird بناتا ہے، اور اس پر وہی ایڈریس ہونا چاہیے۔

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

جن مشینوں پر browser موجود نہ ہو اور جن کے سامنے کوئی صارف نہ ہو، ان پر browser لاگ ان کام نہیں کرتا۔ ایک setup key دراصل ایک pre-authentication ٹوکن ہے جو کسی مشین کو انٹرایکٹو مرحلے کے بغیر رجسٹر کر دیتا ہے۔ اسے ڈیش بورڈ میں Setup Keys کے تحت بنائیں۔

اس کی دو اقسام ہیں۔ ایک one-off key صرف ایک مشین کی تصدیق کرتی ہے اور پھر ختم ہو جاتی ہے۔ ایک reusable key بہت سی مشینوں کو رجسٹر کرتی ہے، جس میں تعداد کی حد مقرر کی جا سکتی ہے۔ دونوں کی ایک میعاد (expiry) ہوتی ہے، اور دونوں نئی مشین کو خودکار طور پر کسی گروپ میں شامل کر سکتی ہیں، تاکہ مشین کے ظاہر ہوتے ہی اس گروپ پر لاگو رسائی کے قوانین (access rules) اس پر بھی لاگو ہو جائیں۔

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

--hostname ڈیش بورڈ میں نظر آنے والا نام سیٹ کرتا ہے۔ اس کے بغیر، مشین وہی نام استعمال کرتی ہے جو اس نے خود رکھا ہوتا ہے، اور ubuntu نام والی بہت سی انٹریز کسی کے کام نہیں آتیں۔

کنٹینرز اور مختصر مدت کے build agents کے لیے، کی (key) بناتے وقت اسے ephemeral کے طور پر نشان زد کریں۔ ephemeral کی کے ساتھ رجسٹرڈ peers خود بخود ہٹا دیے جاتے ہیں جب وہ 10 منٹ سے زیادہ offline رہیں، جس سے peer لسٹ میں مردہ انٹریز نہیں رہتیں۔

setup keys کے ساتھ منصوبہ بندی کرنے سے پہلے ایک حد کو سمجھنا ضروری ہے: کی کو ختم کرنے یا ڈیلیٹ کرنے سے نئی رجسٹریشن رک جاتی ہے، لیکن یہ ان مشینوں کو منقطع نہیں کرتی جو پہلے ہی اس کے ذریعے رجسٹر ہو چکی ہیں۔ کسی مشین کی رسائی ختم کرنے کا مطلب اس peer کو ہٹانا ہے۔

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

چھوٹی تنصیب کے لیے، نہیں۔ بلٹ ان user store ڈیش بورڈ سے بنائے گئے اکاؤنٹس کو سنبھال لیتا ہے، اور چند لوگوں کے لیے یہ کافی ہے۔

آپ کو بیرونی identity provider کی ضرورت تب پڑتی ہے جب آپ کے پاس پہلے سے ایک موجود ہو اور آپ صارفین کی دوسری فہرست نہیں بنانا چاہتے۔ NetBird ہر اس provider کو قبول کرتا ہے جو OIDC پر بات کرتا ہے۔ اپنے 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 کنٹرول سرور کو دوبارہ نافذ کرتا ہے، اور آپ بدستور آفیشل Tailscale کلائنٹس استعمال کرتے رہتے ہیں۔ اس میں کوئی آفیشل ویب کنسول نہیں ہے۔ آپ صارفین اور pre-authentication keys کو ایک کنفیگریشن فائل کے خلاف headscale کمانڈ کے ذریعے مینیج کرتے ہیں۔ کمیونٹی کے بنائے ہوئے ویب انٹرفیس موجود ہیں، لیکن وہ اس پروجیکٹ کا حصہ نہیں ہیں۔ یہ ان لوگوں کے لیے موزوں ہے جو اپنی اسٹیٹ کو فائلوں میں اور تبدیلیوں کو ورژن کنٹرول میں رکھنا چاہتے ہیں۔

NetBird مکمل پروڈکٹ فراہم کرتا ہے: اس کا اپنا کلائنٹ، اپنا ڈیش بورڈ، ایک ایمبیڈڈ شناخت فراہم کنندہ (identity provider)، اور براؤزر میں ایڈٹ کی جانے والی ایکسیس پالیسیاں۔ آپ کے VPS پر اس کے زیادہ اجزاء (moving parts) ہوتے ہیں، لیکن کسی ایسے ساتھی کے حوالے کرنا بہت آسان ہے جو کبھی ٹرمینل نہیں کھولے گا۔

اگر آپ پہلے سے Tailscale کلائنٹس استعمال کر رہے ہیں یا آپ کم سے کم ممکنہ کنٹرول پلین چاہتے ہیں تو Headscale چلائیں۔ اگر کئی لوگوں کو پیئرز (peers) کو مینیج کرنے کی ضرورت ہے اور آپ بغیر کسی اضافی سیٹ اپ کے کنسول اور SSO چاہتے ہیں تو NetBird چلائیں۔ کسی ایک کا انتخاب کرنے سے پہلے، Tailscale کا مفت پلان درحقیقت کیا کور کرتا ہے چیک کریں، کیونکہ ایک ایسا گروپ جو 6 صارفین اور لامحدود ڈیوائسز کے اندر آتا ہے، وہ ہوسٹڈ کنٹرول پلین کے لیے کچھ ادا نہیں کرتا اور ہو سکتا ہے اسے خود چلانے کی کوئی وجہ نہ ہو۔ اس حد سے آگے بل مشینوں کی تعداد کے بجائے لوگوں کی تعداد کے ساتھ بڑھتا ہے، لہذا Tailscale آپ کے گروپ سے کیا چارج کرے گا اس کا حساب لگانا آپ کو ایک ایسی رقم دے گا جس کا موازنہ آپ اس VPS اور ان گھنٹوں سے کر سکتے ہیں جو یہ اسٹیک آپ سے لیتا ہے۔

اس کام کے لیے کم از کم کتنا چھوٹا VPS کافی ہے؟

دستاویزی کم از کم ضرورت 1 CPU اور 2 GB میموری ہے۔ NetBird کے اپنے نوٹس کے مطابق، اب جبکہ یوزر مینجمنٹ مقامی (local) ہے، موجودہ حد 1 GB RAM کے قریب ہے، جبکہ پرانے لے آؤٹ میں مکمل Zitadel ڈیپلائمنٹ کے لیے 2 GB سے 4 GB درکار ہوتے تھے۔ 2 GB خریدیں۔ اضافی گنجائش (headroom) ہی وہ چیز ہے جو اپ گریڈ کے دوران نئے امیجز کو ڈاؤن لوڈ کرنے کی اجازت دیتی ہے جبکہ پرانے امیجز ابھی ڈسک پر موجود ہوتے ہیں۔

چھوٹے باکس پر تین چیزوں کو چھوڑنا محفوظ ہے۔ NetBird Proxy سروس کو مسترد کر دیں، جو کہ اندرونی سروسز کو پبلک ہوسٹ نیمز پر شائع کرنے کے لیے ہوتی ہے اور اس کا پیئرز (peers) کے آپس میں جڑنے سے کوئی تعلق نہیں ہے۔ CrowdSec کو مسترد کر دیں، جسے پہلے دن کے بجائے بعد میں کسی ایکسپوزڈ باکس پر شامل کرنا زیادہ بہتر ہے۔ ڈیفالٹ SQLite اسٹور کو netbird_data والیوم میں رکھیں، اور PostgreSQL پر تب ہی منتقل ہوں جب آپ ڈیپلائمنٹ کو مختلف مشینوں پر تقسیم کریں یا حقیقی کنکرنسی (concurrency) کا سامنا ہو، جسے دستاویزات میں ایک ایسی مائیگریشن کے طور پر بیان کیا گیا ہے جو آپ بعد میں کر سکتے ہیں۔

ریلے (relay) وہ واحد جزو ہے جسے آپ ختم نہیں کر سکتے۔ دو پیئرز جن کا NAT ہر منزل (destination) کے لیے الگ پورٹ تفویض کرتا ہے، وہ کبھی بھی براہ راست ٹنل قائم نہیں کر پائیں گے، اس لیے ریلے ہی واحد راستہ ہے جو انہیں کام کرنے کے قابل بناتا ہے۔ اسے غیر فعال کرنے سے بہت کم میموری بچتی ہے اور کنکشنز اس طرح ٹوٹتے ہیں جنہیں ٹریس کرنا مشکل ہوتا ہے۔

جب ایک باکس کافی نہ رہے، تو ریلے وہ پہلی چیز ہے جسے وہاں سے منتقل کرنا چاہیے۔ ایک اسٹینڈ الون ریلے NB_LISTEN_ADDRESS، NB_EXPOSED_ADDRESS، NB_AUTH_SECRET اور NB_ENABLE_STUN کے ساتھ چلتا ہے۔ شیئرڈ سیکرٹ (shared secret) کا ریلے اور مین سرور دونوں پر ایک جیسا ہونا ضروری ہے، ورنہ کلائنٹس اس پر تصدیق (authenticate) کرنے میں ناکام ہو جائیں گے۔

ناکامی کی صورتیں اور آپ کو کیا نظر آئے گا

ڈیش بورڈ پر سرٹیفکیٹ کی وارننگ نظر آتی ہے۔ Traefik نے سرٹیفکیٹ حاصل نہیں کیا۔ docker compose logs traefik | grep -i acme چلائیں۔ اس کی دو وجوہات ہو سکتی ہیں۔ یا تو dig +short netbird.example.com ابھی تک اس VPS کی طرف اشارہ نہیں کر رہا، یا Let's Encrypt اور کنٹینر کے درمیان کہیں TCP 80 بند ہے، جو عام طور پر ufw کے بجائے پرووائیڈر کے نیٹ ورک فائر وال پر ہوتا ہے۔ دوبارہ کوشش کرنے سے پہلے وجہ درست کریں، کیونکہ ناکام توثیق (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 دکھاتا ہے۔ کوئی براہ راست ٹنل نہیں بن رہی، اس لیے تمام ٹریفک آپ کے VPS سے گزرتی ہے اور لیٹنسی (latency) میں ایک ہاپ (hop) کا اضافہ کرتی ہے۔ 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 volume جس میں ڈیٹا بیس اور انکرپشن کیز محفوظ ہیں۔ ان دونوں کا بیک اپ ایک ساتھ لیں۔ 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 والیوم کے ناموں کے ساتھ پروجیکٹ ڈائریکٹری کا سابقہ (prefix) لگاتا ہے، اس لیے netbird_data کے طور پر دستاویزی والیوم عام طور پر netbird_netbird_data کے نام سے ظاہر ہوتا ہے۔ پہلے docker volume ls چلائیں اور اس نام کا استعمال کریں جو وہ پرنٹ کرتا ہے، ورنہ اوپر دیا گیا docker run خاموشی سے ایک خالی والیوم بنا کر ناکام ہو جائے گا اور کچھ بھی آرکائیو نہیں ہوگا۔ آرکائیوز کو VPS سے باہر رکھیں۔ اگر آپ کے پاس پہلے سے کوئی بیک اپ ٹول موجود ہے، تو restic یا BorgBackup آف سائٹ بیک اپ کا کام سنبھال لیتے ہیں۔

سرور کو اپ گریڈ کرنے کا مطلب امیج کو pull کرنا اور دوبارہ تخلیق کرنا ہے:

docker compose pull
docker compose up -d
docker compose ps

اس پر انحصار کرنے سے پہلے، docker compose config | grep image: چلائیں۔ کوئی بھی ٹیگ جس پر latest لکھا ہو اسے ایک مخصوص ورژن پر پن (pin) کیا جانا چاہیے، اسی وجہ سے جس کے لیے آپ نے انسٹال اسکرپٹ کو پن کیا تھا: آپ یہ جاننا چاہتے ہیں کہ کیا چل رہا ہے، اور اپ گریڈ کے مسائل پیدا ہونے کی صورت میں آپ کے پاس واپس جانے کے لیے ایک ورژن موجود ہونا چاہیے۔ کلائنٹس اس پیکیج مینیجر کے ذریعے اپ گریڈ ہوتے ہیں جس نے انہیں انسٹال کیا تھا۔

FAQ

کیا NetBird کو self-host کرنے کے لیے مجھے اپنے identity provider کی ضرورت ہے؟

نہیں۔ موجودہ releases میں ایک بلٹ ان یوزر اسٹور شامل ہے، لہذا آپ براؤزر میں https://netbird.example.com پر پہلا ایڈمن اکاؤنٹ بناتے ہیں اور اس کے بعد ڈیش بورڈ سے صارفین کا اضافہ کرتے ہیں۔ ایک بیرونی OIDC فراہم کنندہ اختیاری ہے اور اسے بعد میں چار اقدار کے ساتھ شامل کیا جا سکتا ہے: نام، کلائنٹ آئی ڈی، کلائنٹ سیکرٹ اور جاری کنندہ۔ وہ گائیڈز جو آپ کو NetBird سے پہلے Zitadel یا Keycloak تعینات کرنے کا کہتی ہیں، وہ ایسے سیٹ اپ کی وضاحت کرتی ہیں جس کی اب ضرورت نہیں ہے، اور ان پر عمل کرنے سے آپ کو ایک اضافی سروس چلانے کی قیمت چکانی پڑتی ہے۔

میرے تمام peers Connection type: Relayed کیوں دکھا رہے ہیں؟

براہ راست کنکشن نہیں بن رہے ہیں، اس لیے ٹریفک آپ کے VPS پر موجود ریلے کے ذریعے جاتی ہے۔ اس کی عام وجہ 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 صرف ایک کنٹرول پلین ہے: آپ اسے headscale کمانڈ اور ایک کنفیگ فائل کے ساتھ منظم کرتے ہیں، اس میں کوئی آفیشل ویب کنسول نہیں ہے، اور یہ آفیشل Tailscale کلائنٹس کو چلاتا ہے۔ NetBird اپنا کلائنٹ، ایک ایڈمن ڈیش بورڈ اور identity provider انٹیگریشن ایک ہی اسٹیک میں فراہم کرتا ہے۔ Headscale چلانے میں چھوٹا ہے اور اپنی حالت کو فائلوں میں محفوظ رکھتا ہے۔ NetBird کو ان لوگوں کے حوالے کرنا آسان ہے جو ٹرمینل استعمال نہیں کریں گے۔

self-hosted NetBird سرور کو کس سائز کے VPS کی ضرورت ہے؟

دستاویزی کم از کم ضرورت 1 CPU اور 2 GB میموری ہے، اور 2 GB ہی وہ تعداد ہے جو آپ کو خریدنی چاہیے۔ عملی حد حالیہ releases میں تقریباً 1 GB تک گر گئی ہے کیونکہ identity provider اب الگ تعیناتی کے بجائے ایمبیڈڈ ہے۔ انسٹالیشن کے دوران اختیاری پراکسی اور CrowdSec سروسز کو مسترد کریں، اور تب تک ڈیفالٹ SQLite اسٹور پر رہیں جب تک کہ آپ کو واقعی PostgreSQL کی ضرورت نہ پڑے۔