কিভাবে নিজের VPS-এ NetBird VPN সার্ভার সেটআপ করবেন

NetBird VPN সার্ভার নিজে হোস্ট করার সুবিধা

NetBird VPN সার্ভার নিজে হোস্ট করলে কন্ট্রোল প্লেনটি আপনার নিজস্ব VPS-এ থাকে: এটি এমন একটি অংশ যা পিয়ার লিস্ট সংরক্ষণ করে, কোন মেশিন কোন মেশিনের সাথে যোগাযোগ করতে পারবে তা নির্ধারণ করে এবং NAT (network address translation)-এর পেছনে থাকা দুটি পিয়ারকে একে অপরের সাথে সংযোগ স্থাপনে সাহায্য করে। টানেলগুলো মূলত WireGuard-এর, যা সরাসরি আপনার মেশিনগুলোর মধ্যে এনক্রিপ্ট করা থাকে। এতে পরিবর্তন শুধু এটুকুই যে, কোনো বাইরের কোম্পানি আপনার ডিভাইসের তালিকা বা লগইন প্রবাহ নিয়ন্ত্রণ করে না। এটি আপনাকে কী সুবিধা দিচ্ছে সে সম্পর্কে পরিষ্কার ধারণা রাখুন, কারণ হোস্ট করা কন্ট্রোল প্লেনও আপনার ট্রাফিক এনক্রিপ্ট করার চাবিকাঠি (keys) ধারণ করে না এবং একটি কোঅর্ডিনেশন সার্ভার আপস করা হলে বাস্তবে কী করতে পারে তা সাধারণ মানুষের ধারণার চেয়ে অনেক সীমিত।

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 অনেক কম পরিশ্রমে সেই কাজটি করতে পারে। আর যদি লক্ষ্য হয় মেশিনগুলোকে একে অপরের সাথে যুক্ত করার পরিবর্তে একটি প্রাইভেট নেটওয়ার্কে পৌঁছানো, তবে a Tailscale subnet router on a VPS আপনার বিদ্যমান নেটওয়ার্কে সেই রেঞ্জটি যুক্ত করতে পারে, যার জন্য নিচের কোনো জটিল কাঠামোর প্রয়োজন হয় না।

স্ট্যাকটি আসলে কী চালায়

লেআউটটি সম্প্রতি পরিবর্তিত হয়েছে, এবং বেশিরভাগ পুরোনো লেখায় আগের লেআউটটি বর্ণনা করা হয়েছে। October 2026-এ v0.80.0 এবং এই গাইডে নির্ধারিত release v0.76.2 দিয়ে যাচাই করে দেখা গেছে, quickstart script ডিফল্টভাবে তিনটি service-সহ একটি Compose file তৈরি করে।

• netbird-server management API, signal service, embedded STUN listener-সহ relay এবং embedded identity provider চালায়। পুরোনো release-গুলোতে এগুলো আলাদা container ছিল, এবং identity provider ছিল আলাদা Zitadel installation, যা আপনাকে আগে তৈরি করতে হতো।
• dashboard admin web console।
• traefik TLS (transport layer security) termination করে এবং প্রথমবার start হওয়ার সময় Let's Encrypt-এর কাছে একটি certificate চায়।

আরও দুটি service আছে, তবে prompt-এ yes না বলা পর্যন্ত সেগুলো চালু হয় না। NetBird Proxy service internal service-গুলোকে public hostname-এ প্রকাশ করে। CrowdSec ক্ষতিকর traffic filter করে। কার্যকর mesh তৈরি করতে কোনোটিই প্রয়োজনীয় নয়, এবং ছোট server-এ দুটিই memory ব্যবহার করে।

আপনি যদি একটি Docker container-এ wg-easy থেকে এসে থাকেন, তাহলে এটি component-এর সংখ্যায় একটি বড় বৃদ্ধি। এর বিনিময়ে access policy ও per-user account এবং একটি gateway-এর মাধ্যমে না গিয়ে সরাসরি একে অপরের সঙ্গে সংযুক্ত হওয়া peer পাওয়া যায়।

শুরু করার আগে যা প্রয়োজন

একটি public domain name ঐচ্ছিক নয়। Dashboard, API এবং relay—সবই port 443-এ HTTPS ব্যবহার করে, আর Traefik TLS-ALPN-01 challenge-এর মাধ্যমে Let's Encrypt থেকে certificate সংগ্রহ করে। এই challenge-এর উত্তর port 443-এ দিতে হয়। তাই এমন একটি name প্রয়োজন, যা public internet থেকে এই VPS-এ resolve হয়। এই পদ্ধতিতে সরাসরি IP address কাজ করবে না।

একটি A record তৈরি করুন, netbird.example.com যা VPS-এর public IPv4 address-এ নির্দেশ করবে। কোনো কমান্ড চালানোর আগে DNS propagation সম্পূর্ণ হওয়া পর্যন্ত অপেক্ষা করুন।

dig +short netbird.example.com

এতে আপনার server-এর address প্রদর্শিত হওয়া উচিত। DNS propagate হওয়ার আগে installer চালালে প্রথম start-এর সময় certificate request ব্যর্থ হবে। বারবার validation ব্যর্থ হলে Let's Encrypt rate limit-এও পড়তে পারেন। তখন আবার চেষ্টা করার আগে limit পূরণ হওয়া পর্যন্ত অপেক্ষা করতে হবে।

Internet থেকে 3টি port-এ পৌঁছানো আবশ্যক: HTTPS-এ redirect-এর জন্য TCP 80, dashboard, API, signal ও relay traffic এবং certificate challenge-এর জন্য 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 panel-এ এটি আলাদা একটি নিয়ন্ত্রণব্যবস্থা। তাই server-এর নিজের ufw status সঠিক দেখালেও connection প্রত্যাখ্যাত হতে পারে।

STUN (session traversal utilities for NAT) ব্যবহার করে একটি peer জানতে পারে তার NAT কোন public address এবং port নির্ধারণ করেছে। ফলে 2টি peer সরাসরি tunnel তৈরির চেষ্টা করতে পারে। UDP 3478 block করলেও peer-রা TCP 443-এর relay ব্যবহার করে সংযুক্ত হতে পারে, তাই কোনো কিছু নষ্ট হয়েছে বলে মনে নাও হতে পারে। যেসব peer সরাসরি পথ খুঁজে পায় না, তাদের ক্ষেত্রে Connection type: Relayed দেখা যায়। তাদের traffic peer-to-peer না গিয়ে আপনার VPS-এর মধ্য দিয়ে যায়। একই LAN-এর peer-রা তাদের local address ব্যবহার করে সরাসরি সংযুক্ত হতে পারে।

Software-এর ক্ষেত্রে আপনার Docker এবং Compose v2 plugin দরকার। পাশাপাশি jq এবং curl-ও প্রয়োজন। Script Docker, Compose এবং jq পরীক্ষা করে। যেকোনো একটি না থাকলে script বন্ধ হয়ে যায়। এটি curl পরীক্ষা না করেই ব্যবহার করে, তাই আগে এটি install করুন। এই server-এ Docker নতুন হলে প্রথমে VPS-এ Docker Compose সচল করুন।

quickstart script দিয়ে NetBird server ইনস্টল করুন

নথিভুক্ত one-liner সর্বশেষ release সরাসরি shell-এ pipe করে:

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

এর পরিবর্তে নির্দিষ্ট release ব্যবহার করুন। latest পরিবর্তিত হয়। তাই একই command দুই সপ্তাহের ব্যবধানে চালালে দুটি ভিন্ন install তৈরি হয়, এবং কোনটি আপনার config লিখেছে তা disk-এ নথিভুক্ত থাকে না। একটি tagged release download করুন, সেটি পড়ে দেখুন, তারপর চালান।

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 কীভাবে পরিচালিত হবে:

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 থেকে 4 একটি config snippet লেখে এবং বাকি সংযোগ আপনাকেই করতে দেয়। Option 5 Compose file, dashboard.env এবং config.yaml লেখে এবং terminal-এ setup documentation দেখায়। যে server-এ আগে থেকেই proxy চলছে, সেখানে এটি সঠিক পছন্দ। কিন্তু নতুন server-এ এটি সঠিক নয়। এরপর Option 0 একটি email address জানতে চায়। Traefik এই address ব্যবহার করে আপনার Let's Encrypt account-এ নিবন্ধন করে। Prompt-এ এটিকে এখনও certificate notification-এর address বলা হয়। তবে Let's Encrypt June 4, 2025 থেকে expiry email পাঠানো বন্ধ করেছে। তাই renewal সমস্যা inbox-এর বদলে Traefik log-এ দেখা যাবে।

প্রথম install-এর সময় NetBird Proxy service চালু করতে সম্মতি দেবেন না। এর জন্য আরও একটি DNS record প্রয়োজন: একটি wildcard *.netbird.example.com CNAME, যা netbird.example.com-এর দিকে নির্দেশ করবে। সাধারণ mesh-এর জন্য এর কোনো কার্যকারিতা নেই। Proxy enabled থাকলেই শুধু CrowdSec prompt দেখা যায়। তাই proxy প্রত্যাখ্যান করলে CrowdSec-ও বাদ পড়ে। দুটিই পরে যোগ করা যাবে।

Script বর্তমান directory-তে এগুলো লেখে: docker-compose.yml, mode 600-সহ config.yaml এবং dashboard.env। Bundled Traefik ব্যবহার করলে NetBird Proxy enabled করার সময়ই শুধু এটি traefik-dynamic.yaml এবং proxy.env যোগ করে। ওই directory-কে সংরক্ষণযোগ্য state হিসেবে বিবেচনা করুন। কারণ config.yaml store-এ থাকা data encrypt করার key ধরে রাখে। এটি হারালে reinstall করে সমস্যা সমাধান হবে না।

docker compose ps
docker compose logs -f netbird-server

প্রতিটি service-এর running পড়া উচিত। Server log-এও loop করে restart না হয়ে স্থিতিশীল হওয়া উচিত। Certificate আলাদাভাবে monitor করুন:

docker compose logs traefik | grep -i acme

ACME (automatic certificate management environment) হলো certificate পাওয়ার জন্য Traefik ব্যবহৃত protocol। এখানে error হলে কারণ প্রায় সবসময় DNS সমস্যা অথবা 443 port বন্ধ থাকা।

প্রথম অ্যাডমিন অ্যাকাউন্ট তৈরি করুন

https://netbird.example.com খুলুন। নতুন ইনস্টলেশনের ক্ষেত্রে এটি লগইন ফর্মের পরিবর্তে একটি সেটআপ পেজে নিয়ে যাবে। একটি ইমেইল ঠিকানা, নাম এবং পাসওয়ার্ড দিন, তারপর Create Account-এ ক্লিক করুন। এটিই প্রথম অ্যাডমিন অ্যাকাউন্ট হিসেবে গণ্য হবে এবং পেজটি আপনাকে লগইন ফর্মে রিডাইরেক্ট করবে।

এই অ্যাকাউন্টটি NetBird-এর নিজস্ব ইউজার স্টোরে থাকে, যা netbird-server কন্টেইনারে এমবেড করা একটি আইডেন্টিটি প্রোভাইডার দ্বারা পরিচালিত হয়। এতে বাইরের কোনো কিছুর প্রয়োজন হয় না। এক বছর আগের সেলফ-হোস্টেড NetBird-এর তুলনায় এটি সবচেয়ে বড় পরিবর্তন; তখন একটি কার্যকর ইনস্টলেশনের জন্য প্রথমে Zitadel বা Keycloak সেটআপ করতে হতো এবং কোনো কিছু শুরু করার আগেই setup.env-এ চারটি OIDC (OpenID Connect) ভ্যালু কপি করতে হতো।

যদি সেটআপ পেজের পরিবর্তে ব্রাউজারে সার্টিফিকেট ওয়ার্নিং পান, তবে বুঝবেন সার্টিফিকেট ইস্যু হয়নি। পরবর্তী ধাপে যাওয়ার আগে এটি সমাধান করুন, কারণ ড্যাশবোর্ড একই হোস্টনামের মাধ্যমে API-এর সাথে যোগাযোগ করে এবং ত্রুটিপূর্ণ সার্টিফিকেটের কারণে এটি বিভ্রান্তিকরভাবে ব্যর্থ হতে পারে।

আপনার প্রথম পিয়ার যুক্ত করুন

যেকোনো Linux মেশিনে ক্লায়েন্ট ইনস্টল করুন, এমনকি আপনি যদি এটিকে মেশের (mesh) অন্তর্ভুক্ত করতে চান তবে 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 হলো সেই WireGuard ইন্টারফেস যা NetBird তৈরি করে এবং এতে একই অ্যাড্রেস থাকা উচিত।

ব্রাউজার ছাড়া এবং সামনে কোনো ব্যবহারকারী না থাকা মেশিনে ব্রাউজার লগইন কাজ করে না। একটি setup key হলো pre-authentication token, যা interactive ধাপ ছাড়াই মেশিন নিবন্ধন করে। Dashboard-এর Setup Keys-এ গিয়ে একটি তৈরি করুন।

এগুলোর 2 ধরনের রয়েছে। One-off key ঠিক 1টি মেশিনকে authenticate করে এবং এরপর ব্যবহৃত হয়ে যায়। Reusable key একাধিক মেশিন নিবন্ধন করতে পারে; চাইলে সর্বোচ্চ সংখ্যাও নির্ধারণ করা যায়। উভয় key-এর জন্য expiry নির্ধারণ করা যায়। উভয় key-ই নতুন peer-কে স্বয়ংক্রিয়ভাবে একটি group-এ যুক্ত করতে পারে। ফলে মেশিনটি দেখা দেওয়ার সঙ্গে সঙ্গে ওই group-এর access rule প্রযোজ্য হয়।

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

--hostname Dashboard-এ প্রদর্শিত নাম নির্ধারণ করে। এটি না থাকলে peer মেশিনের নিজস্ব নাম ব্যবহার করে। আর সব entry-এর নাম ubuntu হলে fleet পরিচালনা করা কঠিন হয়।

Container এবং স্বল্পমেয়াদি build agent-এর জন্য key তৈরি করার সময় সেটিকে ephemeral হিসেবে চিহ্নিত করুন। Ephemeral key দিয়ে নিবন্ধিত peer 10 মিনিটের বেশি offline থাকলে স্বয়ংক্রিয়ভাবে সরিয়ে দেওয়া হয়। এতে peer list-এ অকার্যকর entry জমে থাকে না।

Setup key ব্যবহার করে পরিকল্পনা করার আগে একটি সীমা বুঝে নিন। কোনো key-এর expiry শেষ হলে বা সেটি revoke করলে নতুন registration বন্ধ হয়। তবে ওই key দিয়ে ইতিমধ্যে নিবন্ধিত মেশিনগুলো disconnect হয় না। কোনো মেশিনের access সরাতে হলে সেই peer সরাতে হবে।

আপনার কি এখনও আলাদা identity provider প্রয়োজন?

ছোট কোনো ইনস্টলেশনের ক্ষেত্রে, না। বিল্ট-ইন user store ড্যাশবোর্ড থেকে তৈরি করা অ্যাকাউন্টগুলো পরিচালনা করে, যা অল্প সংখ্যক ব্যবহারকারীর জন্য যথেষ্ট।

আপনার যদি আগে থেকেই একটি identity provider থাকে এবং আপনি ব্যবহারকারীদের দ্বিতীয় কোনো তালিকা তৈরি করতে না চান, তবেই আপনার একটি external 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: কোন control plane চালাবেন?

উভয়ই একই dependency সরিয়ে দেয়: hosted control server, যেখানে না হলে আপনার client-গুলো নিজে থেকে যোগাযোগ করত। তবে project দুটির কাঠামো এক নয়।

Headscale, Tailscale control server-এর পুনঃবাস্তবায়ন। আপনি official Tailscale client-ই ব্যবহার করতে থাকেন। কোনো official web console নেই। একটি config file-এর বিপরীতে headscale command ব্যবহার করে user এবং pre-authentication key পরিচালনা করেন। Community web interface আছে, তবে সেগুলো project-এর অংশ নয়। যারা file-এ state রাখতে এবং version control-এ পরিবর্তন সংরক্ষণ করতে চান, তাদের জন্য এই পদ্ধতি উপযোগী।

NetBird পুরো product সরবরাহ করে: নিজস্ব client, নিজস্ব dashboard, embedded identity provider এবং browser-এ সম্পাদনা করা access policy। আপনার VPS-এ এতে বেশি moving part যোগ হয়। তবে এমন সহকর্মীর কাছে কাজটি হস্তান্তর করা অনেক সহজ, যিনি কখনো terminal খুলবেন না। আপনি যদি Headscale-এর বদলে hosted Tailscale-এর সঙ্গে NetBird তুলনা করেন, তাহলে উভয়ই ভিতরে WireGuard ব্যবহার করে। তাই NetBird বনাম Tailscale তুলনা-এ প্রকৃত পার্থক্যগুলো ব্যাখ্যা করা হয়েছে: control plane কে চালায়, access rule কীভাবে লেখা হয় এবং relay কীভাবে traffic বহন করে।

আপনি যদি ইতিমধ্যে Tailscale client ব্যবহার করে থাকেন বা সবচেয়ে ছোট control plane চান, তাহলে Headscale চালান। একাধিক ব্যক্তির peer পরিচালনার প্রয়োজন হলে এবং নিজে তৈরি না করে console ও SSO চাইলে NetBird চালান। যেকোনো একটি বেছে নেওয়ার আগে Tailscale free plan-এ আসলে কী অন্তর্ভুক্ত আছে তা দেখুন। non-commercial group ছয়জন user-এর মধ্যে থাকলে hosted control plane-এর জন্য কোনো অর্থ দিতে হয় না; শুরুতেই unlimited user device এবং 50 tagged resource পাওয়া যায়। সেক্ষেত্রে নিজস্ব control plane চালানোর কোনো প্রয়োজন নাও থাকতে পারে। এই সীমা অতিক্রম করলে bill machine-এর সংখ্যার বদলে মানুষের সংখ্যার সঙ্গে বাড়ে। তাই আপনার group-এর জন্য Tailscale কত charge করবে তা হিসাব করুন। এতে VPS-এর খরচ এবং এই stack পরিচালনায় আপনার ব্যয় হওয়া সময়ের সঙ্গে তুলনা করার মতো একটি সংখ্যা পাবেন।

এই কাজটি চালাতে কত ছোট VPS যথেষ্ট?

নথিভুক্ত ন্যূনতম প্রয়োজন 1 CPU এবং 2 GB মেমরি। 2 GB-এর VPS নিন।

ছোট সার্ভারে তিনটি উপাদান বাদ রাখা নিরাপদ। NetBird Proxy service নির্বাচন করবেন না। এটি internal service-কে public hostname-এ প্রকাশ করার জন্য ব্যবহৃত হয় এবং peer-গুলোর সংযোগের সঙ্গে এর কোনো সম্পর্ক নেই। CrowdSec বাদ দিন। Script-টি এটি শুধু proxy-এর সঙ্গে প্রস্তাব করে। Exposed server-এ পরে এটি যোগ করা যুক্তিযুক্ত, কিন্তু প্রথম দিনেই নয়। netbird_data volume-এ থাকা default SQLite store ব্যবহার করুন। একাধিক মেশিনে deployment ভাগ করলে বা প্রকৃত concurrency-তে পৌঁছালে PostgreSQL-এ যান। নথি অনুযায়ী এটি পরে migration হিসেবে করা যায়।

Relay এমন একমাত্র component, যা বাদ দেওয়া যাবে না। দুইটি peer-এর NAT যদি প্রতিটি destination-এর জন্য আলাদা port নির্ধারণ করে, তারা কখনো direct tunnel স্থাপন করতে পারবে না। তাই relay-ই তাদের কাজ করানোর একমাত্র পথ। এটি disable করলে খুব সামান্য মেমরি সাশ্রয় হয়, কিন্তু এমনভাবে connection নষ্ট হয় যার কারণ শনাক্ত করা কঠিন।

একটি সার্ভার আর যথেষ্ট না হলে প্রথমে relay-গুলো সেই সার্ভার থেকে সরান। Standalone relay NB_LISTEN_ADDRESS, NB_EXPOSED_ADDRESS, NB_AUTH_SECRET এবং NB_ENABLE_STUN ব্যবহার করে চলে। Relay এবং main server-এ shared secret অভিন্ন হতে হবে। তা না হলে client-গুলো relay-এ authenticate করতে ব্যর্থ হবে।

ব্যর্থতার ধরন এবং আপনি যা দেখতে পাবেন

ড্যাশবোর্ডে certificate warning দেখায়। Traefik certificate সংগ্রহ করতে পারেনি। docker compose logs traefik | grep -i acme চালান। এর দুটি কারণ হতে পারে। হয় dig +short netbird.example.com এখনো এই VPS-এ resolve হচ্ছে না, অথবা Let's Encrypt এবং container-এর মধ্যবর্তী কোনো স্থানে TCP 443 বন্ধ। সাধারণত এটি ufw-এ নয়, provider-এর network firewall-এ বন্ধ থাকে। Challenge-এর উত্তর 443-এ দেওয়া হয়। তাই port 80 খোলা থাকলে এতে কোনো সাহায্য হয় না। Loop করে আবার চেষ্টা করার আগে কারণটি ঠিক করুন। কারণ Let's Encrypt প্রতি hostname, account এবং ঘণ্টায় সর্বোচ্চ পাঁচটি ব্যর্থ authorization অনুমোদন করে। সীমা পূরণ হয়ে গেলে সেটি পুনরায় পূরণ না হওয়া পর্যন্ত আপনি আর চেষ্টা করতে পারবেন না।

Client বলছে এটি connected, কিন্তু dashboard ফাঁকা। --management-url অনুপস্থিত থাকায় client NetBird-এর hosted service-এ register করেছে। netbird status --detail চালিয়ে Management: line পড়ুন। এতে client আসলে কোন server-এর সঙ্গে যোগাযোগ করছে তা দেখা যায়। 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 type-ও দেখায়। এতে প্রচেষ্টা কতদূর এগিয়েছে তা বোঝা যায়। কিছু network-এ relayed-ই একমাত্র সম্ভব ফলাফল। সে ক্ষেত্রে কোনো সমস্যা নেই।

একটি peer যোগ দেয়, কিন্তু কোনো কিছুর সঙ্গে যোগাযোগ করতে পারে না। Mesh-এ থাকা মানেই দুই peer পরস্পরের সঙ্গে কথা বলতে পারবে না। এটি access policy নির্ধারণ করে। কোনো group-এর সঙ্গে policy যুক্ত না থাকলে সেটি কোনো কিছুতেই পৌঁছাতে পারে না। Route ও firewall debug শুরু করার আগে dashboard-এ policy পরীক্ষা করুন।

netbird status daemon-সংক্রান্ত সমস্যা দেখায়। Service চলমান নয়। sudo netbird service status এবং sudo netbird service start ব্যবহার করুন। Client log রয়েছে /var/log/netbird/client.log-এ। কোনো বিষয়ের অবস্থান নির্ধারণ করতে না পারলে netbird debug bundle --anonymize --system-info চালান। এটি log, status, route, DNS setting এবং firewall state একত্র করে একটি archive তৈরি করে।

ব্যাকআপ এবং আপগ্রেড

পুরো ইন্সটলেশনটি দুটি জিনিসের ওপর নির্ভর করে: যে ডিরেক্টরিতে docker-compose.yml এবং config.yaml থাকে, এবং যে Docker volume-এ ডাটাবেস ও এনক্রিপশন কি (keys) সংরক্ষিত থাকে। এই দুটি একসাথে ব্যাকআপ নিন। 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

self-hosted NetBird চালাতে কি আমার নিজস্ব identity provider প্রয়োজন?

না। বর্তমান releases-এ built-in user store রয়েছে। তাই https://netbird.example.com-এ browser খুলে প্রথম admin account তৈরি করতে পারবেন। এরপর dashboard থেকে user যোগ করুন। External OIDC provider ঐচ্ছিক। পরে এটি যোগ করতে name, client ID, client secret এবং issuer—এই 4টি value লাগে। NetBird-এর আগে Zitadel বা Keycloak deploy করতে বলে এমন guide এখন আর প্রয়োজনীয় নয়। সেগুলো অনুসরণ করলে চালানোর জন্য একটি অতিরিক্ত service যুক্ত হয়।

আমার সব peer-এ Connection type: Relayed দেখাচ্ছে কেন?

Direct connection তৈরি হচ্ছে না। তাই traffic আপনার VPS-এর relay-এর মধ্য দিয়ে যাচ্ছে। সাধারণত UDP 3478 blocked থাকলে এটি ঘটে। Peer-গুলো নিজেদের public address ও port শনাক্ত করতে এই STUN port ব্যবহার করে। VPS-এর firewall এবং provider-এর আলাদা network firewall—উভয় জায়গায় port-টি খুলুন। এরপর আবার netbird status --detail চালান এবং Direct: line পড়ুন। উভয় peer এমন NAT-এর পেছনে থাকলে, যা প্রতিটি destination-এর জন্য আলাদা port বরাদ্দ করে, তাহলে relayed প্রত্যাশিত ফলাফল। এ ক্ষেত্রে configuration-এ কোনো ভুল নেই।

আমার client connected, কিন্তু dashboard-এ কোনো peer দেখা যাচ্ছে না। কী ঘটেছে?

Client আপনার server-এর পরিবর্তে NetBird-এর hosted service-এ register করেছে। --management-url বাদ থাকলে এমনটি ঘটে। netbird status --detail যে server-এর সঙ্গে client কথা বলছে, সেটি 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 দিয়ে পরিচালনা করেন। এর কোনো official web console নেই। এটি official Tailscale client পরিচালনা করে। NetBird একই stack-এর মধ্যে নিজস্ব client, একটি admin dashboard এবং identity provider integration দেয়। Headscale চালানোর জন্য ছোট এবং file-এ state সংরক্ষণ করে। যারা terminal ব্যবহার করবেন না, তাদের জন্য NetBird পরিচালনা করা সহজ।

self-hosted NetBird server-এর জন্য কী আকারের VPS প্রয়োজন?

Documented minimum হলো 1 CPU এবং 2 GB memory। তাই কিনতে হবে 2 GB-এর plan। Install-এর সময় optional proxy service প্রত্যাখ্যান করুন। এতে CrowdSec prompt-ও বাদ যাবে। সত্যিই PostgreSQL প্রয়োজন না হওয়া পর্যন্ত default SQLite store ব্যবহার করুন।