Headscale سے اپنا Tailscale سرور کیسے چلائیں

headscale کیا ہے

Headscale، Tailscale کنٹرول سرور کا self-hosted نفاذ ہے۔ اس لیے وہ مشین جو آپ کے نجی نیٹ ورک کو مربوط کرتی ہے، آپ کی ملکیت کا VPS ہوتی ہے۔ یہ کمیونٹی کا منصوبہ ہے اور Tailscale Inc. اسے نہیں چلاتی۔ ہر مشین پر سرکاری tailscale کلائنٹ ہی چلتا ہے، جسے ایک flag، --login-server، کے ذریعے آپ کے سرور کی طرف متعین کیا جاتا ہے۔

کنٹرول سرور وہ جزو ہے جو جانتا ہے کہ نیٹ ورک میں کون شامل ہے۔ یہ ہر node کو 100.64.0.0/10 میں سے ایک address دیتا ہے، public keys تقسیم کرتا ہے، اور nodes کو بتاتا ہے کہ وہ ایک دوسرے کو کہاں تلاش کریں۔ tunnels بدستور WireGuard پر قائم رہتے ہیں اور node سے node تک بنتے ہیں۔ آپ کی دو مشینوں کے درمیان network traffic headscale box سے نہیں گزرتا، الاّ یہ کہ براہِ راست راستہ قائم نہ ہو سکے اور nodes relay پر منتقل ہو جائیں۔

Headscale کی ہر instance ایک tailnet (ایک Tailscale network) فراہم کرتی ہے۔ منصوبے کے مطابق یہ ذاتی استعمال یا چھوٹی تنظیم کے لیے موزوں ہے۔ تین یا چار مشینوں کے ساتھ آپ کی ملکیت کے VPS پر ایک سادہ WireGuard VPN چلانے کے لیے کم software درکار ہوتا ہے اور خرابی کے امکانات بھی کم ہوتے ہیں۔ Headscale اس وقت مفید ثابت ہوتا ہے جب آپ ہر نئے laptop کے لیے ایک [Peer] block دستی طور پر نہیں لکھنا چاہتے۔ دونوں models کے وسیع تر موازنے کے لیے WireGuard اور Tailscale میں فرق دیکھیں۔

تنصیب سے پہلے درکار چیزیں

• Ubuntu 24.04 چلانے والا VPS، جس کے پاس عوامی IPv4 ایڈریس اور sudo کی رسائی ہو۔ اگر سرور نیا ہے تو پہلے نئے VPS کے ابتدائی دس منٹ مکمل کریں۔
• اس ایڈریس کی طرف اشارہ کرنے والا DNS A ریکارڈ۔ اس رہنما میں headscale.example.com استعمال کیا گیا ہے۔
• MagicDNS کے لیے دوسرا ڈومین یا ذیلی ڈومین۔ اس رہنما میں tailnet.example.net استعمال کیا گیا ہے۔ یہ server_url میں موجود ڈومین جیسا نہیں ہونا چاہیے۔
• شامل کرنے کے لیے ایک کلائنٹ مشین، جس پر Linux، macOS، Windows، Android یا iOS چل رہا ہو۔

سرکاری .deb سے headscale انسٹال کریں

پروجیکٹ اپنے GitHub releases صفحے پر .deb پیکیجز جاری کرتا ہے۔ جولائی 2026 تک موجودہ ریلیز 0.29.3 ہے۔ پہلے اپنا architecture چیک کریں، کیونکہ فائل کے نام میں 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

فائل کے نام سے پہلے ./ لگانا ضروری ہے۔ اس کے بغیر apt آپ کی repositories میں headscale.deb نامی پیکیج تلاش کرتا ہے اور ناکام ہو جاتا ہے۔

پیکیج headscale system user بناتا ہے، ایک default /etc/headscale/config.yaml لکھتا ہے، اور systemd unit انسٹال کرتا ہے۔ یہ سروس شروع نہیں کرتا، اور یہی درست ترتیب ہے۔ فراہم کردہ configuration server_url کو http://127.0.0.1:8080 پر مقرر کرتی ہے، جو ایسا address نہیں ہے جس تک آپ کا کوئی client پہنچ سکے۔ اس لیے اگر سروس ابھی شروع ہو بھی جائے تو configuration غلط ہو گی۔ اس مرحلے پر sudo systemctl is-active headscale چلانے سے inactive دکھائی دیتا ہے۔ یہ متوقع نتیجہ ہے، خرابی نہیں۔

سروس شروع کرنے سے پہلے server_url ترتیب دیں

sudo nano /etc/headscale/config.yaml کے ذریعے /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 وہ پتہ ہے جہاں عمل bind ہوتا ہے۔ اسے loopback پر ہی رہنے دیں۔ اسی سرور پر موجود reverse proxy TLS (transport layer security) ختم کرکے درخواستیں اسے بھیجتا ہے، اس لیے سرور کے باہر سے کسی کو port 8080 تک رسائی کی ضرورت نہیں۔

base_domain MagicDNS لاحقہ ہے، یعنی وہ domain جس کے تحت آپ کے nodes کو نام ملتے ہیں۔ یہ trailing dot کے بغیر مکمل qualified domain name ہونا چاہیے، اور server_url میں موجود domain سے مختلف ہونا چاہیے، کیونکہ بصورت دیگر دونوں نامی مقامات باہم متصادم ہوں گے۔

database سیکشن میں کوئی تبدیلی نہ کریں۔ پہلے سے طے شدہ اختیار SQLite ہے، جو /var/lib/headscale/db.sqlite میں موجود ہے۔ یہ اس directory میں ہے جسے package نے بنایا اور اس کی ملکیت حاصل کی ہے، اور اس سائز کے 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 دونوں کام کرتا ہے: سروس شروع کرتا ہے اور اسے reboot کے بعد شروع ہونے کے لیے فعال کرتا ہے۔

اگر is-active، failed دکھائے تو sudo journalctl -u headscale -n 50 --no-pager کے ذریعے journal پڑھیں۔ اس مرحلے پر خرابی تقریباً ہمیشہ configuration file میں ہوتی ہے، کیونکہ headscale socket کھولنے سے پہلے پوری file parse کرتا ہے۔ اس لیے غلط indent یا نامعلوم key، کسی بھی چیز کے listen ہونے سے پہلے process روک دیتی ہے۔ file درست کریں، پھر sudo systemctl restart headscale چلائیں۔ اس کے بعد configuration میں کی جانے والی ہر تبدیلی کے لیے یہی restart درکار ہوگا۔ بعد میں clients خود دوبارہ connect ہو جاتے ہیں۔ اگر systemd units آپ کے لیے نئی ہیں تو systemd کے ذریعے اپنی services اور timers چلانا یہاں استعمال ہونے والے commands کی وضاحت کرتا ہے۔

Shell میں موجود رہتے ہوئے state files بھی چیک کریں:

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

دونوں lines headscale سے شروع ہوتی ہیں، جو package کے بنائے ہوئے unprivileged user کا نام ہے۔ noise_private.key، اپنے clients کے لیے server کی شناخت ہے۔ اسے محفوظ رکھیں۔ اگر آپ اسے delete کر دیں تو headscale نئی شناخت بناتا ہے اور ہر node کو دوبارہ register کرنا پڑتا ہے۔

headscale کے سامنے TLS لگائیں

Clients کو server_url تک HTTPS کے ذریعے پہنچنا چاہیے۔ Caddy سب سے مختصر راستہ ہے، کیونکہ یہ خود certificate کی درخواست اور تجدید کرتا ہے۔

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

فائل کی parsing کامیاب ہونے پر validate، adapted config to JSON دکھاتا ہے۔ فائل کے format نہ ہونے سے متعلق warning صرف ظاہری مسئلہ ہے۔ اپنے laptop سے curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health کو بھی 200 دکھانا چاہیے۔ اس ایک جانچ سے ثابت ہو جاتا ہے کہ DNS، firewall، certificate اور proxy مل کر درست کام کر رہے ہیں۔

یہ proxy کی وہ تفصیل ہے جس پر لوگ ایک شام ضائع کر دیتے ہیں۔ Tailscale control connection ایک HTTP upgrade ہے۔ یہ GET کے بجائے POST سے شروع ہوتا ہے، اور Upgrade header کی value tailscale-control-protocol ہوتی ہے۔ Caddy اسے اضافی configuration کے بغیر آگے منتقل کر دیتا ہے۔ 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;
    }
}

ان lines کو چھوڑنے پر عام requests پھر بھی کامیاب ہوتی رہتی ہیں۔ اسی لیے /health، 200 واپس کرتا ہے اور سب کچھ درست دکھائی دیتا ہے، جبکہ دیرپا control connection قائم نہیں ہوتا اور آپ کے nodes register ہونے کے بعد offline رہتے ہیں۔ اگر آپ nginx استعمال کریں، تو Ubuntu 24.04 پر nginx کے ساتھ Certbot certificate کے حصے کی وضاحت کرتا ہے۔

UFW میں کھولے جانے والے پورٹس

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

Port 443 تمام کلائنٹ مواصلات کے لیے استعمال ہوتا ہے۔ Port 80 صرف ACME (خودکار سرٹیفکیٹ مینجمنٹ ماحول) کے HTTP challenge اور HTTPS پر redirect کے لیے درکار ہے، اور Caddy کو سرٹیفکیٹ حاصل کرنے کے لیے اس پورٹ کی ضرورت ہوتی ہے۔

Port 8080 بند رہتا ہے۔ listen_addr، 127.0.0.1:8080 ہے، اس لیے proxy، headscale تک loopback interface کے ذریعے پہنچتا ہے اور firewall rule کی ضرورت نہیں ہوتی۔ Port 8080 کو internet کے لیے کھولنے سے کلائنٹس کو cleartext control channel ملتا ہے، لیکن اس کا کوئی فائدہ نہیں۔ یاد رکھیں کہ زیادہ تر providers اپنے control panel میں UFW سے الگ دوسرا firewall چلاتے ہیں۔ اس لیے کوئی port مشین پر کھلا ہو سکتا ہے، لیکن edge پر پھر بھی بند ہو سکتا ہے۔ VPS پر UFW firewall کی بنیادی باتیں میں rule syntax کی مزید تفصیل دی گئی ہے۔

صارف اور preauth key بنائیں

sudo headscale users create alice
sudo headscale users list

headscale ایک client ہے۔ یہ چل رہے daemon سے unix socket /var/run/headscale/headscale.sock کے ذریعے رابطہ کرتا ہے۔ اس socket کا mode 0770 ہے اور یہ headscale group کی ملکیت ہے۔ اس کے دو نتائج ہیں۔ سروس بند ہونے پر command ناکام ہو جاتی ہے، جو اس guide میں ترتیب کی اہمیت کی دوسری وجہ ہے۔ اس کے علاوہ، آپ کو sudo درکار ہے، الاّ یہ کہ آپ اپنا account headscale group میں شامل کر دیں۔

users list ہر نام کے ساتھ ایک ID دکھاتا ہے۔ آپ کو یہ number درکار ہے، کیونکہ key command نام کے بجائے numeric user ID لیتی ہے۔

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

key صرف ایک بار دکھائی جاتی ہے۔ اسے ابھی copy کر لیں۔ preauth key single use ہوتی ہے اور ایک گھنٹے تک valid رہتی ہے، جب تک آپ مختلف مدت مقرر نہ کریں۔ اس لیے testing کے دوران --expiration 24h مقرر کرنا مفید ہے۔ ایسی key کے لیے --reusable شامل کریں جو کئی machines کو enroll کرے، اور اسے password کی طرح محفوظ رکھیں، کیونکہ جس شخص کے پاس یہ ہو وہ آپ کے network میں شامل ہو سکتا ہے۔

--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 سے بالکل مطابقت رکھنی چاہیے۔ اس میں scheme بھی شامل ہے اور آخر میں slash نہیں ہونا چاہیے۔ ان کا موازنہ strings کے طور پر کیا جاتا ہے۔ عدم مطابقت کی صورت میں کلائنٹ ایک پتے کے خلاف رجسٹر ہوتا ہے، پھر اسے دوسرے پتے سے رابطہ کرنے کو کہا جاتا ہے۔

جو مشین پہلے Tailscale کی hosted service میں سائن ان ہو چکی ہو، اس کی وہ login برقرار رہتی ہے۔ پہلے اس پر sudo tailscale logout چلائیں، پھر --login-server کے ساتھ tailscale up چلائیں۔

اگر آپ --auth-key چھوڑ دیں، تو کلائنٹ اس کے بجائے ایک URL دکھاتا ہے۔ اسے کھولیں۔ صفحہ اس registration attempt کا identifier دکھاتا ہے، جسے آپ سرور پر منظور کرتے ہیں:

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

یہ طریقہ آپ کے اپنے laptop کے لیے زیادہ آسان ہے۔ scripted کاموں کے لیے preauth keys بہتر ہیں، کیونکہ کسی انسان کو نگرانی کرنے کی ضرورت نہیں ہوتی۔

DERP، اور براہِ راست راستہ ناکام ہونے پر ٹریفک کو ریلے کرنے والا نظام

DERP (designated encrypted relay for packets) متبادل راستہ ہے۔ جب دو nodes براہِ راست WireGuard connection قائم نہیں کر سکتے، عموماً اس لیے کہ دونوں سخت NAT (network address translation) کے پیچھے ہوں، تو وہ packets ریلے کے ذریعے بھیجتے ہیں۔ ریلے کے پاس کوئی keys نہیں ہوتیں، اس لیے وہ آپ کی traffic پڑھ نہیں سکتا۔ البتہ اسے معلوم ہوتا ہے کہ کون سے nodes آپس میں رابطہ کر رہے ہیں اور کتنا data منتقل ہو رہا ہے۔

default configuration کے اثرات واضح طور پر سمجھیں۔ Headscale، https://controlplane.tailscale.com/derpmap/default کی طرف auto_update_enabled: true اور update_frequency: 3h کے ساتھ پہلے سے اشارہ کرتا ہے۔ اس طرح آپ کا control plane آپ کے اختیار میں رہتا ہے، جبکہ relays 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 اس تقاضے کو واضح طور پر بیان کرتی ہے: server_url میں https استعمال ہونا چاہیے، کیونکہ DERP کو TLS درکار ہے۔ derp.urls list کو خالی کرنے سے Tailscale کے relays نقشے سے ہٹ جاتے ہیں۔ اگر آپ ایسا working embedded relay کے بغیر کرتے ہیں تو nodes کا ہر وہ جوڑا جو براہِ راست connect نہیں ہو سکتا، بالکل connect نہیں ہو سکے گا۔

کسی client سے tailscale netcheck ہر معلوم relay region تک latency دکھاتا ہے، جبکہ tailscale status ہر peer کو اس کے address کے ساتھ direct یا region code کے ساتھ relay قرار دیتا ہے۔ relay پر پھنسا ہوا peer NAT کا مسئلہ ہے، headscale کا نہیں۔

نوڈ آف لائن کیوں دکھائی دیتا ہے؟

پراکسی upgrade کو آگے نہیں بھیج رہی۔ یہ عام وجہ ہے، اور اس کی علامت یہ ہے کہ باقی سب کچھ درست دکھائی دیتا ہے: /health کا نتیجہ 200 آتا ہے، headscale nodes list میں نوڈ دکھائی دیتا ہے، لیکن نوڈ کبھی آن لائن نہیں ہوتا۔ کنٹرول کنکشن ایک POST ہے جس میں Upgrade: tailscale-control-protocol شامل ہوتا ہے۔ جو پراکسی اسے آگے نہیں بھیجتی، وہ نوڈ کی حالت رپورٹ کرنے والا واحد چینل بند کر دیتی ہے۔ اپنی nginx configuration کا اوپر دیے گئے map block سے موازنہ کریں، یا پراکسی کو خارج از امکان قرار دینے کے لیے 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 چلائیں۔ جو کلائنٹ آپ کے domain کو resolve یا اس تک رسائی حاصل نہیں کر سکتا، وہ اپنی دوبارہ کوششوں کا لاگ وہیں درج کرتا ہے۔

key کی میعاد ختم ہو گئی ہے۔ اس کی وضاحت اگلے حصے میں ہے۔

جانچ کے دوران server side کی نگرانی کے لیے VPS پر sudo journalctl -u headscale -f چلائیں اور client پر tailscaled دوبارہ شروع کریں۔ headscale تک پہنچنے والا نوڈ فوراً log lines تیار کرتا ہے۔ خاموشی کا مطلب ہے کہ request پہنچ نہیں رہی۔ اس لیے headscale دیکھنے سے پہلے DNS، firewall اور proxy چیک کریں۔

کلید کی میعاد ختم ہونا، اور وہ نوڈ جو کئی ہفتے بعد کام کرنا بند کر دیتا ہے

دو الگ الگ میعادیں موجود ہیں، اور انہیں آپس میں ملانے سے وقت ضائع ہوتا ہے۔

Preauth keys ڈیزائن کے لحاظ سے جلدی expire ہوتی ہیں۔ ڈیفالٹ ایک گھنٹہ اور ایک استعمال ہے۔ اگر tailscale up کلید قبول نہ کرے تو client پر کچھ ترمیم کرنے کے بجائے server پر نئی کلید بنائیں۔

Node keys طویل مدت والا حصہ ہیں۔ config.yaml کا node سیکشن expiry: 0 مقرر کرتا ہے، اور 0 کا مطلب ہے کہ کوئی default expiry نہیں ہے: registered node اس وقت تک valid رہتا ہے جب تک آپ اسے expire نہ کریں۔ Tagged nodes کی میعاد کبھی ختم نہیں ہوتی۔ اگر آپ چاہتے ہیں کہ registrations وقت کے ساتھ خود expire ہوں تو expiry: 180d مقرر کریں، لیکن اس کے اثر کو سمجھیں: اس کے بعد ہر non-tagged node کو اسی شیڈول کے مطابق sudo tailscale up --login-server https://headscale.example.com --force-reauth درکار ہوگا، اور headless server، جسے کوئی دوبارہ authenticate نہیں کرتا، خود ہی network سے خارج ہو جائے گا۔

جب کسی کا laptop گم ہو جائے تو یہ کام دستی طور پر کریں۔ sudo headscale nodes list آپ کو ID دیتا ہے، پھر sudo headscale nodes expire -i 3 اس node کو logout کرتا ہے، اور sudo headscale nodes delete -i 3 اسے network سے مکمل طور پر ہٹا دیتا ہے۔

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

/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

دونوں فائلیں سرور سے باہر منتقل کریں۔ ان میں نجی keys اور تمام registrations شامل ہیں، اس لیے ان کی حفاظت بھی سرور جیسی ہی ہونی چاہیے۔ VPS سے restic بیک اپس میں یہ کام مقررہ شیڈول کے مطابق اور encrypted طریقے سے کرنے کا طریقہ شامل ہے۔

اپ گریڈ کا طریقہ انسٹالیشن کو دہراتا ہے: نیا .deb، sudo apt install ./headscale.deb ڈاؤن لوڈ کریں، پھر سروس restart کریں اور is-active اور /health checks دوبارہ چلائیں۔ 0.29 سے upgrade path سخت ہے۔ minor version چھوڑ کر آگے بڑھنا ممنوع ہے، اور پرانے minor version پر downgrade کرنا بھی ممنوع ہے۔ ایک وقت میں صرف ایک minor version آگے بڑھیں، ہر مرحلے سے پہلے بیک اپ لیں، اور پہلے اس version کی release notes پڑھیں، کیونکہ اسی release میں ACL policy کے رویے میں تبدیلی کی گئی اور کئی configuration keys منتقل کی گئیں۔

FAQ

headscale کو .deb انسٹال کرنے کے فوراً بعد شروع ہونے میں ناکامی کیوں ہوتی ہے؟

پیکیج 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 کرتا ہے۔

کیا مجھے اپنی machines پر معمول کا Tailscale client اب بھی انسٹال کرنا ہوگا؟

جی ہاں۔ Headscale صرف control server کو تبدیل کرتا ہے۔ ہر node Tailscale کا official client چلاتا ہے، اور آپ sudo tailscale up --login-server https://headscale.example.com کے ذریعے اسے اپنے server کی طرف متوجہ کرتے ہیں۔ یہ flag standard client میں موجود ہے، اس لیے کسی patch یا rebuild کی ضرورت نہیں ہوتی۔

کیا میرا traffic headscale server سے گزرتا ہے؟

عام طور پر نہیں۔ Headscale network کو coordinate کرتا ہے اور keys اور addresses فراہم کرتا ہے، جبکہ data path آپ کے nodes کے درمیان براہِ راست WireGuard کے ذریعے قائم ہوتا ہے۔ Traffic صرف اس وقت متبادل راستہ اختیار کرتا ہے جب دو nodes ایک دوسرے تک براہِ راست نہ پہنچ سکیں اور DERP relay پر fallback کریں۔ shipped configuration میں یہ relays Tailscale کے public relays ہوتے ہیں۔ کسی node پر tailscale status چلائیں تاکہ معلوم ہو سکے کہ متعلقہ peer direct ہے یا relay پر ہے۔

رجسٹر ہونے کے بعد میرا node offline کیوں رہتا ہے؟

جو node headscale nodes list میں ظاہر ہو، لیکن کبھی online نہ ہو، وہ عموماً reverse proxy پر اپنا control connection کھو چکا ہوتا ہے۔ یہ connection Upgrade: tailscale-control-protocol header کے ساتھ POST کی صورت میں بھیجا جانے والا HTTP upgrade ہوتا ہے۔ nginx اسے اس وقت تک drop کر دیتا ہے جب تک آپ map $http_upgrade $connection_upgrade block اور اس سے مطابقت رکھنے والی proxy_set_header lines شامل نہ کریں۔ Caddy اسے کسی اضافی configuration کے بغیر forward کر دیتا ہے، اس لیے یہ جانچنے کا تیز طریقہ ہے کہ مسئلہ proxy میں ہے یا نہیں۔

کیا headscale کے لیے domain name اور TLS ضروری ہیں؟

عملی طور پر، ہاں۔ Clients اسی string سے connect کرتے ہیں جو آپ server_url میں رکھتے ہیں۔ Certificates names کے لیے جاری کیے جاتے ہیں، bare IP addresses کے لیے نہیں۔ Configuration file یہ بھی بیان کرتی ہے کہ DERP کے لیے TLS ضروری ہے۔ Domain اور Caddy کے ذریعے تقریباً پانچ منٹ میں HTTPS endpoint قائم ہو جاتا ہے، جو خود renew ہوتا ہے۔ Control server کو plain HTTP پر چلانے کا مطلب ہے کہ clients اور server کے درمیان ہر conversation internet پر غیر encrypted حالت میں گزرتی ہے۔