SSD Nodes Learn Hosting plans →
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-28

নিজের VPS-এ Tailscale চালাতে headscale সেটআপ

নিজের VPS-এ Tailscale control server চালান। Official .deb দিয়ে headscale ইনস্টল করে startup-এর আগে server_url সেট করুন, তারপর প্রথম node-এ join করুন।

Verified Every command ran end-to-end on a fresh Ubuntu 24.04 server, July 30, 2026.

headscale কী

headscale হলো Tailscale control server-এর একটি self-hosted implementation। তাই আপনার private network সমন্বয়কারী machineটি আপনার মালিকানাধীন একটি VPS। এটি একটি community project এবং Tailscale Inc. এটি পরিচালনা করে না। প্রতিটি machine-এ official tailscale client-ই চলে। একটি flag, --login-server ব্যবহার করে client-টিকে আপনার server-এ নির্দেশ করা হয়।

Control server জানে কারা network-এর অন্তর্ভুক্ত। এটি 100.64.0.0/10 থেকে প্রতিটি node-কে একটি address দেয়, public key বিতরণ করে এবং node-গুলোকে জানায় তারা একে অপরকে কোথায় খুঁজে পাবে। Tunnel-গুলো WireGuard-ই থাকে এবং node-to-node তৈরি হয়। আপনার দুটি machine-এর মধ্যে traffic headscale box-এর মধ্য দিয়ে যায় না, যদি না সরাসরি path তৈরি করা সম্ভব না হয় এবং node-গুলো relay ব্যবহার করে। এই coordination role নিজে চালালে roleটি কে ধরে রাখে তা বদলায়, কিন্তু এটি কী করতে পারে তা বদলায় না। তাই এই পরিবর্তনকে নিজে থেকেই security improvement ধরে নেওয়ার আগে এই model-এ control server কোন জায়গায় পৌঁছাতে পারে এবং পারে না তা বোঝা দরকার।

প্রতিটি headscale instance একটি tailnet (একটি Tailscale network) পরিচালনা করে। Project-টি এটিকে ব্যক্তিগত ব্যবহার বা ছোট organisation-এর জন্য উপযোগী বলে বর্ণনা করে। তিন বা চারটি machine থাকলে আপনার মালিকানাধীন VPS-এ একটি সাধারণ WireGuard VPN চালানোতে কম software পরিচালনা করতে হয় এবং নষ্ট হওয়ার সম্ভাবনাও কম থাকে। প্রতিটি নতুন laptop-এর জন্য হাতে একটি [Peer] block লিখতে না চাইলে headscale বেশি উপকারী হয়। খরচের কারণে মানুষ সাধারণত প্রথমে বিকল্প খোঁজে। তাই server নেওয়ার আগে hosted free plan-এ আসলে কী কী অন্তর্ভুক্ত তা পড়ে নেওয়া ভালো, কারণ অল্প কয়েকটি ব্যক্তিগত machine সাধারণত এর সীমার মধ্যে থাকে। আপনি যদি ইতিমধ্যে সেই সীমা অতিক্রম করে থাকেন, তাহলে paid plan-এর খরচ কত, যা device নয় বরং user-প্রতি নির্ধারিত তার সঙ্গে হিসাব মিলিয়ে দেখুন। কারণ একটি account ব্যবহারকারী একটি household-এ device-এর সংখ্যা গুরুত্বপূর্ণ হওয়া বন্ধ করার পরও খরচ কম থাকতে পারে। আপনি যদি self-hosted control plane চান, কিন্তু Tailscale-এর drop-in replacement-এর বদলে নিজের client এবং peer পরিচালনার জন্য web interface চান, তাহলে একটি single VPS-এ NetBird বিবেচনা করার মতো বিকল্প। দুটি model-এর বিস্তৃত তুলনার জন্য দেখুন WireGuard এবং Tailscale-এর পার্থক্য।

ইনস্টল করার আগে যা প্রয়োজন

  • public IPv4 address এবং sudo access-সহ Ubuntu 24.04 চালিত একটি VPS। সার্ভারটি নতুন হলে আগে নতুন VPS-এ প্রথম দশ মিনিট নির্দেশিকা অনুসরণ করুন।
  • ওই address-এ নির্দেশ করা একটি DNS A record। এই নির্দেশিকায় headscale.example.com ব্যবহার করা হয়েছে।
  • MagicDNS-এর জন্য একটি দ্বিতীয় domain বা subdomain। এই নির্দেশিকায় tailnet.example.net ব্যবহার করা হয়েছে। এটি server_url-এ থাকা domain-এর মতো একই হতে পারবে না।
  • যোগ দেওয়ার জন্য Linux, macOS, Windows, Android অথবা iOS চালিত একটি client machine।

অফিশিয়াল .deb থেকে headscale ইনস্টল করুন

প্রকল্পটি GitHub releases page-এ .deb প্যাকেজ প্রকাশ করে। July 2026 অনুযায়ী বর্তমান release হলো 0.29.3। প্রথমে আপনার architecture পরীক্ষা করুন, কারণ file name-এ architecture উল্লেখ থাকে।

sudo apt update
sudo apt install -y wget
dpkg --print-architecture

সাধারণ x86 VPS-এ এটি amd64 এবং Ampere বা Graviton ধরনের plan-এ arm64 দেখায়। নিচের variable-এ উত্তরটি রাখুন।

HEADSCALE_VERSION="0.29.3"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \\
  "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install -y ./headscale.deb
headscale version

file name-এর আগে ./ থাকা আবশ্যক। এটি না থাকলে apt আপনার repositories-এ headscale.deb নামের package খোঁজে এবং ব্যর্থ হয়।

প্যাকেজটি একটি headscale system user তৈরি করে, একটি default /etc/headscale/config.yaml লেখে এবং একটি systemd unit ইনস্টল করে। এটি service শুরু করে না, এবং এটিই সঠিক ক্রম। সরবরাহ করা configuration server_url-কে http://127.0.0.1:8080-এর দিকে নির্দেশ করে। এটি এমন কোনো address নয় যেখানে আপনার কোনো client পৌঁছাতে পারে। তাই এখন service শুরু করলে service চালু হলেও configuration ভুল হবে। এই পর্যায়ে sudo systemctl is-active headscale চালালে inactive দেখায়। এটি প্রত্যাশিত আচরণ, কোনো ত্রুটি নয়।

service চালু করার আগে server_url কনফিগার করুন

/etc/headscale/config.yaml-এ sudo nano /etc/headscale/config.yaml ব্যবহার করে সম্পাদনা করুন, অথবা sed দিয়ে একই তিনটি পরিবর্তন প্রয়োগ করুন। মূল ফাইলটির একটি কপি সংরক্ষণ করুন। ফাইলটি দীর্ঘ এবং এতে অনেক মন্তব্য আছে, তাই বাকি সেটিংস বোঝার জন্য এটিই আপনার সবচেয়ে ভালো রেফারেন্স।

sudo cp /etc/headscale/config.yaml /etc/headscale/config.yaml.orig
sudo sed -i 's|^server_url:.*|server_url: https://headscale.example.com|' /etc/headscale/config.yaml
sudo sed -i 's|^listen_addr:.*|listen_addr: 127.0.0.1:8080|' /etc/headscale/config.yaml
sudo sed -i 's|^  base_domain:.*|  base_domain: tailnet.example.net|' /etc/headscale/config.yaml
sudo grep -E '^(server_url|listen_addr):|^  base_domain:' /etc/headscale/config.yaml

server_url হলো সেই ঠিকানা যা headscale প্রতিটি client registration-এ লিখে দেয়। এরপর client-গুলো সবসময় ওই নির্দিষ্ট string-এ সংযোগ করবে। তাই এখানে https://-সহ public name দিতে হবে; কখনোই 127.0.0.1 ব্যবহার করবেন না।

listen_addr নির্ধারণ করে process কোথায় bind করবে। এটি loopback-এ রাখুন। একই server-এর reverse proxy TLS (transport layer security) termination করে এবং অনুরোধ এখানে forward করে। তাই server-এর বাইরে থেকে port 8080-এ পৌঁছানোর প্রয়োজন নেই।

base_domain হলো MagicDNS suffix, যার অধীনে আপনার node-গুলো নাম পাবে। এটি trailing dot ছাড়া একটি fully qualified domain name হতে হবে। server_url-এ ব্যবহৃত domain থেকে এটি আলাদা হতে হবে, কারণ একই হলে দুইটি name space পরস্পরের সঙ্গে সংঘর্ষে জড়াবে।

Database section অপরিবর্তিত রাখুন। ডিফল্ট হিসেবে /var/lib/headscale/db.sqlite-এ SQLite ব্যবহৃত হয়। এটি package দ্বারা তৈরি ও মালিকানাধীন একটি directory-তে থাকে, এবং এই আকারের tailnet-এর জন্য SQLite যথেষ্ট।

headscale চালু করুন এবং এটি চলছে তা নিশ্চিত করুন

sudo systemctl enable --now headscale
sudo systemctl is-active headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/health

is-active active দেখায় এবং curl 200 দেখায়। enable --now কাজটির উভয় অংশ সম্পন্ন করে: এটি service চালু করে এবং reboot-এর পরে চালু হওয়ার জন্য সেট করে।

is-active যদি failed দেখায়, তাহলে sudo journalctl -u headscale -n 50 --no-pager দিয়ে journal পড়ুন। এই পর্যায়ে ব্যর্থতার কারণ প্রায় সব সময় configuration file, কারণ headscale socket খোলার আগে পুরো file parse করে। তাই indentation ভুল হলে বা অজানা key থাকলে কোনো কিছু port-এ listen করার আগেই process বন্ধ হয়ে যায়। File ঠিক করে তারপর sudo systemctl restart headscale চালান। পরবর্তী প্রতিটি configuration পরিবর্তনের পরও একইভাবে restart করতে হবে। এরপর client-গুলো নিজে থেকেই আবার সংযোগ করবে। systemd unit আপনার কাছে নতুন হলে, systemd দিয়ে নিজের service ও timer চালানো এই অংশে ব্যবহৃত command-গুলো ব্যাখ্যা করা হয়েছে।

Shell-এ থাকা অবস্থায় state file-গুলো পরীক্ষা করুন:

stat -c '%U %n' /var/lib/headscale/db.sqlite /var/lib/headscale/noise_private.key

উভয় line-ই headscale দিয়ে শুরু হয়। এটি package তৈরি করা unprivileged user। noise_private.key হলো client-গুলোর কাছে server-এর পরিচয়। এটি সংরক্ষণ করুন। এটি মুছে ফেললে headscale নতুন একটি তৈরি করবে এবং প্রতিটি node-কে আবার register করতে হবে।

headscale-এর সামনে TLS বসান

ক্লায়েন্টদের অবশ্যই HTTPS-এর মাধ্যমে server_url-এ পৌঁছাতে হবে। Caddy সবচেয়ে সংক্ষিপ্ত পথ, কারণ এটি নিজেই certificate চেয়ে নেয় এবং renewal করে।

sudo apt install -y caddy

/etc/caddy/Caddyfile-এর জায়গায় headscale documentation-এর block বসান:

headscale.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up True-Client-IP {remote_host}
        header_up X-Real-IP {remote_host}
    }
}
sudo caddy validate --adapter caddyfile --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl is-active caddy

ফাইলটি parse হলে validate, adapted config to JSON দেখায়। ফাইলটি formatted নয়—এমন warning শুধু cosmetic। আপনার laptop থেকে curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health চালালেও 200 দেখানো উচিত। এই একটিমাত্র check প্রমাণ করে যে DNS, firewall, certificate এবং proxy একসঙ্গে সঠিকভাবে কাজ করছে।

Proxy-এর যে বিষয়টি অনেকের এক সন্ধ্যা নষ্ট করে, তা হলো: Tailscale control connection একটি HTTP upgrade। এটি GET-এর পরিবর্তে POST দিয়ে শুরু হয়, এবং Upgrade header-এর মান হলো tailscale-control-protocol। Caddy কোনো অতিরিক্ত configuration ছাড়াই এটি pass through করে। nginx তা করে না। তাই nginx front end-এ upgrade map প্রয়োজন:

map $http_upgrade $connection_upgrade {
    default keep-alive;
    ''      close;
}

server {
    listen 443 ssl;
    server_name headscale.example.com;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        proxy_pass http://127.0.0.1:8080;
    }
}

এই লাইনগুলো বাদ দিলে সাধারণ request সফল হয়। তাই /health 200 ফেরত দেয় এবং সবকিছু ঠিকঠাক মনে হয়। কিন্তু দীর্ঘস্থায়ী control connection তৈরি হয় না। ফলে আপনার node-গুলো register হওয়ার পর offline অবস্থায় থাকে। nginx ব্যবহার করলে certificate অংশের জন্য Ubuntu 24.04-এ nginx সহ Certbot দেখুন।

UFW-তে কোন port খুলবেন

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Port 443-এ সব client-এর সংযোগ চলাচল করে। Port 80 শুধু ACME (স্বয়ংক্রিয় certificate management environment) HTTP challenge এবং HTTPS-এ redirect করার জন্য ব্যবহৃত হয়। Caddy-এর certificate পাওয়ার জন্যও এটি প্রয়োজন।

Port 8080 বন্ধ থাকে। listen_addr হলো 127.0.0.1:8080, তাই proxy loopback interface-এর মাধ্যমে headscale-এ পৌঁছায় এবং কোনো firewall rule প্রয়োজন হয় না। Internet-এর জন্য 8080 খুললে client-দের একটি cleartext control channel দেওয়া হয়, কিন্তু এতে কোনো সুবিধা পাওয়া যায় না। মনে রাখবেন, অধিকাংশ provider তাদের control panel-এ UFW থেকে আলাদা একটি দ্বিতীয় firewall চালায়। তাই server-এ কোনো port খোলা থাকলেও edge-এ সেটি বন্ধ থাকতে পারে। VPS-এ UFW firewall-এর মৌলিক বিষয়-এ rule syntax আরও বিস্তারিতভাবে দেখানো হয়েছে।

একটি ব্যবহারকারী এবং একটি preauth key তৈরি করুন

sudo headscale users create alice
sudo headscale users list

headscale command একটি client। এটি /var/run/headscale/headscale.sock-এ থাকা unix socket-এর মাধ্যমে চলমান daemon-এর সঙ্গে যোগাযোগ করে। এই socket-এর mode 0770 এবং এটি headscale group-এর মালিকানাধীন। এর দুটি ফল আছে। service বন্ধ থাকলে command ব্যর্থ হবে; এই কারণেও এই guide-এ কাজের ক্রম গুরুত্বপূর্ণ। এছাড়া headscale group-এ নিজের account যোগ না করলে command চালাতে sudo প্রয়োজন হবে।

users list প্রতিটি নামের পাশে একটি ID দেখায়। আপনার ওই number প্রয়োজন, কারণ key command নাম নয়, numeric user ID গ্রহণ করে।

sudo headscale preauthkeys create --user 1 --expiration 24h

key একবারই print হয়। এখনই এটি copy করুন। আপনি অন্যভাবে না বললে একটি preauth key একবার ব্যবহারযোগ্য এবং এক ঘণ্টা valid থাকে। তাই আপনি এখনও testing করার সময় --expiration 24h সেট করা উপযোগী। একাধিক machine enroll করতে পারে এমন key-এর জন্য --reusable যোগ করুন। এটিকে password-এর মতো সুরক্ষিত রাখুন, কারণ যার কাছে এটি থাকবে সে আপনার network-এ join করতে পারবে।

--login-server ব্যবহার করে প্রথম client সংযুক্ত করুন

আপনি যে machine-টি যুক্ত করতে চান, সেখানে:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com --auth-key 'hskey-auth-PASTE-YOUR-KEY-HERE'
tailscale status
tailscale ip -4

tailscale ip -4 headscale যে address বরাদ্দ করেছে, সেটি দেখায়। এটি 100.64.0.1-এর মতো হতে পারে। Server-এ ফিরে sudo headscale nodes list চালালে node-টির ID, user এবং online state দেখা যায়।

--login-server-এর value-টি server_url-এর সঙ্গে হুবহু মিলতে হবে। এর মধ্যে scheme থাকতে হবে এবং শেষে কোনো slash থাকা যাবে না। এগুলো string হিসেবে তুলনা করা হয়। অমিল হলে client একটি address-এর বিরুদ্ধে register করে এবং পরে অন্য address-এর সঙ্গে যোগাযোগ করতে বলা হয়।

যে machine-এ আগে Tailscale-এর hosted service-এ sign in করা হয়েছিল, সেটি সেই login ধরে রাখে। প্রথমে সেখানে sudo tailscale logout চালান। এরপর --login-server সহ tailscale up চালান।

--auth-key বাদ দিলে client একটি URL দেখায়। URL-টি খুললে সেই registration attempt-এর identifier দেখা যায়। Server-এ সেটি approve করুন:

sudo headscale auth register --user alice --auth-id PASTE-THE-ID-FROM-THE-PAGE

নিজের laptop-এর জন্য এই পদ্ধতিটি সুবিধাজনক। Script-এ ব্যবহার করার জন্য preauth key বেশি উপযোগী, কারণ তখন কোনো মানুষের উপস্থিত থেকে নজর রাখার প্রয়োজন হয় না। VPS নিজেই একটি node হওয়ার পরে আপনার অন্য machine-গুলোর Internet traffic-ও এর মাধ্যমে পাঠাতে পারে। এটিই exit node সেটআপ। পার্থক্য হলো, hosted admin console-এ নয়, server-এ headscale command ব্যবহার করে advertised route approve করতে হবে। যদি আপনার উদ্দেশ্য Internet-এ বের হওয়া না হয়ে VPS-এর পেছনে থাকা private network-এ পৌঁছানো হয়, একই approval ধাপে আপনার tailnet-এর বাকি অংশে সেই subnet advertise করা যায়। কোনো node থেকে সম্পূর্ণ network route না করে শুধু একটি application প্রকাশ করা আলাদা কাজ। এটি করার দুটি উপায় হলো serve এবং funnel। তবে উভয়ই Tailscale-এর নিজস্ব certificate এবং ingress machinery-এর ওপর নির্ভর করে। তাই এগুলোকে headscale-এর দেওয়া সুবিধা নয়, hosted-tailnet feature হিসেবে বিবেচনা করুন।

DERP এবং সরাসরি পথ ব্যর্থ হলে যে relay network traffic পাঠায়

DERP (designated encrypted relay for packets) হলো fallback path। দুটি node সরাসরি WireGuard connection তৈরি করতে না পারলে, সাধারণত উভয়ই strict NAT (network address translation)-এর পেছনে থাকায়, তারা relay-এর মাধ্যমে packet পাঠায়। relay-এর কাছে কোনো key থাকে না। তাই এটি আপনার traffic পড়তে পারে না। তবে কোন node কোন node-এর সঙ্গে যোগাযোগ করছে এবং কত data আদান-প্রদান হচ্ছে, তা relay দেখতে পারে।

Default configuration কী করে, তা পরিষ্কারভাবে বুঝে নিন। Headscale https://controlplane.tailscale.com/derpmap/default-এর দিকে auto_update_enabled: true এবং update_frequency: 3h-সহ configured অবস্থায় ship করে। তাই আপনার control plane আপনার নিজের থাকে, কিন্তু relay থাকে Tailscale-এর। অধিকাংশ ব্যবহারকারীর জন্য এটি যুক্তিসংগত সমঝোতা। আপনার ক্ষেত্রে তা গ্রহণযোগ্য না হলে নিজস্ব relay চালান।

নিজস্ব relay চালাতে config.yaml-এর মধ্যে derp.server-এর অধীনে enabled: true সেট করুন, headscale restart করুন এবং sudo ufw allow 3478/udp দিয়ে STUN (session traversal utilities for NAT) port খুলুন। Configuration file-এ requirement-টি স্পষ্টভাবে লেখা আছে: server_url-এ https ব্যবহার করতে হবে, কারণ DERP-এর জন্য TLS প্রয়োজন। derp.urls list খালি করলে map থেকে Tailscale-এর relay-গুলো সরিয়ে দেওয়া হয়। কাজের embedded relay ছাড়া এটি করলে, যেসব node pair সরাসরি connect করতে পারে না, তারা একেবারেই connect করতে পারবে না।

একটি client থেকে tailscale netcheck এটি জানা প্রতিটি relay region-এ latency দেখায়, আর tailscale status প্রতিটি peer-কে direct হিসেবে address-সহ অথবা relay হিসেবে region code-সহ চিহ্নিত করে। কোনো peer relay অবস্থায় আটকে থাকলে সেটি NAT সমস্যা, headscale সমস্যা নয়। কোনো peer direct অবস্থায় থেকেও ধীর হলে সেটি আবার ভিন্ন বিষয়, এবং সাধারণত এর কারণ tunnel নিজে নয়, বরং MTU।

নোড offline হিসেবে দেখায় কেন?

Proxy upgrade request বাদ দিচ্ছে। এটি সবচেয়ে সাধারণ কারণ। এর লক্ষণ হলো, অন্য সবকিছু স্বাভাবিক দেখা যায়: /health 200 ফেরত দেয়, headscale nodes list নোড দেখায়, কিন্তু নোড কখনো online হয় না। Control connection হলো Upgrade: tailscale-control-protocol বহনকারী একটি POST request। Proxy এটি forward না করলে node state জানানোর একমাত্র channel বন্ধ হয়ে যায়। উপরের map block-এর সঙ্গে আপনার nginx configuration তুলনা করুন। অথবা proxy-কে কারণ হিসেবে বাদ দিতে Caddy ব্যবহার করুন।

নোডগুলো register হওয়ার পরে server_url পরিবর্তন করা হয়েছে। নোডগুলো registration-এর সময় দেওয়া value-তেই বারবার connection করার চেষ্টা করে। এটি পরিবর্তন করলে প্রতিটি নোডে sudo tailscale up --login-server https://headscale.example.com --force-reauth চালান।

Client চলছে না। নোডে sudo systemctl is-active tailscaled এবং sudo journalctl -u tailscaled -n 50 --no-pager চালান। Client আপনার domain resolve করতে বা সেখানে পৌঁছাতে না পারলে তার retry-এর log সেখানে দেখা যাবে।

Key-এর মেয়াদ শেষ হয়েছে। পরের section-এ এটি ব্যাখ্যা করা হয়েছে।

পরীক্ষা করার সময় server side monitor করতে VPS-এ sudo journalctl -u headscale -f চালান এবং client-এ tailscaled restart করুন। কোনো নোড headscale-এ পৌঁছালে সঙ্গে সঙ্গে log line তৈরি হয়। কোনো log না থাকলে request server-এ পৌঁছাচ্ছে না। তাই headscale পরীক্ষা করার আগে DNS, firewall এবং proxy পরীক্ষা করুন।

Key-এর মেয়াদ শেষ হওয়া এবং কয়েক সপ্তাহ পর কাজ বন্ধ করে দেওয়া node

এখানে দুটি পৃথক মেয়াদ শেষ হওয়ার বিষয় আছে। এগুলো গুলিয়ে ফেললে অযথা সময় নষ্ট হয়।

Preauth key পরিকল্পনা অনুযায়ী দ্রুত মেয়াদোত্তীর্ণ হয়। ডিফল্ট হলো এক ঘণ্টা এবং একবার ব্যবহার। tailscale up key প্রত্যাখ্যান করলে client-এ কিছু সম্পাদনা না করে server-এ নতুন key তৈরি করুন।

Node key হলো দীর্ঘমেয়াদি অংশ। config.yaml-এর node section-এ expiry: 0 নির্ধারিত হয়, এবং 0-এর অর্থ হলো কোনো ডিফল্ট মেয়াদ শেষ হওয়ার সময় নেই: আপনি মেয়াদ শেষ না করা পর্যন্ত নিবন্ধিত node বৈধ থাকে। Tagged node কখনো মেয়াদোত্তীর্ণ হয় না। Registration-এর মেয়াদ শেষ করাতে চাইলে expiry: 180d নির্ধারণ করুন। তবে এর প্রভাব বুঝে নিন: এরপর প্রতিটি non-tagged node-কে সেই সময়সূচি অনুযায়ী sudo tailscale up --login-server https://headscale.example.com --force-reauth করতে হবে, এবং যে headless server-এ কেউ পুনরায় authentication করে না, সেটি নিজে থেকেই network থেকে বিচ্ছিন্ন হয়ে যাবে।

কেউ laptop হারালে এটি হাতে করে করুন। sudo headscale nodes list আপনাকে ID দেবে। এরপর sudo headscale nodes expire -i 3 ওই node-কে logout করাবে, এবং sudo headscale nodes delete -i 3 node-টিকে সম্পূর্ণভাবে network থেকে সরিয়ে দেবে।

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

/var/lib/headscale এবং /etc/headscale মিলেই সম্পূর্ণ সার্ভারটি গঠন করে। এগুলো কপি করার আগে service বন্ধ করুন, কারণ SQLite-এ লেখার কাজ চলমান থাকতে পারে এবং load-এর মধ্যে কপি করা database অসামঞ্জস্যপূর্ণ হতে পারে।

sudo systemctl stop headscale
sudo tar czf /root/headscale-state.tgz -C /var/lib headscale
sudo tar czf /root/headscale-config.tgz -C /etc headscale
sudo systemctl start headscale
sudo chmod 600 /root/headscale-*.tgz

দুটি file-ই সার্ভারের বাইরে সরিয়ে রাখুন। এগুলোতে private key এবং সব registration থাকে, তাই সার্ভারের মতোই এগুলোর নিরাপত্তার যত্ন নিতে হবে। VPS থেকে restic backup-এ নির্ধারিত সময়সূচি অনুযায়ী এবং encrypted অবস্থায় এটি করার পদ্ধতি দেখানো হয়েছে।

আপগ্রেডের ধাপও install-এর মতোই: নতুন .deb, sudo apt install ./headscale.deb download করুন, তারপর restart করে is-active এবং /health check আবার চালান। 0.29 থেকে upgrade path কঠোর। একটি minor version বাদ দিয়ে আপগ্রেড করা যাবে না। পুরোনো minor version-এ downgrade করাও নিষিদ্ধ। প্রতিবার এক minor version করে এগোন। প্রতিটি ধাপের আগে backup নিন। আগে সেই version-এর release notes পড়ুন, কারণ একই release-এ ACL policy-এর আচরণ পরিবর্তিত হয়েছে এবং বেশ কয়েকটি configuration key সরানো হয়েছে।

FAQ

headscale ইনস্টল করার পরপরই start হতে ব্যর্থ হয় কেন?

Package unit ইনস্টল করে, কিন্তু service-টি stopped অবস্থায় রাখে। Default /etc/headscale/config.yaml একটি template, কার্যকর configuration নয়। প্রথমে server_url, listen_addr এবং base_domain সম্পাদনা করুন। এরপর sudo systemctl enable --now headscale চালিয়ে sudo systemctl is-active headscale দিয়ে নিশ্চিত করুন। তারপরও ব্যর্থ হলে sudo journalctl -u headscale -n 50 --no-pager সমস্যাটি শনাক্ত করবে। এই পর্যায়ে সমস্যা প্রায় সবসময় YAML error হয়, কারণ headscale কোনো port-এ bind করার আগে পুরো file parse করে।

আমার মেশিনগুলোতে কি এখনও সাধারণ Tailscale client ইনস্টল করতে হবে?

হ্যাঁ। Headscale শুধু control server প্রতিস্থাপন করে। প্রতিটি node-এ Tailscale-এর official client চলে। sudo tailscale up --login-server https://headscale.example.com ব্যবহার করে client-টিকে আপনার server-এর দিকে নির্দেশ করুন। এই flag standard client-এ রয়েছে। তাই কোনো patch বা rebuild প্রয়োজন নেই।

আমার traffic কি headscale server-এর মধ্য দিয়ে যায়?

সাধারণত যায় না। Headscale network সমন্বয় করে এবং key ও address বিতরণ করে। Data path থাকে আপনার node-গুলোর মধ্যে সরাসরি WireGuard সংযোগে। দুটি node সরাসরি একে অপরের কাছে পৌঁছাতে না পারলে traffic শুধু তখনই ঘুরে যায় এবং DERP relay ব্যবহার করে। Shipped configuration-এ ওই relay-গুলো Tailscale-এর public relay। কোনো node-এ tailscale status চালিয়ে নির্দিষ্ট peer direct অবস্থায় আছে, নাকি relay-এ রয়েছে, তা দেখুন।

register করার পরও আমার node offline থাকে কেন?

headscale nodes list-এ দেখা গেলেও কোনো node online না হলে সাধারণত reverse proxy-তে তার control connection বিচ্ছিন্ন হয়েছে। এই connection-টি Upgrade: tailscale-control-protocol header-সহ পাঠানো একটি HTTP upgrade request। আপনি map $http_upgrade $connection_upgrade block এবং এর সঙ্গে মেলা proxy_set_header line যোগ না করলে nginx এটি বাদ দেয়। Caddy কোনো অতিরিক্ত configuration ছাড়াই এটি forward করে। তাই proxy-টি সমস্যার কারণ কি না, তা দ্রুত পরীক্ষা করার জন্য Caddy ব্যবহার করা যায়।

headscale-এর জন্য কি domain name এবং TLS প্রয়োজন?

বাস্তবে, হ্যাঁ। Client-গুলো server_url-এ দেওয়া string-এ সংযোগ করে। Certificate name-এর জন্য issue করা হয়, সরাসরি IP address-এর জন্য নয়। Configuration file-এও বলা আছে যে DERP-এর জন্য TLS প্রয়োজন। একটি domain এবং Caddy ব্যবহার করলে প্রায় পাঁচ মিনিটে স্বয়ংক্রিয় renewal-সহ একটি HTTPS endpoint পাওয়া যায়। Control server plain HTTP-তে চালালে প্রতিটি client conversation Internet-এর মধ্য দিয়ে unencrypted অবস্থায় যায়।

#headscale#tailscale#wireguard#vpn#self-hosting