Headscale कैसे सेटअप करें: अपना खुद का Tailscale सर्वर

Headscale क्या है

Headscale, Tailscale control server का एक self-hosted कार्यान्वयन है। इसका मतलब है कि आपके निजी नेटवर्क को समन्वित करने वाली मशीन आपका अपना VPS है। यह एक सामुदायिक प्रोजेक्ट है और इसे Tailscale Inc. द्वारा संचालित नहीं किया जाता है। प्रत्येक मशीन अभी भी आधिकारिक tailscale क्लाइंट चलाती है, जिसे एक फ्लैग, --login-server के साथ आपके सर्वर की ओर निर्देशित किया जाता है।

Control server वह हिस्सा है जो यह जानता है कि नेटवर्क का हिस्सा कौन है। यह प्रत्येक नोड को 100.64.0.0/10 से एक पता देता है, public keys वितरित करता है, और नोड्स को बताता है कि एक-दूसरे को कहाँ खोजना है। टनल WireGuard ही रहती हैं, जो नोड से नोड तक बनी होती हैं। आपकी दो मशीनों के बीच का traffic headscale बॉक्स से होकर नहीं गुजरता, जब तक कि सीधा रास्ता न बन सके और नोड्स relay पर निर्भर न हो जाएं। इस समन्वय भूमिका को स्वयं चलाने से यह बदल जाता है कि इसे कौन नियंत्रित करता है, न कि यह कि यह क्या करने में सक्षम है। इसलिए, इस कदम को अपने आप में सुरक्षा की जीत मानने से पहले इस मॉडल में एक control server क्या देख सकता है और क्या नहीं को समझना उचित है।

Headscale प्रति instance एक tailnet (एक Tailscale नेटवर्क) प्रदान करता है, जिसे प्रोजेक्ट व्यक्तिगत उपयोग या छोटे संगठन के लिए उपयुक्त बताता है। तीन या चार मशीनों के साथ, आपके अपने VPS पर एक साधारण WireGuard VPN चलाना कम सॉफ्टवेयर और कम जटिलता वाला होता है। Headscale तब फायदेमंद होता है जब आप हर नए लैपटॉप के लिए हाथ से [Peer] ब्लॉक नहीं लिखना चाहते। अक्सर लागत ही वह कारण है जो लोगों को इसकी तलाश करने के लिए प्रेरित करती है। इसलिए, सर्वर लेने से पहले hosted free plan वास्तव में क्या कवर करता है इसे पढ़ना उचित है, क्योंकि व्यक्तिगत मशीनों की एक छोटी संख्या आमतौर पर इसमें फिट हो जाती है। यदि आप उस सीमा से आगे निकल चुके हैं, तो paid plans की लागत, जो प्रति डिवाइस के बजाय प्रति उपयोगकर्ता है की गणना करें, क्योंकि एक खाते पर एक परिवार डिवाइस की संख्या मायने रखना बंद होने के बाद भी सस्ता रह सकता है। यदि आप एक self-hosted control plane चाहते हैं, लेकिन Tailscale के विकल्प के बजाय अपना खुद का क्लाइंट और peers को प्रबंधित करने के लिए एक web interface पसंद करते हैं, तो एकल VPS पर NetBird एक ऐसा विकल्प है जिस पर विचार किया जा सकता है। दोनों मॉडलों की व्यापक तुलना के लिए, देखें WireGuard और Tailscale कैसे भिन्न हैं।

इंस्टॉलेशन से पहले आपकी आवश्यकताएं

• Ubuntu 24.04 पर चलने वाला एक VPS, जिसमें public IPv4 address और sudo access हो। यदि सर्वर नया है, तो पहले नए VPS पर शुरुआती दस मिनट का कार्य पूरा करें।
• उस address पर point करने वाला एक DNS A record। यह गाइड headscale.example.com का उपयोग करती है।
• MagicDNS के लिए एक दूसरा domain या subdomain। यह गाइड tailnet.example.net का उपयोग करती है। यह server_url में उपयोग किए गए domain से अलग होना चाहिए।
• जुड़ने के लिए एक client machine, जो Linux, macOS, Windows, Android या iOS पर चल रही हो।

आधिकारिक .deb से headscale इंस्टॉल करें

यह प्रोजेक्ट अपने GitHub releases पेज पर .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 यूनिट इंस्टॉल करता है। यह सर्विस को start नहीं करता है, और यही सही क्रम है। शिप की गई कॉन्फ़िगरेशन server_url को http://127.0.0.1:8080 पर पॉइंट करती है, जो कि ऐसा पता नहीं है जिसे आपका कोई भी क्लाइंट एक्सेस कर सके, इसलिए यदि सर्विस अभी शुरू की गई तो वह गलत होगी, भले ही वह चालू हो जाए। इस बिंदु पर 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 हर क्लाइंट रजिस्ट्रेशन में लिखता है। क्लाइंट्स उसके बाद हमेशा उसी स्ट्रिंग का उपयोग करके कनेक्ट करते हैं, इसलिए यह https:// के साथ पब्लिक नाम होना चाहिए, न कि 127.0.0.1।

listen_addr वह स्थान है जहाँ प्रोसेस बाइंड होती है। इसे loopback पर ही रहने दें। उसी सर्वर पर मौजूद एक reverse proxy TLS (transport layer security) को टर्मिनेट करता है और इसे फॉरवर्ड करता है, इसलिए सर्वर के बाहर किसी भी चीज़ को port 8080 तक पहुँचने की आवश्यकता नहीं है।

base_domain MagicDNS सफ़िक्स है, वह डोमेन जिसके अंतर्गत आपके नोड्स को नाम मिलते हैं। यह बिना ट्रेलिंग डॉट वाला एक fully qualified domain name होना चाहिए, और यह server_url वाले डोमेन से अलग होना चाहिए, अन्यथा दोनों नेम स्पेस आपस में टकरा जाएंगे।

डेटाबेस सेक्शन को न बदलें। डिफ़ॉल्ट रूप से यह /var/lib/headscale/db.sqlite पर SQLite है, जो एक ऐसी डायरेक्टरी में है जिसे पैकेज ने बनाया है और जिसका वह स्वामी है, और इस आकार के tailnet के लिए SQLite पर्याप्त है।

Start 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 कमांड दोनों काम करता है: यह सर्विस को शुरू करता है और इसे रीबूट के बाद शुरू होने के लिए मार्क करता है।

यदि is-active कमांड failed प्रिंट करता है, तो sudo journalctl -u headscale -n 50 --no-pager के साथ जर्नल पढ़ें। इस चरण पर विफलता लगभग हमेशा configuration file के कारण होती है, क्योंकि headscale सॉकेट खोलने से पहले पूरी फाइल को पार्स करता है। इसलिए, गलत इंडेंट या अज्ञात की (key) किसी भी पोर्ट के लिसन होने से पहले ही प्रोसेस को रोक देती है। फाइल को ठीक करें, फिर sudo systemctl restart headscale चलाएं। बाद में किसी भी configuration बदलाव के लिए उसी रीस्टार्ट की आवश्यकता होती है। क्लाइंट इसके बाद अपने आप फिर से कनेक्ट हो जाते हैं। यदि systemd यूनिट्स आपके लिए नई हैं, तो systemd के साथ अपनी खुद की सर्विस और टाइमर चलाना में यहाँ उपयोग की गई कमांड्स की जानकारी दी गई है।

शेल में रहते हुए स्टेट फाइल्स की जाँच करें:

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

दोनों लाइनें headscale से शुरू होती हैं, जो कि पैकेज द्वारा बनाया गया एक अनप्रिविलेज्ड यूजर है। noise_private.key क्लाइंट्स के लिए सर्वर की पहचान है। इसे सुरक्षित रखें। यदि आप इसे डिलीट करते हैं, तो headscale एक नई पहचान जनरेट करेगा और प्रत्येक नोड को फिर से रजिस्टर करना होगा।

Headscale के सामने TLS लगाएँ

Clients को HTTPS के माध्यम से server_url तक पहुँचना चाहिए। Caddy सबसे छोटा रास्ता है, क्योंकि यह अपने आप certificate का अनुरोध करता है और उसे renew करता है।

sudo apt install -y caddy

/etc/caddy/Caddyfile को headscale documentation के ब्लॉक से बदलें:

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

जब file parse होती है, तो validate, adapted config to JSON print करता है। यह चेतावनी कि file formatted नहीं है, केवल cosmetic है। आपके laptop से, curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health को भी 200 print करना चाहिए। यह एक जाँच यह साबित करती है कि DNS, firewall, certificate और proxy सभी एक साथ काम कर रहे हैं।

यहाँ proxy का वह विवरण है जिसमें लोगों की एक पूरी शाम बर्बाद हो जाती है। Tailscale control connection एक HTTP upgrade है, यह GET के बजाय POST के साथ शुरू होता है, और Upgrade header का मान tailscale-control-protocol होता है। Caddy इसे बिना किसी अतिरिक्त configuration के pass कर देता है। 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;
    }
}

यदि आप उन पंक्तियों को छोड़ देते हैं, तो सामान्य requests सफल होती रहेंगी, यही कारण है कि /health 200 return करता है और सब कुछ ठीक दिखता है, जबकि long-lived control connection कभी नहीं बनता है और आपके nodes register होने के बाद offline ही रहते हैं। यदि आप nginx का रास्ता चुनते हैं, तो Certbot on Ubuntu 24.04 with nginx 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 सभी client conversations को संभालता है। Port 80 केवल ACME (automatic certificate management environment) HTTP challenge और HTTPS पर रीडायरेक्ट करने के लिए आवश्यक है, और Caddy को certificate प्राप्त करने के लिए इसकी आवश्यकता होती है।

Port 8080 को बंद रखें। listen_addr, 127.0.0.1:8080 है, इसलिए proxy loopback interface के माध्यम से headscale तक पहुँचता है और इसमें किसी firewall rule की आवश्यकता नहीं होती। 8080 को इंटरनेट के लिए खोलने से clients को एक cleartext control channel मिल जाता है और इसका कोई लाभ नहीं है। ध्यान रखें कि अधिकांश providers UFW से अलग, अपने control panel में एक दूसरी firewall चलाते हैं, इसलिए एक port server पर खुला होने के बावजूद edge पर बंद हो सकता है। VPS पर UFW firewall की बुनियादी जानकारी में rule syntax को विस्तार से समझाया गया है।

एक user और एक preauth key बनाएँ

sudo headscale users create alice
sudo headscale users list

headscale कमांड एक client है। यह /var/run/headscale/headscale.sock पर स्थित unix socket के माध्यम से चल रहे daemon से बात करता है, जिसका mode 0770 है और जो headscale group के स्वामित्व में है। इसके परिणामस्वरूप दो बातें होती हैं। जब service बंद होती है तो यह कमांड विफल हो जाता है, यही कारण है कि इस गाइड में निर्देशों का क्रम महत्वपूर्ण है। साथ ही, जब तक आप अपने account को headscale group में नहीं जोड़ते, तब तक इसे sudo की आवश्यकता होती है।

users list प्रत्येक नाम के आगे एक ID प्रिंट करता है। आपको उस संख्या की आवश्यकता होगी, क्योंकि key कमांड नाम के बजाय numeric user ID लेती है।

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

key केवल एक बार प्रिंट होती है। इसे अभी copy कर लें। एक preauth key का उपयोग केवल एक बार किया जा सकता है और यह एक घंटे के लिए वैध होती है, जब तक कि आप अन्यथा न कहें। इसलिए परीक्षण के दौरान --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 से बिल्कुल मेल खाना चाहिए, जिसमें स्कीम शामिल हो और अंत में कोई स्लैश न हो। इनकी तुलना स्ट्रिंग के रूप में की जाती है, और बेमेल होने का मतलब है कि क्लाइंट एक पते पर रजिस्टर होता है और फिर उसे दूसरे पते पर बात करने के लिए कहा जाता है।

जो मशीन पहले Tailscale की होस्टेड सर्विस में साइन इन थी, वह उस लॉगिन को बनाए रखती है। उस पर पहले sudo tailscale logout चलाएं, फिर --login-server के साथ tailscale up चलाएं।

यदि आप --auth-key को छोड़ देते हैं, तो क्लाइंट एक URL प्रिंट करता है। उसे खोलें और पेज उस रजिस्ट्रेशन प्रयास के लिए आइडेंटिफायर दिखाता है, जिसे आप सर्वर पर अप्रूव करते हैं:

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

वह फॉर्म आपके अपने लैपटॉप के लिए अधिक सुविधाजनक है। प्री-ऑथेंटिकेशन कीज़ (Preauth keys) किसी भी स्क्रिप्टेड कार्य के लिए बेहतर हैं, क्योंकि इसमें किसी व्यक्ति को निगरानी करने की आवश्यकता नहीं होती है। एक बार जब VPS स्वयं एक नोड बन जाता है, तो यह आपकी अन्य मशीनों के इंटरनेट ट्रैफ़िक को भी ले जा सकता है, जो एग्जिट नोड सेटअप है, बस एक अंतर यह है कि आप होस्टेड एडमिन कंसोल के बजाय headscale कमांड के साथ सर्वर पर विज्ञापित रूट (advertised route) को अप्रूव करते हैं। यदि आप इंटरनेट तक पहुँचने के बजाय उस VPS के पीछे स्थित प्राइवेट नेटवर्क तक पहुँच चाहते हैं, तो वही अप्रूवल स्टेप उस सबनेट को अपने बाकी टेलनेट (tailnet) में विज्ञापित करने के लिए काम आता है। किसी नोड से पूरे नेटवर्क को रूट करने के बजाय एक एप्लिकेशन पब्लिश करना एक अलग कार्य है, और serve और funnel इसे करने के दो तरीके हैं, हालाँकि दोनों Tailscale के अपने सर्टिफिकेट और इनग्रेस मशीनरी पर निर्भर करते हैं, इसलिए उन्हें होस्टेड-टेलनेट फीचर्स के रूप में पढ़ें, न कि ऐसी चीज़ के रूप में जो headscale आपको प्रदान करता है।

DERP, और जब सीधा रास्ता विफल हो जाए तो क्या traffic को relay करता है

DERP (designated encrypted relay for packets) एक fallback रास्ता है। जब दो nodes एक सीधा WireGuard connection नहीं खोल पाते हैं, आमतौर पर इसलिए क्योंकि दोनों strict NAT (network address translation) के पीछे होते हैं, तो वे इसके बजाय एक relay के माध्यम से packets भेजते हैं। Relay के पास कोई keys नहीं होती हैं, इसलिए यह आपके traffic को पढ़ नहीं सकता है। यह केवल यह देखता है कि कौन से nodes आपस में बात कर रहे हैं और कितना data transfer हो रहा है।

डिफ़ॉल्ट 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 सूची को खाली करने से Tailscale के relays map से हट जाते हैं, और यदि आप ऐसा किसी कार्यशील embedded relay के बिना करते हैं, तो ऐसे nodes का कोई भी जोड़ा जो सीधे connect नहीं हो सकता, वह बिल्कुल भी connect नहीं हो पाएगा।

Client से tailscale netcheck चलाने पर यह ज्ञात प्रत्येक relay region तक latency दिखाता है। tailscale status प्रत्येक peer को direct यानी address के साथ या relay यानी region code के साथ चिह्नित करता है। relay पर अटका peer NAT की समस्या दर्शाता है, headscale की नहीं। जो peer direct है लेकिन फिर भी धीमा है, वह अलग समस्या है। वहाँ सामान्यतः समस्या tunnel के बजाय MTU में होती है.

नोड ऑफलाइन क्यों दिखता है?

प्रॉक्सी अपग्रेड को ड्रॉप कर रही है। यह एक सामान्य समस्या है, और इसका संकेत यह है कि बाकी सब कुछ सही काम कर रहा है: /health 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 की जाँच करें। जो क्लाइंट आपके डोमेन को रिजॉल्व या एक्सेस नहीं कर सकता, वह अपने रिट्राय (retries) को वहीं लॉग करता है।

की (key) की समय-सीमा समाप्त हो गई है। इसे अगले सेक्शन में कवर किया गया है।

परीक्षण के दौरान सर्वर-साइड को मॉनिटर करने के लिए, VPS पर sudo journalctl -u headscale -f चलाएं और क्लाइंट पर tailscaled को रीस्टार्ट करें। जो नोड headscale तक पहुँचता है, वह तुरंत लॉग लाइनें उत्पन्न करता है। यदि कोई लॉग नहीं दिख रहा है, तो इसका मतलब है कि रिक्वेस्ट पहुँच नहीं रही है, इसलिए headscale को देखने से पहले DNS, फायरवॉल और प्रॉक्सी की जाँच करें।

Key expiry, और वह node जो हफ्तों बाद काम करना बंद कर देता है

दो अलग-अलग प्रकार की expiry होती हैं, और उन्हें आपस में मिला देने से समय बर्बाद होता है।

Preauth keys डिज़ाइन के अनुसार जल्दी expire हो जाती हैं। डिफ़ॉल्ट समय एक घंटा और एक उपयोग है। यदि tailscale up key को अस्वीकार कर देता है, तो client पर कुछ भी edit करने के बजाय सर्वर पर एक नई key generate करें।

Node keys लंबे समय तक चलने वाला हिस्सा हैं। config.yaml का node section expiry: 0 को सेट करता है, और 0 का अर्थ है कोई डिफ़ॉल्ट expiry नहीं: एक registered node तब तक valid रहता है जब तक आप उसे expire न कर दें। Tagged nodes कभी भी expire नहीं होते हैं। यदि आप चाहते हैं कि registrations समय के साथ समाप्त हो जाएं, तो expiry: 180d सेट करें, लेकिन यह समझें कि आप क्या कर रहे हैं: इसके बाद हर non-tagged node को उस schedule पर sudo tailscale up --login-server https://headscale.example.com --force-reauth की आवश्यकता होगी, और एक headless सर्वर जिसे कोई re-authenticate नहीं करता है, वह अपने आप नेटवर्क से हट जाएगा।

जब किसी का laptop खो जाए तो इसे मैन्युअल रूप से करें। sudo headscale nodes list आपको ID देता है, फिर sudo headscale nodes expire -i 3 उस node को log out कर देता है, और sudo headscale nodes delete -i 3 उसे पूरी तरह से नेटवर्क से हटा देता है।

बैकअप और अपग्रेड

/var/lib/headscale और /etc/headscale मिलकर पूरे सर्वर का निर्माण करते हैं। इन्हें कॉपी करने से पहले सर्विस को रोक दें, क्योंकि SQLite में डेटा राइट हो रहा हो सकता है और लोड के दौरान कॉपी की गई डेटाबेस फाइल असंगत (inconsistent) हो सकती है।

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 वर्ज़न के बाद से अपग्रेड पाथ सख्त है। किसी माइनर वर्ज़न को छोड़ना (skip करना) प्रतिबंधित है, और पुराने माइनर वर्ज़न पर डाउनग्रेड करना भी संभव नहीं है। एक बार में केवल एक माइनर वर्ज़न आगे बढ़ें, हर चरण से पहले बैकअप लें, और उस वर्ज़न के रिलीज़ नोट्स को पहले पढ़ें, क्योंकि उसी रिलीज़ में 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) और पते (addresses) प्रदान करता है, जबकि डेटा पाथ आपके नोड्स के बीच सीधे WireGuard होता है। ट्रैफ़िक केवल तब डायवर्ट होता है जब दो नोड एक-दूसरे तक सीधे नहीं पहुँच पाते और DERP रिले का उपयोग करते हैं। शिप की गई कॉन्फ़िगरेशन के साथ, वे रिले Tailscale के सार्वजनिक रिले होते हैं। यह देखने के लिए कि कोई विशिष्ट पीयर direct है या relay पर है, किसी नोड पर tailscale status चलाएं।

रजिस्टर होने के बाद मेरा नोड ऑफ़लाइन क्यों रहता है?

एक नोड जो 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 पर कंट्रोल सर्वर चलाने का मतलब है कि इसके साथ होने वाली हर क्लाइंट बातचीत इंटरनेट पर बिना किसी सुरक्षा के जाती है।