Headscale का उपयोग करके अपना Tailscale सर्वर कैसे बनाएं

Headscale क्या है

Headscale, Tailscale control server का एक self-hosted implementation है, जिसका अर्थ है कि आपके private network को coordinate करने वाली मशीन आपका अपना VPS है। यह एक community project है और इसे Tailscale Inc. द्वारा नहीं चलाया जाता है। प्रत्येक मशीन अभी भी आधिकारिक tailscale client चलाती है, जिसे एक flag, --login-server के साथ आपके सर्वर की ओर point किया जाता है।

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

Headscale प्रत्येक instance के लिए एक tailnet (एक Tailscale network) उपलब्ध कराता है। Project के अनुसार यह व्यक्तिगत उपयोग या छोटे organisation के लिए उपयुक्त है। तीन या चार machines के लिए आपके अपने VPS पर plain WireGuard VPN चलाना कम software मांगता है और इसमें खराबी की संभावनाएँ भी कम रहती हैं। Headscale तब उपयोगी होता है जब आप हर नए laptop के लिए हाथ से [Peer] block लिखना नहीं चाहते। शुरुआत में लोग अक्सर cost के कारण विकल्प तलाशते हैं। इसलिए server लेने से पहले hosted free plan में वास्तव में क्या शामिल है पढ़ना उचित है, क्योंकि कुछ personal machines आम तौर पर उसकी सीमा में आ जाती हैं। यदि आप पहले ही उस सीमा से आगे हैं, तो प्रति user और tagged resource paid plans की लागत के आधार पर कुल लागत निकालें। User devices unlimited होते हैं, जबकि tagged resources के लिए अलग allowances और charges होते हैं। यदि आप self-hosted control plane चाहते हैं, लेकिन Tailscale के drop-in replacement के बजाय peers manage करने के लिए अपना client और web interface पसंद करेंगे, तो एक single VPS पर NetBird विचार करने योग्य alternative है। दोनों आपका traffic WireGuard के माध्यम से भेजते हैं। इसलिए चुनाव इस बात पर निर्भर करता है कि आप access rules कैसे लिखते हैं और relays कैसे व्यवहार करते हैं। Install करने से पहले इन बिंदुओं पर NetBird और Tailscale की तुलना करना उपयोगी है। दोनों models की व्यापक तुलना के लिए 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 पर चल रही हो। Headscale 0.29.6 के लिए Tailscale client version 1.80.0 या उससे नया होना आवश्यक है।

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

यह प्रोजेक्ट अपने GitHub releases पेज पर .deb पैकेज प्रकाशित करता है। 27 अक्टूबर, 2026 तक नवीनतम स्टेबल रिलीज़ 0.29.6 है, जिसे 24 अक्टूबर, 2026 को रिलीज़ किया गया था। पहले अपने आर्किटेक्चर की जाँच करें, क्योंकि फ़ाइल नाम में यह जानकारी होती है।

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

यह एक सामान्य x86 VPS पर amd64 प्रिंट करता है और Ampere या Graviton स्टाइल प्लान पर arm64 प्रिंट करता है। उत्तर को नीचे दिए गए वेरिएबल में रखें।

HEADSCALE_VERSION="0.29.6"
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 यूनिट इंस्टॉल करता है, और फिर सर्विस शुरू करता है। इसलिए जब apt कमांड पूरी होती है, तब headscale पहले से ही चल रहा होता है, और sudo systemctl is-active headscale कमांड active प्रिंट करती है। हालाँकि, फ्रेश इंस्टॉल पर पैकेज यूनिट को इनेबल नहीं करता है, इसलिए रीबूट के बाद सर्विस तब तक वापस नहीं आएगी जब तक आप इसे इनेबल नहीं करते, जो नीचे दिए गए रीस्टार्ट स्टेप में किया गया है। यह शिप की गई कॉन्फ़िगरेशन पर भी चल रहा है, और वह server_url को http://127.0.0.1:8080 पर पॉइंट करता है, जो ऐसा पता नहीं है जिसे आपका कोई भी क्लाइंट एक्सेस कर सके। अभी कुछ भी एक्सपोज़ नहीं हुआ है, क्योंकि शिप किया गया listen_addr भी लूपबैक पर है, लेकिन जब तक आप server_url सेट नहीं कर लेते और सर्विस को रीस्टार्ट नहीं कर लेते, तब तक किसी भी क्लाइंट को जॉइन न करें, जो अगले दो स्टेप्स में किया गया है।

किसी भी client के जुड़ने से पहले 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 पंजीकरण URL बनाते समय करता है। Clients --login-server के साथ कॉन्फ़िगर किए गए control पते का उपयोग करते हैं, इसलिए दोनों स्थानों पर https:// के साथ एक ही सार्वजनिक नाम का उपयोग करें, कभी भी 127.0.0.1 का नहीं। Headscale का दस्तावेज़ीकरण कहता है कि plain HTTP, या 443 के अलावा किसी अन्य पोर्ट पर HTTPS संभव है, लेकिन यह production के लिए पोर्ट 443 पर HTTPS की पुरज़ोर अनुशंसा करता है, और यह गाइड इसी आधार पर आगे बढ़ती है।

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

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

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

Headscale को रीस्टार्ट करें और सुनिश्चित करें कि यह चल रहा है

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

is-active कमांड active प्रिंट करता है, is-enabled कमांड enabled प्रिंट करता है, और curl कमांड 200 प्रिंट करता है। रीस्टार्ट वह चरण है जो आपके द्वारा किए गए बदलावों को लोड करता है। Headscale अपनी कॉन्फ़िगरेशन को केवल एक बार पढ़ता है, जब वह शुरू होता है, इसलिए पैकेज द्वारा शुरू की गई प्रक्रिया तब तक पुराने server_url का उपयोग करती रहती है जब तक आप उसे रीस्टार्ट नहीं करते। sudo systemctl enable --now headscale यह काम नहीं करता है: सर्विस पहले से ही चल रही है, इसलिए --now स्टार्ट करने से कुछ नहीं बदलता और पुरानी वैल्यू ही सक्रिय रहती है। बूट पर सर्विस शुरू करना enable का काम है, और यह आपके लिए अपने आप नहीं होता: नए इंस्टॉलेशन पर पैकेज सर्विस को इनेबल किए बिना शुरू कर देता है, इसलिए ऊपर बताए अनुसार sudo systemctl enable headscale को एक बार चलाएं।

यदि is-active कमांड active के अलावा कुछ भी प्रिंट करता है, या curl कमांड 200 प्रिंट नहीं करता है, तो sudo journalctl -u headscale -n 50 --no-pager के साथ जर्नल पढ़ें। इस चरण पर विफलता लगभग हमेशा कॉन्फ़िगरेशन फ़ाइल के कारण होती है, क्योंकि headscale सॉकेट खोलने से पहले पूरी फ़ाइल को पार्स करता है। इसलिए, गलत इंडेंट या कोई अमान्य आवश्यक सेटिंग प्रक्रिया को सॉकेट लिसन करने से पहले ही रोक देती है। फ़ाइल को ठीक करें, फिर 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 एक नई पहचान बनाता है और क्लाइंट्स को फिर से कनेक्ट होने से पहले नई सर्वर की (key) प्राप्त करनी होगी; मौजूदा रजिस्ट्रेशन डेटाबेस में बने रहते हैं।

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 प्रिंट करता है। यह चेतावनी कि file formatted नहीं है, केवल दिखावटी है। आपके 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 का मान tailscale-control-protocol होता है। Caddy इसे बिना किसी अतिरिक्त configuration के पास कर देता है। nginx ऐसा नहीं करता है, इसलिए nginx front end को Upgrade और Connection headers को स्पष्ट रूप से forward करना पड़ता है। Headscale documentation इसे एक 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;
    }
}

उन पंक्तियों को छोड़ दें तो सामान्य अनुरोध अभी भी सफल होते हैं, यही कारण है कि /health 200 return करता है और सब कुछ ठीक दिखता है, जबकि control connection कभी नहीं बनता है: नए nodes register नहीं हो सकते, और मौजूदा nodes reconnect होकर online रिपोर्ट नहीं कर सकते। यदि आप nginx का रास्ता चुनते हैं, तो nginx के साथ Ubuntu 24.04 पर 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 प्रत्येक client का headscale के साथ control connection संभालता है। यदि आप बाद में embedded DERP relay सक्षम करते हैं, तो उसे 3478/udp की भी आवश्यकता होगी, जिसका विवरण नीचे दिया गया है। Port 80 का उपयोग ACME (automatic certificate management environment) HTTP challenge और HTTPS पर redirect करने के लिए किया जाता है। Caddy port 80 बंद होने पर भी certificate प्राप्त कर सकता है, क्योंकि यह port 443 पर TLS-ALPN challenge का उपयोग कर सकता है, लेकिन 80 खुला होने पर दोनों challenges उपलब्ध रहते हैं और साधारण http:// requests redirect हो जाती हैं।

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

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

sudo headscale users create alice
sudo headscale users list

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

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

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

key केवल एक बार प्रिंट होती है। इसे अभी copy कर लें। एक preauth key का उपयोग केवल एक बार किया जा सकता है और यह एक घंटे के लिए वैध होती है, जब तक कि आप अन्यथा न कहें, इसलिए 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 से प्राप्त पब्लिक HTTPS पते का उपयोग करें। क्लाइंट अपने कंट्रोल URL से अंत में लगे स्लैश (trailing slashes) को हटा देता है; ऐसी कोई सटीक स्ट्रिंग तुलना नहीं है जिसके लिए आपको इसे हटाना आवश्यक हो।

जो मशीन पहले 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 कमांड के साथ सर्वर पर एडवर्टाइज्ड रूट को अप्रूव करते हैं। यदि आप इंटरनेट तक जाने के बजाय उस VPS के पीछे स्थित प्राइवेट नेटवर्क तक पहुंच चाहते हैं, तो वही अप्रूवल स्टेप उस सबनेट को बाकी टेलनेट (tailnet) में एडवर्टाइज करने के लिए काम आता है। किसी नोड से पूरे नेटवर्क को रूट करने के बजाय किसी एक एप्लिकेशन को पब्लिश करना एक अलग कार्य है, और serve और funnel इसे करने के दो तरीके हैं, हालांकि दोनों Tailscale के अपने सर्टिफिकेट और इनग्रेस मशीनरी पर निर्भर करते हैं, इसलिए उन्हें होस्टेड-टेलनेट फीचर्स के रूप में पढ़ें, न कि ऐसी चीज के रूप में जो headscale आपको प्रदान करता है।

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

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

डिफ़ॉल्ट कॉन्फ़िगरेशन क्या करता है, इसे लेकर स्पष्ट रहें। 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 सेट करें, शिप किए गए ipv4: 198.51.100.1 और ipv6: 2001:db8::1 को अपने relay के public addresses से बदलें, या DNS का उपयोग करने के लिए दोनों सेटिंग्स को हटा दें, फिर headscale को restart करें और sudo ufw allow 3478/udp के साथ STUN (session traversal utilities for NAT) port खोलें। वे address सेटिंग्स DNS को override कर देती हैं, इसलिए किसी भी placeholder को वैसे ही छोड़ देने से clients एक unreachable address पर चले जाते हैं। कॉन्फ़िगरेशन फ़ाइल आवश्यकता को स्पष्ट रूप से बताती है: server_url को https का उपयोग करना चाहिए, क्योंकि DERP के लिए TLS आवश्यक है। derp.urls सूची को खाली करने से Tailscale के relays map से हट जाते हैं; ऐसा करने से पहले एक कार्यशील embedded या custom relay सुनिश्चित करें। Headscale एक खाली relay map के साथ start होने से मना कर देता है, और केवल एक unreachable relay वाला map उन nodes को संचार करने में असमर्थ छोड़ देता है जो सीधे connect नहीं हो सकते।

एक client से, tailscale netcheck उन सभी relay regions की latency प्रिंट करता है जिनके बारे में वह जानता है, और tailscale status सक्रिय peer connections के लिए address के साथ direct या region code के साथ relay दिखाता है। relay पर अटके हुए peer के लिए उसके सीधे रास्ते की जाँच करने की आवश्यकता होती है, जिसमें NAT और firewall rules शामिल हैं। एक peer जो direct है और फिर भी धीमा है, वह एक अलग समस्या है, और वहाँ सामान्य उत्तर tunnel के बजाय MTU होता है।

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

प्रॉक्सी अपग्रेड को ड्रॉप कर रही है। इसका संकेत यह है कि /health 200 रिटर्न करता है, जबकि नए रजिस्ट्रेशन विफल हो जाते हैं या मौजूदा नोड फिर से कनेक्ट नहीं हो पाते हैं। कंट्रोल कनेक्शन एक POST है जो Upgrade: tailscale-control-protocol को ले जाता है, और जो प्रॉक्सी इसे फॉरवर्ड नहीं करती, वह रजिस्ट्रेशन और नोड स्टेट रिपोर्ट करने वाले चैनल, दोनों को ब्लॉक कर देती है। अपने nginx कॉन्फ़िगरेशन की तुलना ऊपर दी गई अपग्रेड लाइनों से करें, या प्रॉक्सी को समस्या से बाहर करने के लिए Caddy पर स्विच करें।

पब्लिक कंट्रोल एड्रेस बदल गया है। नोड --login-server के साथ कॉन्फ़िगर किए गए एड्रेस पर डायल करना जारी रखते हैं; 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 तक पहुँचने वाले हर अनुरोध के लिए डिफ़ॉल्ट लॉग लेवल पर लाइन जनरेट होना सुनिश्चित नहीं है, इसलिए केवल सर्वर लॉग का शांत होना DNS, फ़ायरवॉल या प्रॉक्सी की विफलता का प्रमाण नहीं है।

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

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

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

Node keys लंबे समय तक चलने वाला हिस्सा हैं। config.yaml का node सेक्शन expiry: 0 को सेट करता है, और 0 का अर्थ है कि कोई डिफ़ॉल्ट expiry नहीं है; फिर भी एक स्पष्ट client expiry या OIDC expiry लागू हो सकती है। Tagged nodes स्वचालित expiry से मुक्त होते हैं, हालाँकि एक administrator उन्हें स्पष्ट रूप से expire कर सकता है। यदि आप non-tagged registrations के लिए 180-दिन की डिफ़ॉल्ट अवधि चाहते हैं तो expiry: 180d सेट करें, लेकिन client द्वारा अनुरोधित expiry को प्राथमिकता दी जाती है और OIDC डिफ़ॉल्ट को override कर सकता है। इस सेटिंग को बदलने से मौजूदा registrations में पूर्वव्यापी (retroactively) बदलाव नहीं होता। जिस node की expiry तय है, उसे उस समय सीमा से पहले sudo tailscale up --login-server https://headscale.example.com --force-reauth का उपयोग करके फिर से authenticate करने की आवश्यकता होती है, और एक headless सर्वर जिसे कोई re-authenticate नहीं करता, वह registration expire होने पर नेटवर्क से हट जाएगा।

जब किसी का 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

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

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

FAQ

क्या .deb इंस्टॉल करने के तुरंत बाद headscale चल रहा होता है?

हाँ। पैकेज इंस्टॉल होते ही सर्विस को डिफ़ॉल्ट /etc/headscale/config.yaml पर शुरू कर देता है, जो केवल loopback पर listen करती है और server_url को http://127.0.0.1:8080 पर सेट करती है। फ्रेश इंस्टॉलेशन पर यह सर्विस को enable नहीं करता है, इसलिए जब तक आप sudo systemctl enable headscale नहीं चलाते, यह बूट के समय शुरू नहीं होगी। डिफ़ॉल्ट एड्रेस क्लाइंट्स के लिए अनुपयोगी है, इसलिए server_url, listen_addr और base_domain को एडिट करें, फिर sudo systemctl restart headscale चलाएं और sudo systemctl is-active headscale के साथ पुष्टि करें। इसे restart होना चाहिए: headscale फ़ाइल को केवल शुरू होते समय पढ़ता है, और पहले से चल रही सर्विस पर enable --now इसे बूट के लिए enable तो कर देता है लेकिन रीस्टार्ट नहीं करता, जिससे पुरानी वैल्यूज ही सक्रिय रहती हैं। यदि रीस्टार्ट के बाद यह विफल हो जाता है, तो 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 के पब्लिक रिले होते हैं। यह देखने के लिए कि कोई विशिष्ट पीयर direct है या relay पर, किसी नोड पर tailscale status चलाएं।

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

जो नोड headscale nodes list में दिखाई देता है लेकिन कभी ऑनलाइन नहीं होता, उसके कंट्रोल कनेक्शन की जाँच करने की आवश्यकता है, जिसमें रिवर्स प्रॉक्सी भी शामिल है। वह कनेक्शन एक HTTP अपग्रेड है जिसे Upgrade: tailscale-control-protocol हेडर के साथ POST के रूप में भेजा जाता है, और nginx इसे तब तक ड्रॉप कर देता है जब तक आप Upgrade और Connection हेडर्स को proxy_set_header के साथ स्पष्ट रूप से फॉरवर्ड नहीं करते, जिसे ऊपर दिया गया कॉन्फ़िगरेशन अपने map $http_upgrade $connection_upgrade ब्लॉक के माध्यम से करता है। उन हेडर्स को ड्रॉप करने से नए नोड्स को रजिस्टर होने से भी रोका जा सकता है। Caddy इसे बिना किसी अतिरिक्त कॉन्फ़िगरेशन के फॉरवर्ड करता है, जिससे यह परीक्षण करने का एक त्वरित तरीका बन जाता है कि क्या प्रॉक्सी में कोई खराबी है।

क्या मुझे headscale के लिए डोमेन नाम और TLS की आवश्यकता है?

इस सेटअप के लिए, हाँ: डोमेन नाम और HTTPS का उपयोग करें। सर्टिफिकेट्स बेयर IP एड्रेस को भी कवर कर सकते हैं, लेकिन कॉन्फ़िगरेशन फ़ाइल बताती है कि DERP के लिए TLS आवश्यक है। एक डोमेन और Caddy में लगभग पाँच मिनट लगते हैं और आपको एक HTTPS एंडपॉइंट मिलता है जो खुद को रिन्यू करता है। सादा HTTP संभव है, लेकिन headscale का डॉक्यूमेंटेशन प्रोडक्शन के लिए पोर्ट 443 पर HTTPS की पुरजोर सिफारिश करता है, और ध्यान दिलाता है कि Tailscale क्लाइंट कुछ स्थितियों में पोर्ट 443 पर HTTPS मानकर चलता है।