Headscale দিয়ে নিজের Tailscale সার্ভার সেটআপ করার নিয়ম

headscale কী

headscale হলো Tailscale কন্ট্রোল সার্ভারের একটি সেলফ-হোস্টেড ইমপ্লিমেন্টেশন, তাই আপনার প্রাইভেট নেটওয়ার্ক সমন্বয়কারী মেশিনটি আপনার নিজস্ব একটি VPS। এটি একটি কমিউনিটি প্রজেক্ট এবং এটি Tailscale Inc. দ্বারা পরিচালিত হয় না। প্রতিটি মেশিন এখনও অফিসিয়াল tailscale ক্লায়েন্ট চালায়, যা একটি ফ্ল্যাগ --login-server ব্যবহার করে আপনার সার্ভারের দিকে নির্দেশ করা থাকে।

কন্ট্রোল সার্ভার হলো সেই অংশ যা জানে নেটওয়ার্কে কারা অন্তর্ভুক্ত। এটি প্রতিটি নোডকে 100.64.0.0/10 থেকে একটি অ্যাড্রেস প্রদান করে, পাবলিক কি বিতরণ করে এবং নোডগুলোকে একে অপরের অবস্থান জানায়। টানেলগুলো WireGuard-এই থাকে, যা নোড থেকে নোডে তৈরি হয়। আপনার দুটি মেশিনের মধ্যকার ট্রাফিক headscale বক্সের মধ্য দিয়ে যায় না, যদি না সরাসরি কোনো পাথ তৈরি করা সম্ভব হয় এবং নোডগুলো রিলে (relay) ব্যবহার করতে বাধ্য হয়।

headscale প্রতিটি ইনস্ট্যান্সে একটি tailnet (একটি Tailscale নেটওয়ার্ক) সাপোর্ট করে, যা প্রজেক্টটির বর্ণনা অনুযায়ী ব্যক্তিগত ব্যবহার বা ছোট প্রতিষ্ঠানের জন্য উপযুক্ত। তিন বা চারটি মেশিনের ক্ষেত্রে, আপনার নিজস্ব VPS-এ একটি সাধারণ WireGuard VPN চালানো সহজ এবং এতে ত্রুটির সম্ভাবনা কম। headscale তখন কার্যকর হয় যখন আপনি প্রতিটি নতুন ল্যাপটপের জন্য হাতে [Peer] ব্লক লিখতে চান না। এই দুটি মডেলের বিস্তারিত তুলনার জন্য দেখুন WireGuard এবং Tailscale-এর মধ্যে পার্থক্য।

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

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

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

প্রকল্পটি তাদের GitHub রিলিজ পেজে .deb প্যাকেজ প্রকাশ করে। জুলাই 2026 অনুযায়ী বর্তমান রিলিজ হলো 0.29.3। প্রথমে আপনার আর্কিটেকচার পরীক্ষা করুন, কারণ ফাইলের নামে এটি উল্লেখ থাকে।

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

এটি সাধারণ x86 VPS-এ amd64 এবং Ampere বা Graviton স্টাইলের প্ল্যানে arm64 প্রিন্ট করে। নিচের ভেরিয়েবলে উত্তরটি বসান।

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

ফাইলের নামের আগে ./ থাকা আবশ্যক। এটি ছাড়া, apt আপনার রিপোজিটরিতে headscale.deb নামের একটি প্যাকেজ খোঁজে এবং ব্যর্থ হয়।

প্যাকেজটি একটি headscale সিস্টেম ইউজার তৈরি করে, একটি ডিফল্ট /etc/headscale/config.yaml লেখে এবং একটি systemd ইউনিট ইনস্টল করে। এটি সার্ভিসটি চালু করে না, এবং এটিই সঠিক ক্রম। সরবরাহকৃত কনফিগারেশন server_url-কে http://127.0.0.1:8080-এর দিকে নির্দেশ করে, যা আপনার কোনো ক্লায়েন্টের পক্ষে পৌঁছানো সম্ভব নয়, তাই এখনই সার্ভিস চালু করা ভুল হবে, এমনকি যদি এটি চালুও হয়। এই পর্যায়ে sudo systemctl is-active headscale রান করলে inactive প্রিন্ট হয়। এটি প্রত্যাশিত, কোনো ত্রুটি নয়।

পরিষেবাটি শুরু করার আগে 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 প্রতিটি ক্লায়েন্ট নিবন্ধনের সময় লিখে রাখে। ক্লায়েন্টরা এরপর থেকে সবসময় সেই নির্দিষ্ট স্ট্রিংটিতেই ডায়াল করে, তাই এটি অবশ্যই https:// যুক্ত একটি পাবলিক নাম হতে হবে, কখনোই 127.0.0.1 নয়।

listen_addr হলো সেই জায়গা যেখানে প্রসেসটি বাইন্ড হয়। এটিকে লুপব্যাকে (loopback) থাকতে দিন। একই সার্ভারে থাকা একটি রিভার্স প্রক্সি TLS (transport layer security) টার্মিনেট করে এবং সেটিকে ফরোয়ার্ড করে, তাই সার্ভারের বাইরের কোনো কিছুরই port 8080-এ পৌঁছানোর প্রয়োজন নেই।

base_domain হলো MagicDNS সাফিক্স, যে ডোমেইনের অধীনে আপনার নোডগুলো নাম পায়। এটি অবশ্যই একটি সম্পূর্ণ কোয়ালিফাইড ডোমেইন নাম হতে হবে যার শেষে কোনো ডট থাকবে না, এবং এটি অবশ্যই server_url-এ থাকা ডোমেইন থেকে আলাদা হতে হবে, কারণ অন্যথায় দুটি নেম স্পেসের মধ্যে সংঘর্ষ ঘটবে।

ডেটাবেস সেকশনটি পরিবর্তন করবেন না। ডিফল্ট হিসেবে /var/lib/headscale/db.sqlite-এ SQLite ব্যবহার করা হয়, যা প্যাকেজটি তৈরির সময় তৈরি করা একটি ডিরেক্টরিতে থাকে এবং এই আকারের একটি টেলনেটের (tailnet) জন্য SQLite যথেষ্ট।

Start headscale and prove it is running

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 prints active and the curl prints 200. enable --now does both halves of the job: it starts the service and it marks it to start after a reboot.

If is-active prints failed, read the journal with sudo journalctl -u headscale -n 50 --no-pager. A failure at this stage is nearly always the configuration file, because headscale parses the whole file before it opens a socket, so a bad indent or an unknown key stops the process before anything listens. Fix the file, then sudo systemctl restart headscale. Every later configuration change needs that same restart. Clients reconnect on their own afterwards. If systemd units are new to you, running your own services and timers with systemd covers the commands used here.

Check the state files while you are in the shell:

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

Both lines start with headscale, the unprivileged user the package created. noise_private.key is the server's identity to its clients. Keep it. If you delete it, headscale generates a new one and every node has to register again.

headscale-এর সামনে TLS স্থাপন করা

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

sudo apt install -y caddy

/etc/caddy/Caddyfile-কে headscale ডকুমেন্টেশনের ব্লক দিয়ে প্রতিস্থাপন করুন:

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

ফাইলটি পার্স হলে validate, adapted config to JSON প্রিন্ট করে। ফাইলটি ফরম্যাট করা নেই এমন সতর্কতাটি কেবল প্রসাধনমূলক। আপনার ল্যাপটপ থেকে, curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health-ও 200 প্রিন্ট করবে। এই একটি পরীক্ষা প্রমাণ করে যে DNS, ফায়ারওয়াল, সার্টিফিকেট এবং প্রক্সি একসাথে কাজ করছে।

এখানে প্রক্সির সেই বিবরণটি দেওয়া হলো যা অনেকের সন্ধ্যা নষ্ট করে। Tailscale কন্ট্রোল কানেকশন হলো একটি HTTP আপগ্রেড, এটি GET-এর পরিবর্তে POST দিয়ে শুরু হয় এবং Upgrade হেডারের মান হলো tailscale-control-protocol। Caddy কোনো অতিরিক্ত কনফিগারেশন ছাড়াই এটি পাস করে। nginx তা করে না, তাই একটি nginx ফ্রন্ট এন্ডের জন্য আপগ্রেড ম্যাপ প্রয়োজন:

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;
    }
}

এই লাইনগুলো বাদ দিলে সাধারণ অনুরোধগুলো সফল হয়, যার কারণে /health 200 রিটার্ন করে এবং সবকিছু ঠিকঠাক দেখায়, কিন্তু দীর্ঘস্থায়ী কন্ট্রোল কানেকশন কখনোই তৈরি হয় না এবং আপনার নোডগুলো রেজিস্টার হওয়ার পর অফলাইন হয়ে থাকে। আপনি যদি nginx রুট ব্যবহার করেন, তবে Ubuntu 24.04-এ nginx সহ Certbot সার্টিফিকেটের অংশটি কভার করে।

UFW-তে কোন পোর্টগুলো খুলতে হবে

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

443 (443) পোর্ট প্রতিটি ক্লায়েন্ট কথোপকথন বহন করে। 80 (80) পোর্টটি শুধুমাত্র ACME (automatic certificate management environment) HTTP চ্যালেঞ্জ এবং HTTPS-এ রিডাইরেক্ট করার জন্য ব্যবহৃত হয়, এবং সার্টিফিকেট পাওয়ার জন্য Caddy-এর এটি প্রয়োজন।

8080 (8080) পোর্টটি বন্ধ রাখুন। listen_addr হলো 127.0.0.1:8080, তাই প্রক্সিটি লুপব্যাক ইন্টারফেসের মাধ্যমে headscale-এ পৌঁছায় এবং এতে কোনো ফায়ারওয়াল রুল জড়িত থাকে না। ইন্টারনেট থেকে 8080 (8080) পোর্টটি খুলে দিলে ক্লায়েন্টরা একটি প্লেইনটেক্সট কন্ট্রোল চ্যানেল পেয়ে যায়, যা কোনো উপকারে আসে না। মনে রাখবেন যে, বেশিরভাগ প্রোভাইডার UFW থেকে আলাদা তাদের কন্ট্রোল প্যানেলে একটি দ্বিতীয় ফায়ারওয়াল চালায়, তাই একটি পোর্ট সার্ভারে খোলা থাকলেও তা এজ-এ বন্ধ থাকতে পারে। VPS-এ UFW ফায়ারওয়ালের মৌলিক বিষয়সমূহ-এ রুল সিনট্যাক্স সম্পর্কে বিস্তারিত আলোচনা করা হয়েছে।

ব্যবহারকারী তৈরি এবং প্রি-অথ কী (preauth key)

sudo headscale users create alice
sudo headscale users list

headscale কমান্ডটি একটি ক্লায়েন্ট। এটি /var/run/headscale/headscale.sock-এ থাকা ইউনিক্স সকেটের মাধ্যমে চলমান ডেমনের সাথে যোগাযোগ করে, যার মোড 0770 এবং মালিকানা headscale গ্রুপের। এর থেকে দুটি বিষয় স্পষ্ট হয়। সার্ভিস বন্ধ থাকলে কমান্ডটি ব্যর্থ হয়, যা এই গাইডের ধাপগুলোর ক্রম বজায় রাখার আরেকটি কারণ। এছাড়া, আপনার নিজের অ্যাকাউন্টকে headscale গ্রুপে যুক্ত না করলে এটি চালানোর জন্য sudo প্রয়োজন হয়।

users list প্রতিটি নামের পাশে একটি আইডি প্রিন্ট করে। আপনার সেই নম্বরটি প্রয়োজন, কারণ কী (key) কমান্ডটি নামের পরিবর্তে একটি সংখ্যাসূচক ইউজার আইডি গ্রহণ করে।

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

কী-টি একবারই প্রিন্ট করা হয়। এটি এখনই কপি করে নিন। একটি প্রি-অথ কী একবারই ব্যবহারযোগ্য এবং অন্যথায় উল্লেখ না থাকলে এটি এক ঘণ্টার জন্য বৈধ থাকে, তাই পরীক্ষা করার সময় --expiration 24h সেট করে রাখা ভালো। একাধিক মেশিন এনরোল করার জন্য --reusable যোগ করুন এবং সেটিকে পাসওয়ার্ডের মতো সুরক্ষিত রাখুন, কারণ এটি যার কাছে থাকবে সে আপনার নেটওয়ার্কে যুক্ত হতে পারবে।

--login-server ব্যবহার করে আপনার প্রথম ক্লায়েন্ট সংযুক্ত করুন

যে মেশিনে আপনি সংযোগ করতে চান তাতে নিচের কমান্ডটি চালান:

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 দ্বারা নির্ধারিত ঠিকানা প্রদর্শন করবে, যা অনেকটা 100.64.0.1 এর মতো। সার্ভারে ফিরে গিয়ে, sudo headscale nodes list কমান্ডটি চালালে নোডটির ID, ব্যবহারকারী এবং অনলাইন অবস্থা দেখা যাবে।

--login-server এর মান অবশ্যই server_url এর সাথে হুবহু মিলতে হবে, যার মধ্যে স্কিম অন্তর্ভুক্ত থাকবে এবং শেষে কোনো স্ল্যাশ (/) থাকা যাবে না। এগুলো স্ট্রিং হিসেবে তুলনা করা হয়; কোনো অমিল থাকলে ক্লায়েন্ট একটি ঠিকানায় নিবন্ধিত হবে কিন্তু তাকে অন্য ঠিকানায় যোগাযোগ করতে বলা হবে।

যে মেশিনটি আগে Tailscale-এর হোস্ট করা পরিষেবায় সাইন-ইন করা ছিল, সেটি সেই লগইনটি ধরে রাখে। সেটিতে প্রথমে sudo tailscale logout চালান, তারপর --login-server ফ্ল্যাগসহ tailscale up চালান।

আপনি যদি --auth-key বাদ দেন, তবে ক্লায়েন্ট একটি URL প্রদর্শন করবে। সেটি ওপেন করলে একটি পেজে নিবন্ধনের শনাক্তকারী (identifier) দেখা যাবে, যা আপনাকে সার্ভারে অনুমোদন করতে হবে:

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

আপনার নিজের ল্যাপটপের জন্য এই পদ্ধতিটি সুবিধাজনক। স্ক্রিপ্ট করা কোনো কাজের জন্য Preauth keys ব্যবহার করা ভালো, কারণ সেক্ষেত্রে কোনো মানুষের নজরদারির প্রয়োজন হয় না।

DERP, এবং সরাসরি সংযোগ ব্যর্থ হলে যা ট্রাফিক রিলে করে

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

ডিফল্ট কনফিগারেশন কী কাজ করে সে সম্পর্কে পরিষ্কার ধারণা রাখুন। Headscale https://controlplane.tailscale.com/derpmap/default-এর দিকে নির্দেশ করে auto_update_enabled: true এবং update_frequency: 3h সহ আসে, তাই আপনার কন্ট্রোল প্লেন আপনার নিজের নিয়ন্ত্রণে থাকলেও রিলেগুলো Tailscale-এর। অধিকাংশ ব্যবহারকারীর জন্য এটি একটি গ্রহণযোগ্য বিনিময়। যদি এটি আপনার জন্য উপযুক্ত না হয়, তবে নিজের রিলে চালান।

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

ক্লায়েন্ট থেকে, tailscale netcheck প্রতিটি রিলে অঞ্চলের ল্যাটেন্সি প্রিন্ট করে যা এটি জানে, এবং tailscale status প্রতিটি পিয়ারকে হয় direct (ঠিকানা সহ) অথবা relay (অঞ্চল কোড সহ) হিসেবে চিহ্নিত করে। কোনো পিয়ার যদি relay-এ আটকে থাকে, তবে সেটি একটি NAT সমস্যা, headscale সমস্যা নয়।

একটি নোড কেন অফলাইন দেখায়?

প্রক্সি আপগ্রেডটি ড্রপ করছে। এটি একটি সাধারণ সমস্যা এবং এর লক্ষণ হলো বাকি সবকিছু ঠিকঠাক কাজ করে: /health 200 (200) রিটার্ন করে, headscale nodes list নোডটিকে দেখায়, কিন্তু নোডটি কখনোই অনলাইনে আসে না। কন্ট্রোল কানেকশনটি হলো একটি POST রিকোয়েস্ট যা Upgrade: tailscale-control-protocol বহন করে, এবং যে প্রক্সি এটি ফরওয়ার্ড করে না তা সেই চ্যানেলটিকে বন্ধ করে দেয় যা নোডের অবস্থা রিপোর্ট করে। আপনার nginx কনফিগারেশনটি উপরের map ব্লকের সাথে মিলিয়ে দেখুন, অথবা প্রক্সির সমস্যা নিশ্চিত হতে Caddy ব্যবহার করে দেখুন।

নোড নিবন্ধনের পর server_url পরিবর্তিত হয়েছে। নোডগুলো নিবন্ধনের সময় যে ভ্যালু পায়, তারা সেটিই ব্যবহার করতে থাকে। যদি আপনি এটি পরিবর্তন করে থাকেন, তবে প্রতিটি নোডে sudo tailscale up --login-server https://headscale.example.com --force-reauth রান করুন।

ক্লায়েন্ট চলছে না। নোডটিতে, sudo systemctl is-active tailscaled এবং sudo journalctl -u tailscaled -n 50 --no-pager চেক করুন। যে ক্লায়েন্ট আপনার ডোমেইন রিজলভ করতে বা সেখানে পৌঁছাতে পারে না, সে তার রিট্রাইগুলো সেখানে লগ করে।

কী (key) এর মেয়াদ শেষ হয়েছে। এটি পরবর্তী সেকশনে আলোচনা করা হয়েছে।

পরীক্ষা করার সময় সার্ভার সাইড পর্যবেক্ষণ করতে, VPS-এ sudo journalctl -u headscale -f রান করুন এবং ক্লায়েন্টে tailscaled রিস্টার্ট করুন। যে নোড headscale-এ পৌঁছাতে পারে তা সাথে সাথে লগ লাইন তৈরি করে। কোনো আউটপুট না আসা মানে রিকোয়েস্টটি পৌঁছাচ্ছে না, তাই headscale দেখার আগে DNS, ফায়ারওয়াল এবং প্রক্সি চেক করুন।

কী এক্সপায়ারি এবং যে নোডটি কয়েক সপ্তাহ পরে কাজ করা বন্ধ করে দেয়

দুটি আলাদা এক্সপায়ারি বিদ্যমান, এবং এগুলোর মধ্যে গুলিয়ে ফেললে সময়ের অপচয় হয়।

Preauth কীগুলো ডিজাইনের কারণেই দ্রুত এক্সপায়ার হয়ে যায়। ডিফল্ট সময় হলো এক ঘণ্টা এবং একবার ব্যবহার। যদি tailscale up কীটি গ্রহণ না করে, তবে ক্লায়েন্টে কোনো কিছু এডিট না করে সার্ভারে একটি নতুন কী তৈরি করুন।

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

কারও ল্যাপটপ হারিয়ে গেলে এটি ম্যানুয়ালি করুন। sudo headscale nodes list আপনাকে আইডি দেবে, তারপর sudo headscale nodes expire -i 3 সেই নোডটিকে লগ আউট করবে, এবং sudo headscale nodes delete -i 3 সেটিকে নেটওয়ার্ক থেকে পুরোপুরি মুছে ফেলবে।

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

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

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

উভয় ফাইল সার্ভার থেকে সরিয়ে নিন। এগুলিতে প্রাইভেট কি এবং প্রতিটি রেজিস্ট্রেশন থাকে, তাই সার্ভারের মতোই এগুলোর সুরক্ষা নিশ্চিত করা প্রয়োজন। VPS থেকে restic ব্যাকআপ অংশে নিয়মিত এবং এনক্রিপ্টেড ব্যাকআপ নেওয়ার পদ্ধতি আলোচনা করা হয়েছে।

আপগ্রেড করার জন্য ইনস্টলেশন প্রক্রিয়াটি পুনরায় সম্পন্ন করুন: নতুন .deb, sudo apt install ./headscale.deb ডাউনলোড করুন, তারপর রিস্টার্ট করুন এবং is-active ও /health চেকগুলো পুনরায় চালান। 0.29 ভার্সন থেকে আপগ্রেড পাথ কঠোর করা হয়েছে। একটি মাইনর ভার্সন বাদ দিয়ে আপগ্রেড করা বা পুরোনো মাইনর ভার্সনে ডাউনগ্রেড করা ব্লক করা হয়েছে। প্রতিটি ধাপে একটি করে মাইনর ভার্সন পরিবর্তন করুন, প্রতিটি ধাপের আগে ব্যাকআপ নিন এবং সেই ভার্সনের রিলিজ নোটগুলো আগে পড়ে নিন, কারণ একই রিলিজ ACL পলিসির আচরণ পরিবর্তন করেছে এবং বেশ কিছু কনফিগারেশন কি স্থানান্তর করেছে।

FAQ

কেন .deb ইনস্টল করার পরপরই headscale চালু হতে ব্যর্থ হয়?

প্যাকেজটি ইউনিটটি ইনস্টল করে কিন্তু সার্ভিসটিকে বন্ধ রাখে, এবং ডিফল্ট /etc/headscale/config.yaml একটি কার্যকরী কনফিগারেশনের পরিবর্তে একটি টেমপ্লেট মাত্র। প্রথমে 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 ত্রুটি হয়, কারণ headscale কোনো পোর্টে বাইন্ড করার আগেই পুরো ফাইলটি পার্স করে।

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

হ্যাঁ। Headscale শুধুমাত্র কন্ট্রোল সার্ভারকে প্রতিস্থাপন করে। প্রতিটি নোড Tailscale-এর অফিসিয়াল ক্লায়েন্ট চালায়, এবং আপনি sudo tailscale up --login-server https://headscale.example.com দিয়ে সেটিকে আপনার সার্ভারের দিকে নির্দেশ করেন। সেই ফ্ল্যাগটি স্ট্যান্ডার্ড ক্লায়েন্টে বিদ্যমান, তাই কোনো কিছু প্যাচ বা রিবিল্ড করার প্রয়োজন নেই।

আমার ট্রাফিক কি headscale সার্ভারের মধ্য দিয়ে যায়?

সাধারণত না। Headscale নেটওয়ার্ক সমন্বয় করে এবং কী (keys) ও অ্যাড্রেস প্রদান করে, যেখানে ডেটা পাথ হলো আপনার নোডগুলোর মধ্যে সরাসরি WireGuard। ট্রাফিক শুধুমাত্র তখনই ঘুরে যায় যখন দুটি নোড একে অপরের সাথে সরাসরি যোগাযোগ করতে পারে না এবং একটি DERP রিলেতে ফিরে যায়, এবং শিপ করা কনফিগারেশনের সাথে সেই রিলেগুলো হলো Tailscale-এর পাবলিক রিলে। একটি নোডে tailscale status চালান এটি দেখার জন্য যে কোনো নির্দিষ্ট পিয়ার direct নাকি relay-তে আছে।

আমার নোড রেজিস্টার করার পর কেন অফলাইন থাকে?

যে নোডটি headscale nodes list-এ দেখা যায় কিন্তু কখনোই অনলাইন হয় না, সেটির কন্ট্রোল কানেকশন সাধারণত রিভার্স প্রক্সিতে বিচ্ছিন্ন হয়ে গেছে। সেই কানেকশনটি হলো একটি HTTP আপগ্রেড যা Upgrade: tailscale-control-protocol হেডারসহ একটি POST হিসেবে পাঠানো হয়, এবং nginx এটিকে ড্রপ করে যদি না আপনি map $http_upgrade $connection_upgrade ব্লক এবং সংশ্লিষ্ট proxy_set_header লাইনগুলো যোগ করেন। Caddy কোনো অতিরিক্ত কনফিগারেশন ছাড়াই এটিকে ফরওয়ার্ড করে, যা প্রক্সির কারণে সমস্যা হচ্ছে কিনা তা পরীক্ষা করার একটি দ্রুত উপায়।

আমার কি headscale-এর জন্য একটি ডোমেইন নাম এবং TLS প্রয়োজন?

বাস্তবে, হ্যাঁ। ক্লায়েন্টরা server_url-এ আপনি যে স্ট্রিংটি দেবেন তার সাথে কানেক্ট হয়, সার্টিফিকেটগুলো নামের জন্য ইস্যু করা হয়, কোনো খালি IP অ্যাড্রেসের জন্য নয়, এবং কনফিগারেশন ফাইলে উল্লেখ আছে যে DERP-এর জন্য TLS প্রয়োজন। একটি ডোমেইন এবং Caddy সেটআপ করতে প্রায় পাঁচ মিনিট সময় লাগে এবং এটি আপনাকে একটি HTTPS এন্ডপয়েন্ট দেয় যা নিজে থেকেই রিনিউ হয়। সাধারণ HTTP-এর মাধ্যমে কন্ট্রোল সার্ভার চালানোর অর্থ হলো এর সাথে প্রতিটি ক্লায়েন্টের কথোপকথন ইন্টারনেটে উন্মুক্ত অবস্থায় আদান-প্রদান হয়।