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 में अंतर देखें।

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

• 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 है। पहले अपने आर्किटेक्चर की जाँच करें, क्योंकि फ़ाइल नाम में यह जानकारी होती है।

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 वह स्थान है जहाँ प्रक्रिया बाइंड होती है। इसे लूपबैक पर ही रहने दें। उसी सर्वर पर स्थित एक रिवर्स प्रॉक्सी TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) को समाप्त करती है और इसे फॉरवर्ड करती है, इसलिए सर्वर के बाहर किसी भी चीज़ को पोर्ट 8080 तक पहुँचने की आवश्यकता नहीं है।

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

डेटाबेस सेक्शन को न बदलें। डिफ़ॉल्ट रूप से यह /var/lib/headscale/db.sqlite पर SQLite है, जो एक ऐसी डायरेक्टरी में है जिसे पैकेज ने बनाया है और जिसका वह स्वामी है, और इस आकार के टेलनेट (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 दोनों काम करता है: यह सर्विस को शुरू करता है और इसे रीबूट के बाद शुरू होने के लिए मार्क करता है।

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

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

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

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

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

Port 443 सभी क्लाइंट संचार को संभालता है। Port 80 केवल ACME (automatic certificate management environment) HTTP चैलेंज और HTTPS पर रीडायरेक्ट करने के लिए आवश्यक है, और Caddy को सर्टिफिकेट प्राप्त करने के लिए इसकी आवश्यकता होती है।

Port 8080 को बंद रखें। listen_addr, 127.0.0.1:8080 है, इसलिए प्रॉक्सी loopback इंटरफ़ेस के माध्यम से headscale तक पहुँचती है और इसमें किसी फ़ायरवॉल नियम की आवश्यकता नहीं होती है। 8080 को इंटरनेट के लिए खोलने से क्लाइंट्स को एक क्लियरटेक्स्ट कंट्रोल चैनल मिल जाता है और इससे कोई लाभ नहीं होता है। ध्यान रखें कि अधिकांश प्रदाता अपने कंट्रोल पैनल में UFW से अलग एक दूसरा फ़ायरवॉल चलाते हैं, इसलिए एक पोर्ट सर्वर पर खुला हो सकता है लेकिन नेटवर्क के किनारे पर बंद हो सकता है। VPS पर UFW फ़ायरवॉल की बुनियादी जानकारी में नियम सिंटैक्स के बारे में विस्तार से बताया गया है।

एक उपयोगकर्ता और एक प्री-ऑथ (preauth) कुंजी बनाना

sudo headscale users create alice
sudo headscale users list

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

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

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

कुंजी केवल एक बार प्रिंट की जाती है। इसे अभी कॉपी करें। एक प्री-ऑथ कुंजी एक बार उपयोग के लिए होती है और एक घंटे तक मान्य रहती है जब तक कि आप अन्यथा न कहें, इसलिए परीक्षण के दौरान --expiration 24h सेट करना उपयोगी है। ऐसी कुंजी के लिए --reusable जोड़ें जो कई मशीनों को एनरोल (enroll) करती है, और इसे पासवर्ड की तरह सुरक्षित रखें, क्योंकि इसे रखने वाला कोई भी व्यक्ति आपके नेटवर्क से जुड़ सकता है।

अपना पहला क्लाइंट --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) किसी भी स्क्रिप्टेड कार्य के लिए बेहतर होती हैं, क्योंकि किसी व्यक्ति को इसे मॉनिटर करने की आवश्यकता नहीं होती है।

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 रिटर्न करता है, 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, फ़ायरवॉल और प्रॉक्सी की जांच करें।

कुंजी की समाप्ति, और वह नोड जो हफ्तों बाद काम करना बंद कर देता है

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

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

Node कुंजियाँ लंबे समय तक चलने वाला हिस्सा हैं। config.yaml का node अनुभाग expiry: 0 को सेट करता है, और 0 का अर्थ है कोई डिफ़ॉल्ट समाप्ति नहीं: एक पंजीकृत नोड तब तक वैध रहता है जब तक आप उसे समाप्त नहीं करते। Tagged नोड्स कभी भी समाप्त नहीं होते हैं। यदि आप चाहते हैं कि पंजीकरण एक समय के बाद समाप्त हो जाए, तो expiry: 180d सेट करें, और समझें कि आप क्या मांग रहे हैं: तब प्रत्येक गैर-टैग किए गए नोड को उस समय-सीमा पर sudo tailscale up --login-server https://headscale.example.com --force-reauth की आवश्यकता होगी, और एक हेडलेस सर्वर जिसे कोई भी पुनः प्रमाणित नहीं करता है, वह अपने आप नेटवर्क से बाहर हो जाएगा।

जब कोई अपना लैपटॉप खो देता है, तो इसे मैन्युअल रूप से करें। sudo headscale nodes list आपको ID देता है, फिर sudo headscale nodes expire -i 3 उस नोड को लॉग आउट कर देता है, और 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

दोनों फाइलों को सर्वर से बाहर कहीं और ले जाएं। इनमें प्राइवेट कीज़ (private keys) और सभी रजिस्ट्रेशन मौजूद होते हैं, इसलिए इन्हें सर्वर के समान ही सुरक्षित रखना आवश्यक है। VPS से restic बैकअप में इन्हें शेड्यूल के अनुसार और एन्क्रिप्टेड तरीके से बैकअप करने की जानकारी दी गई है।

अपग्रेड करने के लिए इंस्टॉलेशन प्रक्रिया को दोहराएं: नया .deb और sudo apt install ./headscale.deb डाउनलोड करें, फिर रीस्टार्ट करें और is-active तथा /health चेक को दोबारा चलाएं। 0.29 वर्ज़न के बाद से अपग्रेड पाथ सख्त है। किसी माइनर वर्ज़न को छोड़ना (skip करना) प्रतिबंधित है, और पुराने माइनर वर्ज़न पर डाउनग्रेड करना भी संभव नहीं है। एक बार में केवल एक माइनर वर्ज़न आगे बढ़ें, हर चरण से पहले बैकअप लें, और उस वर्ज़न के रिलीज़ नोट्स पहले पढ़ें, क्योंकि उसी रिलीज़ में ACL पॉलिसी के व्यवहार में बदलाव किया गया था और कई कॉन्फ़िगरेशन कीज़ (configuration keys) को स्थानांतरित किया गया था।

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 नेटवर्क का समन्वय करता है और कुंजियाँ तथा पते प्रदान करता है, जबकि डेटा पाथ आपके नोड्स के बीच सीधे 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 पर चलाने का मतलब है कि इसके साथ होने वाली हर क्लाइंट बातचीत इंटरनेट पर स्पष्ट रूप से (बिना एन्क्रिप्शन के) जाती है।