headscale: स्वतःचा Tailscale control server चालवा

headscale म्हणजे काय

headscale ही Tailscale control server ची self-hosted अंमलबजावणी आहे. त्यामुळे तुमच्या private network चे समन्वयन करणारे machine तुमच्या मालकीचे VPS असते. हा community project आहे आणि तो Tailscale Inc. द्वारे चालवला जात नाही. प्रत्येक machine वर अधिकृत tailscale client चालतो. तो तुमच्या server कडे --login-server या एका flag ने निर्देशित केला जातो.

कोण network मध्ये समाविष्ट आहे हे control server ला माहीत असते. तो प्रत्येक node ला 100.64.0.0/10 मधील एक address देतो, public keys वितरित करतो आणि nodes ना एकमेकांना कुठे शोधायचे ते सांगतो. Tunnels WireGuard वरच राहतात आणि ते node-to-node तयार केले जातात. तुमच्या दोन machines मधील traffic headscale box मधून जात नाही. मात्र direct path तयार करता आला नाही आणि nodes relay कडे fallback झाले, तर traffic relay मधून जाऊ शकतो.

प्रत्येक instance साठी headscale एक tailnet म्हणजेच एक Tailscale network पुरवतो. Project च्या मते, हे वैयक्तिक वापरासाठी किंवा लहान organisation साठी योग्य आहे. तुमच्याकडे तीन किंवा चार machines असल्यास, तुमच्या मालकीच्या VPS वरील साधा WireGuard VPN चालवणे सोपे आहे. त्यासाठी कमी software व्यवस्थापित करावे लागते आणि बिघाडाची शक्यताही कमी असते. प्रत्येक नवीन laptop साठी [Peer] block हाताने लिहायची गरज उरत नाही, तेव्हा headscale उपयुक्त ठरतो. या दोन models ची व्यापक तुलना करण्यासाठी WireGuard आणि Tailscale मधील फरक पहा.

इंस्टॉल करण्यापूर्वी आवश्यक गोष्टी

• सार्वजनिक IPv4 पत्ता आणि sudo प्रवेश असलेला Ubuntu 24.04 चालणारा VPS. सर्व्हर नवीन असल्यास, आधी नवीन VPS वरील पहिली दहा मिनिटे पूर्ण करा.
• त्या पत्त्याकडे निर्देश करणारा DNS A रेकॉर्ड. या मार्गदर्शकात headscale.example.com वापरले आहे.
• MagicDNS साठी दुसरे डोमेन किंवा सबडोमेन. या मार्गदर्शकात tailnet.example.net वापरले आहे. हे server_url मधील डोमेनसारखेच नसावे.
• जोडण्यासाठी Linux, macOS, Windows, Android किंवा iOS चालणारे एक क्लायंट मशीन.

अधिकृत .deb मधून headscale स्थापित करा

प्रकल्प त्याची .deb पॅकेजेस GitHub releases पृष्ठावर प्रकाशित करतो. July 2026 पर्यंतची सध्याची release 0.29.3 आहे. प्रथम तुमची architecture तपासा, कारण file name मध्ये ती समाविष्ट असते.

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

File name च्या आधीचे ./ आवश्यक आहे. ते नसल्यास apt तुमच्या repositories मध्ये headscale.deb नावाचे package शोधते आणि अपयशी ठरते.

Package headscale system user तयार करते, default /etc/headscale/config.yaml लिहिते आणि systemd unit स्थापित करते. ते service सुरू करत नाही, आणि हाच योग्य क्रम आहे. वितरित configuration server_url ला http://127.0.0.1:8080 कडे निर्देशित करते. तुमच्या कोणत्याही client ला त्या पत्त्यावर पोहोचता येत नाही. त्यामुळे आत्ता सुरू केलेली service सुरू झाली तरी चुकीची असेल. या टप्प्यावर 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 प्रत्येक client registration मध्ये लिहितो तो पत्ता आहे. त्यानंतर clients नेमक्या त्या string शी कायम जोडले जातात. त्यामुळे येथे https:// च्या आधी public name असणे आवश्यक आहे; 127.0.0.1 कधीही वापरू नका.

listen_addr येथे process bind होतो. ते loopback वरच ठेवा. त्याच server वरील reverse proxy TLS (transport layer security) समाप्त करून विनंत्या त्याकडे पाठवतो. त्यामुळे server च्या बाहेरून port 8080 पर्यंत पोहोचण्याची गरज नाही.

base_domain हा MagicDNS suffix आहे. तुमच्या nodes ना ज्या domain अंतर्गत नावे मिळतात तो हा domain आहे. तो trailing dot नसलेला fully qualified domain name असणे आवश्यक आहे. तसेच तो server_url मधील domain पेक्षा वेगळा असावा. अन्यथा दोन्ही name spaces मध्ये संघर्ष निर्माण होईल.

Database section मध्ये कोणताही बदल करू नका. Default /var/lib/headscale/db.sqlite येथे SQLite आहे. हे package ने तयार करून त्याच्या मालकीच्या directory मध्ये आहे. या आकाराच्या 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 वापरून जर्नल वाचा. या टप्प्यावर अपयशाचे कारण जवळजवळ नेहमी कॉन्फिगरेशन फाइल असते, कारण socket उघडण्यापूर्वी headscale संपूर्ण फाइलचे विश्लेषण करते. त्यामुळे चुकीचे indentation किंवा अज्ञात key आढळल्यास, कोणताही process ऐकण्याच्या स्थितीत येण्यापूर्वीच थांबतो. फाइल दुरुस्त करा आणि नंतर sudo systemctl restart headscale चालवा. त्यानंतरच्या प्रत्येक कॉन्फिगरेशन बदलासाठीही हाच restart आवश्यक आहे. त्यानंतर clients आपोआप पुन्हा जोडले जातात. systemd units तुमच्यासाठी नवीन असल्यास, systemd वापरून स्वतःच्या services आणि timers चालवणे येथे वापरलेल्या commands चे वर्णन आहे.

shell मध्ये असताना state files तपासा:

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

दोन्ही ओळी headscale ने सुरू होतात. हा package ने तयार केलेला unprivileged user आहे. noise_private.key ही server ची clients साठीची ओळख आहे. ती जतन करा. ती delete केल्यास headscale नवीन ओळख निर्माण करतो आणि प्रत्येक node ला पुन्हा register करावे लागते.

headscale समोर TLS ठेवा

क्लायंटने server_url वर HTTPS द्वारे पोहोचले पाहिजे. 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

फाइलचे parsing यशस्वी झाल्यावर validate, adapted config to JSON दर्शवते. फाइलचे formatting झालेले नाही, असा इशारा केवळ स्वरूपाशी संबंधित आहे. तुमच्या लॅपटॉपवरून curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health ने देखील 200 दर्शवले पाहिजे. या एका तपासणीने DNS, firewall, प्रमाणपत्र आणि proxy एकत्रितपणे कार्यरत असल्याचे सिद्ध होते.

खालील proxy तपशीलामुळे अनेकांचा संपूर्ण संध्याकाळचा वेळ जातो. Tailscale control connection हे HTTP upgrade असते. ते GET ऐवजी POST ने सुरू केले जाते आणि Upgrade header चे मूल्य 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;
    }
}

या ओळी वगळल्यास सामान्य विनंत्या तरीही यशस्वी होतात. त्यामुळे /health 200 परत करते आणि सर्व काही योग्य दिसते. परंतु दीर्घकाळ चालणारे control connection कधीच तयार होत नाही. तुमचे nodes नोंदणी करून offline राहतात. 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 वरून क्लायंटचे सर्व संप्रेषण होते. पोर्ट 80 केवळ ACME (स्वयंचलित प्रमाणपत्र व्यवस्थापन वातावरण) HTTP challenge आणि HTTPS कडे redirect करण्यासाठी वापरले जाते. Caddy ला प्रमाणपत्र मिळवण्यासाठी ते आवश्यक आहे.

पोर्ट 8080 बंदच ठेवा. listen_addr हे 127.0.0.1:8080 आहे. त्यामुळे proxy loopback interface द्वारे headscale पर्यंत पोहोचतो आणि कोणत्याही firewall नियमाची आवश्यकता नसते. इंटरनेटसाठी पोर्ट 8080 उघडल्यास क्लायंटना cleartext control channel मिळतो, पण त्याचा कोणताही लाभ होत नाही. लक्षात ठेवा की बहुतेक providers त्यांच्या control panel मध्ये UFW पासून स्वतंत्र दुसरा firewall चालवतात. त्यामुळे server वर पोर्ट उघडे असले, तरी edge वर ते बंद असू शकते. VPS वरील UFW firewall ची मूलभूत माहिती मध्ये नियमांची syntax अधिक तपशीलाने दिली आहे.

वापरकर्ता आणि preauth key तयार करा

sudo headscale users create alice
sudo headscale users list

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

users list प्रत्येक नावासमोर एक ID छापते. तुम्हाला हा क्रमांक आवश्यक आहे, कारण key कमांडला नावाऐवजी संख्यात्मक user ID लागतो.

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

key एकदाच छापली जाते. ती आता कॉपी करा. preauth key एकदाच वापरता येते आणि तुम्ही वेगळे निर्दिष्ट केले नसल्यास ती one hour साठी वैध असते. त्यामुळे तुम्ही अजून testing करत असताना --expiration 24h सेट करणे उपयुक्त ठरते. अनेक machines enroll करणारी key तयार करण्यासाठी --reusable जोडा. त्या key कडे 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 चे मूल्य scheme सह आणि शेवटी slash न ठेवता server_url शी तंतोतंत जुळले पाहिजे. त्यांची string म्हणून तुलना केली जाते. विसंगती असल्यास क्लायंट एका पत्त्यावर नोंदणी करतो आणि नंतर त्याला दुसऱ्या पत्त्याशी संपर्क साधण्यास सांगितले जाते.

पूर्वी Tailscale च्या hosted service मध्ये साइन इन केलेली मशीन तो login कायम ठेवते. आधी तिच्यावर 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

तुमच्या स्वतःच्या laptop साठी ही पद्धत अधिक सोयीची आहे. स्क्रिप्टद्वारे चालवल्या जाणाऱ्या कोणत्याही गोष्टीसाठी preauth keys अधिक योग्य आहेत, कारण त्यावर लक्ष ठेवण्यासाठी कोणत्याही व्यक्तीची आवश्यकता नसते.

DERP आणि थेट मार्ग अयशस्वी झाल्यावर नेटवर्क ट्रॅफिक कोणते relay करते

DERP (designated encrypted relay for packets) हा पर्यायी मार्ग आहे. दोन nodes थेट WireGuard connection उघडू शकत नसतील, सामान्यतः दोन्ही strict NAT (network address translation) मागे असल्यामुळे, ते त्याऐवजी relay द्वारे packets पाठवतात. Relay कडे कोणत्याही 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 map मधून काढले जातात. कार्यरत embedded relay शिवाय असे केल्यास, जे nodes थेट connect होऊ शकत नाहीत ते एकमेकांशी अजिबात connect होऊ शकणार नाहीत.

Client कडून tailscale netcheck माहीत असलेल्या प्रत्येक relay region ची latency दाखवते. tailscale status प्रत्येक peer ला address असलेले direct किंवा region code असलेले relay म्हणून दर्शवते. relay वर अडकलेला peer ही NAT समस्या आहे, headscale ची समस्या नाही.

नोड offline का दिसतो?

प्रॉक्सी upgrade विनंती पुढे पाठवत नाही. हे सर्वसाधारण कारण आहे. याची लक्षणे अशी असतात: इतर सर्व गोष्टी व्यवस्थित दिसतात, /health 200 परत करते, headscale nodes list नोड दाखवते आणि नोड कधीही online होत नाही. नियंत्रण कनेक्शन हे Upgrade: tailscale-control-protocol असलेले POST असते. ते पुढे न पाठवणारी प्रॉक्सी नोडची स्थिती कळवणारा एकमेव channel बंद करते. तुमच्या nginx configuration ची वरील map block शी तुलना करा किंवा प्रॉक्सी हे कारण नाही हे तपासण्यासाठी Caddy वापरा.

नोड नोंदणीकृत झाल्यानंतर server_url बदलले. नोंदणीच्या वेळी दिलेल्या मूल्याशी नोड जोडण्याचा प्रयत्न करत राहतात. ते मूल्य संपादित केले असल्यास, प्रत्येक नोडवर sudo tailscale up --login-server https://headscale.example.com --force-reauth चालवा.

Client चालू नाही. नोडवर sudo systemctl is-active tailscaled आणि sudo journalctl -u tailscaled -n 50 --no-pager चालवा. तुमचा domain resolve किंवा reach न करू शकणारा client त्याच्या retry प्रयत्नांची नोंद तिथे करतो.

Key ची मुदत संपली. याचे स्पष्टीकरण पुढील विभागात आहे.

तुम्ही चाचणी करत असताना server side वर लक्ष ठेवण्यासाठी VPS वर sudo journalctl -u headscale -f चालवा आणि client वर tailscaled restart करा. headscale पर्यंत पोहोचणारा नोड लगेच log lines निर्माण करतो. काहीही नोंद होत नसेल, तर request पोहोचत नाही. त्यामुळे headscale तपासण्यापूर्वी DNS, firewall आणि proxy तपासा.

Key ची मुदत संपणे आणि काही आठवड्यांनंतर काम करणे थांबवणारा node

दोन स्वतंत्र मुदतसमाप्ती असतात. त्यांची गल्लत केल्यास वेळ वाया जातो.

Preauth keys ची मुदत डिझाइननुसार लवकर संपते. डीफॉल्ट एक तास आणि एक वापर असा आहे. tailscale up ने key नाकारल्यास, client वर काहीही संपादित करण्याऐवजी server वर नवीन key तयार करा.

Node keys हा दीर्घकालीन भाग आहे. config.yaml मधील node विभाग expiry: 0 सेट करतो. 0 म्हणजे डीफॉल्ट मुदतसमाप्ती नाही. नोंदणीकृत node ची मुदत तुम्ही संपवित नाही तोपर्यंत तो वैध राहतो. Tagged nodes ची मुदत कोणत्याही परिस्थितीत संपत नाही. Registrations ची मुदत आपोआप संपावी असे असल्यास expiry: 180d सेट करा आणि त्याचा परिणाम समजून घ्या: त्यानंतर प्रत्येक non-tagged node ला त्या वेळापत्रकानुसार sudo tailscale up --login-server https://headscale.example.com --force-reauth आवश्यक असेल. ज्या headless server वर कोणीही पुन्हा authentication करत नाही तो स्वतःहून 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

दोन्ही फाइल्स सर्व्हरच्या बाहेर हलवा. त्यांमध्ये private keys आणि सर्व registrations असतात, त्यामुळे त्यांची काळजी सर्व्हरइतकीच घ्या. VPS मधील restic बॅकअप मध्ये हे नियोजित वेळापत्रकानुसार आणि encryption सह कसे करायचे ते दिले आहे.

अपग्रेड करताना install प्रक्रिया पुन्हा करा: नवीन .deb, sudo apt install ./headscale.deb डाउनलोड करा, त्यानंतर सेवा पुन्हा सुरू करा आणि is-active व /health तपासण्या पुन्हा चालवा. 0.29 पासून अपग्रेडची प्रक्रिया कडक आहे. minor version वगळणे प्रतिबंधित आहे. जुन्या minor version वर downgrade करणेही प्रतिबंधित आहे. एका वेळी एकच minor version पुढे जा. प्रत्येक टप्प्यापूर्वी बॅकअप घ्या आणि त्या version च्या release notes आधी वाचा, कारण त्याच release मध्ये ACL policy च्या वर्तनात बदल झाला आणि अनेक configuration keys हलवण्यात आल्या.

FAQ

.deb स्थापित केल्यानंतर headscale लगेच सुरू का होत नाही?

पॅकेज unit स्थापित करते, परंतु service थांबवलेली ठेवते. तसेच, default /etc/headscale/config.yaml ही कार्यरत configuration नसून template असते. प्रथम 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 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 मध्ये उपलब्ध आहे. त्यामुळे patching किंवा rebuilding आवश्यक नाही.

माझा traffic headscale server मधून जातो का?

सामान्यतः नाही. Headscale network चे coordination करते आणि keys व addresses वितरित करते. Data path मात्र तुमच्या nodes दरम्यान थेट WireGuard द्वारे असतो. दोन nodes एकमेकांपर्यंत थेट पोहोचू शकत नसतील, तरच traffic DERP relay कडे वळतो. Shipped configuration मध्ये हे relays Tailscale चे public relays असतात. एखादा peer direct आहे की relay वर आहे हे पाहण्यासाठी node वर tailscale status चालवा.

माझा node register झाल्यानंतर offline का राहतो?

headscale nodes list मध्ये दिसणारा node online होत नसेल, तर reverse proxy वरील control connection तुटलेली असण्याची शक्यता असते. ही connection Upgrade: tailscale-control-protocol header सह पाठवलेली HTTP upgrade request असते. nginx मध्ये map $http_upgrade $connection_upgrade block आणि त्याला अनुरूप proxy_set_header lines जोडल्या नाहीत, तर nginx ही request टाकून देते. Caddy कोणत्याही अतिरिक्त configuration शिवाय ती forward करते. त्यामुळे proxy कारणीभूत आहे का हे तपासण्यासाठी Caddy हा जलद पर्याय आहे.

headscale साठी domain name आणि TLS आवश्यक आहेत का?

प्रत्यक्षात, होय. Clients server_url मध्ये दिलेल्या string शी connect होतात. Certificates names साठी जारी केली जातात; bare IP addresses साठी नाही. तसेच configuration file मध्ये DERP साठी TLS आवश्यक असल्याचे नमूद केले आहे. Domain आणि Caddy वापरल्यास setup सुमारे पाच मिनिटांत पूर्ण होते आणि स्वतः renew होणारा HTTPS endpoint मिळतो. Control server plain HTTP वर चालवल्यास, त्याच्याशी प्रत्येक client चे संभाषण internet वरून unencrypted स्वरूपात जाते.