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

headscale म्हणजे काय

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

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

प्रत्येक instance मध्ये headscale एक tailnet (एक Tailscale network) सेवा देते. Project च्या मते, हे वैयक्तिक वापरासाठी किंवा छोट्या संस्थेसाठी योग्य आहे. तुमच्याकडे तीन किंवा चार machines असतील, तर तुमच्या मालकीच्या VPS वर plain WireGuard VPN चालवणे म्हणजे कमी software चालवावे लागेल आणि बिघाडाच्या शक्यता कमी राहतील. प्रत्येक नवीन laptop साठी [Peer] block हाताने लिहायची गरज उरू नये, तेव्हा headscale उपयुक्त ठरते. तुम्हाला self-hosted control plane हवे असेल, पण Tailscale च्या drop-in replacement ऐवजी स्वतःचा client आणि peers व्यवस्थापित करण्यासाठी web interface हवे असेल, तर एका VPS वर NetBird हा विचार करण्यासारखा पर्याय आहे. या दोन models ची व्यापक तुलना पाहण्यासाठी WireGuard आणि Tailscale मधील फरक पहा.

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

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

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

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

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

हे package headscale system user तयार करते, default /etc/headscale/config.yaml लिहिते आणि systemd unit स्थापित करते. ते सेवा सुरू करत नाही, आणि हीच योग्य क्रमवारी आहे. वितरित configuration server_url ला http://127.0.0.1:8080 कडे निर्देशित करते. या पत्त्यावर तुमचा कोणताही client पोहोचू शकत नाही. त्यामुळे आत्ता सुरू केलेली सेवा सुरू झाली तरी चुकीची configuration वापरेल. या टप्प्यावर sudo systemctl is-active headscale चालवल्यास inactive छापले जाते. हे अपेक्षित आहे; ही त्रुटी नाही.

सेवा सुरू करण्यापूर्वी server_url कॉन्फिगर करा

/etc/headscale/config.yaml फाइल sudo nano /etc/headscale/config.yaml वापरून संपादित करा किंवा sed वापरून तेच तीन बदल लागू करा. मूळ फाइलची प्रत जतन करा, कारण ती मोठी आणि भरपूर टिप्पण्यांसह आहे. उर्वरित settings साठी तीच तुमच्याकडील सर्वोत्तम संदर्भ आहे.

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 अंतर्गत names मिळतात. तो trailing dot नसलेला fully qualified domain name असणे आवश्यक आहे. तसेच तो server_url मधील domain पेक्षा वेगळा असला पाहिजे, कारण अन्यथा दोन्ही name spaces मध्ये conflict होईल.

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 ही दोन्ही कामे करते: ती सेवा सुरू करते आणि reboot नंतर सुरू होण्यासाठी तिला enable करते.

is-active मध्ये failed छापले असल्यास, sudo journalctl -u headscale -n 50 --no-pager वापरून journal वाचा. या टप्प्यावर अपयशाचे कारण जवळजवळ नेहमी configuration file असते. कारण socket उघडण्यापूर्वी headscale संपूर्ण file parse करते. त्यामुळे चुकीचे indentation किंवा अज्ञात key असल्यास process कोणत्याही port वर listening सुरू करण्यापूर्वीच थांबतो. 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 ही server ची clients साठीची identity आहे. ती जतन करा. ती delete केल्यास headscale नवीन identity generate करते आणि प्रत्येक node ला पुन्हा register करावे लागते.

headscale समोर TLS ठेवा

क्लायंटने server_url पर्यंत HTTPS द्वारे पोहोचले पाहिजे. Caddy हा सर्वात सोपा मार्ग आहे, कारण तो स्वतः प्रमाणपत्राची विनंती करतो आणि त्याचे नूतनीकरण करतो.

sudo apt install -y caddy

/etc/caddy/Caddyfile च्या जागी headscale दस्तऐवजीकरणातील 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 दाखवते. फाइलचे formatting केलेले नाही अशी warning केवळ cosmetic आहे. तुमच्या laptop वरूनही 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 ची 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 पाहा.

UFW मध्ये कोणते पोर्ट उघडावे

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

443 पोर्टवर प्रत्येक client चे communication वाहून नेले जाते. 80 पोर्टचा वापर फक्त ACME (automatic certificate management environment) HTTP challenge आणि HTTPS कडे redirect करण्यासाठी होतो. Caddy ला प्रमाणपत्र मिळवण्यासाठीही हे पोर्ट आवश्यक आहे.

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

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

sudo headscale users create alice
sudo headscale users list

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

users list प्रत्येक नावाच्या बाजूला एक ID दाखवतो. तुम्हाला तो क्रमांक आवश्यक आहे, कारण key command मध्ये नावाऐवजी numeric user ID द्यावा लागतो.

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

key एकदाच दाखवली जाते. ती आता copy करा. preauth key single-use असते आणि तुम्ही वेगळे सांगितले नाही, तर ती one hour साठी valid असते. त्यामुळे तुम्ही अजून testing करत असताना --expiration 24h सेट करणे योग्य आहे. अनेक machines enroll करणारी key तयार करण्यासाठी --reusable जोडा. त्या key कडे password प्रमाणे सुरक्षिततेने पाहा, कारण ती ज्याच्याकडे असेल तो तुमच्या network मध्ये join होऊ शकतो.

--login-server वापरून पहिला client कनेक्ट करा

ज्या मशीनला जोडायचे आहे त्या मशीनवर:

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 असा असतो. त्यानंतर server वर sudo headscale nodes list node चा ID, user आणि online स्थिती दाखवते.

--login-server चे मूल्य server_url शी तंतोतंत जुळले पाहिजे. यात scheme समाविष्ट असावी आणि शेवटी slash नसावा. त्यांची string म्हणून तुलना केली जाते. विसंगती असल्यास client एका पत्त्यावर register होतो आणि त्यानंतर त्याला दुसऱ्या पत्त्यावर संपर्क साधण्यास सांगितले जाते.

पूर्वी Tailscale च्या hosted service मध्ये sign in केलेल्या मशीनवर तो login कायम राहतो. अशा मशीनवर आधी sudo tailscale logout चालवा. त्यानंतर --login-server सह tailscale up चालवा.

--auth-key वगळल्यास client त्याऐवजी एक URL दाखवतो. तो उघडा. त्या पृष्ठावर त्या registration प्रयत्नाचा identifier दिसतो. तो server वर approve करा:

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

तुमच्या स्वतःच्या laptop साठी ही पद्धत अधिक सोयीची आहे. Script द्वारे चालणाऱ्या कोणत्याही कामासाठी preauth keys अधिक योग्य आहेत, कारण त्यावर लक्ष ठेवण्यासाठी कोणत्याही व्यक्तीची आवश्यकता नसते. VPS स्वतः node झाल्यानंतर तो तुमच्या इतर मशीनचा internet traffic देखील वाहून नेऊ शकतो. यालाच exit node setup म्हणतात. फरक एवढाच की advertised route ला hosted admin console मध्ये नव्हे, तर server वर headscale command वापरून approve करावे लागते.

DERP आणि direct path अयशस्वी झाल्यावर network traffic relay करणारी यंत्रणा

DERP (designated encrypted relay for packets) हा fallback path आहे. दोन nodes direct WireGuard connection उघडू शकत नसतील, विशेषतः दोन्ही strict NAT (network address translation) मागे असतील, तर ते packets relay मार्फत पाठवतात. Relay कडे कोणत्याही keys नसतात. त्यामुळे तो तुमचा traffic वाचू शकत नाही. मात्र कोणते nodes एकमेकांशी संवाद साधत आहेत आणि किती data transfer होत आहे, हे त्याला दिसते.

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 शिवाय असे केल्यास, direct connection करू न शकणारे कोणतेही दोन nodes एकमेकांशी अजिबात connect होऊ शकणार नाहीत.

क्लायंटकडून tailscale netcheck त्याला ज्ञात असलेल्या प्रत्येक relay region पर्यंतचा latency दाखवते. tailscale status प्रत्येक peer ला पत्ता असलेल्या direct किंवा region code असलेल्या relay पैकी एक म्हणून चिन्हांकित करते. relay वर अडकलेला peer ही NAT ची समस्या आहे; headscale ची नाही. direct असलेला peer अजूनही slow असल्यास तो वेगळा प्रश्न आहे. अशा वेळी नेहमीचे कारण tunnel नसून MTU असते.

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

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

नोड नोंदणीकृत झाल्यानंतर server_url बदलले. नोड नोंदणीच्या वेळी दिलेल्या मूल्याशी पुन्हा पुन्हा connection करण्याचा प्रयत्न करतात. ते मूल्य संपादित केले असल्यास, प्रत्येक नोडवर 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 तेथे त्याचे retries log करतो.

Key कालबाह्य झाली. याचे स्पष्टीकरण पुढील section मध्ये आहे.

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

की कालबाह्यता आणि काही आठवड्यांनंतर काम करणे थांबवणारा node

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

Preauth keys रचनेनुसार लवकर expire होतात. Default one hour आणि one use आहे. tailscale up ने key नाकारल्यास, client वर काहीही संपादित करण्याऐवजी server वर नवीन key तयार करा.

Node keys हा दीर्घकाळ वैध राहणारा भाग आहे. config.yaml मधील node विभाग expiry: 0 सेट करतो आणि 0 म्हणजे default expiry नाही: तुम्ही तो expire करेपर्यंत registered node वैध राहतो. Tagged nodes कधीही expire होत नाहीत. Registrations आपोआप expire व्हाव्यात असे वाटत असल्यास expiry: 180d सेट करा आणि त्याचा परिणाम समजून घ्या: त्यानंतर प्रत्येक non-tagged node ला त्या schedule नुसार sudo tailscale up --login-server https://headscale.example.com --force-reauth आवश्यक असेल. कोणीही पुन्हा authenticate न करणारा headless server स्वतःहून network मधून बाहेर पडेल.

कोणाचा laptop हरवल्यास हे manually करा. 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 backups मध्ये हे नियोजित वेळापत्रकानुसार आणि encrypted पद्धतीने कसे करायचे ते दिले आहे.

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

FAQ

headscale install केल्यानंतर लगेच सुरू होण्यास का अपयशी ठरते?

पॅकेज unit install करते; परंतु service stopped स्थितीत ठेवते. तसेच 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 error असते, कारण headscale port bind करण्यापूर्वी संपूर्ण file parse करते.

माझ्या machines वर नेहमीचा Tailscale client install करायचा का?

होय. headscale फक्त control server बदलते. प्रत्येक node वर Tailscale कडील अधिकृत 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 connection असतो. दोन nodes एकमेकांपर्यंत थेट पोहोचू शकत नसतील आणि DERP relay कडे fallback करत असतील, तेव्हाच traffic वळसा घेतो. shipped configuration मध्ये हे relays Tailscale चे public relays असतात. एखादा peer direct आहे की relay वर आहे, हे पाहण्यासाठी node वर tailscale status चालवा.

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

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

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

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