SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-11-01

Headscale वापरून स्वतःचा Tailscale server कसा चालवायचा

VPS वर स्वतःचा Tailscale control server चालवा. अधिकृत .deb मधून headscale install करा, server_url सेट करून restart करा आणि पहिला node network मध्ये जोडा.

Verified Every command ran end-to-end on a fresh Ubuntu 24.04 server, July 30, 2026.

headscale म्हणजे काय

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

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

Headscale प्रत्येक instance साठी एक tailnet (एक Tailscale network) उपलब्ध करून देतो. प्रकल्पाच्या वर्णनानुसार, हे वैयक्तिक वापरासाठी किंवा छोट्या संस्थेसाठी योग्य आहे. तीन किंवा चार मशीन असल्यास, तुमच्या मालकीच्या VPS वर चालणारे साधे WireGuard VPN चालवण्यासाठी कमी सॉफ्टवेअर लागते आणि बिघाड होण्याची शक्यताही कमी असते. प्रत्येक नवीन laptop साठी [Peer] block हाताने लिहिण्याची गरज उरत नाही, तेव्हा Headscale उपयुक्त ठरतो. खर्चामुळेच अनेक जण सुरुवातीला पर्याय शोधू लागतात. त्यामुळे server उभारण्याची जबाबदारी घेण्यापूर्वी hosted free plan मध्ये प्रत्यक्षात काय समाविष्ट आहे ते वाचणे उपयुक्त ठरते. वैयक्तिक वापरातील काही मोजकी machine साधारणपणे त्यात समाविष्ट होतात. तुम्ही आधीच त्या मर्यादेपलीकडे असाल, तर प्रति user आणि प्रति tagged resource आकारल्या जाणाऱ्या paid plans ची किंमत यांच्याशी खर्चाची तुलना करा. User devices अमर्यादित असतात, तर tagged resources साठी स्वतंत्र मर्यादा आणि शुल्क असते. Self-hosted control plane हवा असेल, पण Tailscale चा थेट पर्याय नको आणि peers व्यवस्थापित करण्यासाठी तुमचा स्वतःचा client तसेच web interface हवा असेल, तर एकाच VPS वर NetBird हा विचार करण्यासारखा पर्याय आहे. दोन्ही पर्याय WireGuard द्वारे तुमचा traffic पाठवतात. त्यामुळे निवड access rules कशा लिहिता आणि relays कसे वागतात यावर अवलंबून असते. यापूर्वी या मुद्द्यांवर NetBird आणि Tailscale ची तुलना करणे उपयुक्त ठरेल. या दोन मॉडेल्सची व्यापक तुलना पाहण्यासाठी WireGuard आणि Tailscale यांच्यातील फरक पहा.

तुम्ही install करण्यापूर्वी आवश्यक गोष्टी

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

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

प्रकल्पाच्या GitHub releases पृष्ठावर .deb पॅकेज उपलब्ध करून दिली जातात. 27 October 2026 रोजीची माहिती पाहता, नवीनतम stable release 0.29.6 आहे. ती 24 October 2026 रोजी प्रसिद्ध झाली. प्रथम तुमचे 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.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

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

या package मुळे headscale system user तयार होतो, default /etc/headscale/config.yaml लिहिली जाते, systemd unit स्थापित केली जाते आणि त्यानंतर service सुरू केली जाते. त्यामुळे apt पूर्ण झाल्यावर headscale आधीच चालू असतो आणि sudo systemctl is-active headscale मुळे active दिसते. मात्र नवीन स्थापनेवर package unit enable करत नाही. त्यामुळे reboot नंतर service पुन्हा सुरू होणार नाही. खालील restart step मध्ये unit enable केल्यामुळे ही समस्या दूर होते. सध्या service shipped configuration वरही चालू असते. त्या configuration मध्ये server_url ला http://127.0.0.1:8080 कडे निर्देशित केलेले असते. तुमच्या कोणत्याही client ला त्या address वर पोहोचता येत नाही. अद्याप काहीही बाहेरून उपलब्ध केलेले नसते, कारण shipped listen_addr देखील loopback वर असते. तरीही server_url सेट करून service restart करेपर्यंत कोणताही client जोडू नका. पुढील दोन steps हेच करतात.

कोणताही client जोडण्यापूर्वी server_url configure करा

/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 registration URLs तयार करताना वापरत असलेला सार्वजनिक पत्ता आहे. Clients --login-server ने configure केलेला control address वापरतात. त्यामुळे दोन्ही ठिकाणी https:// सह तेच सार्वजनिक नाव वापरा. 127.0.0.1 कधीही वापरू नका. headscale च्या documentation नुसार plain HTTP किंवा 443 व्यतिरिक्त इतर port वरील HTTPS वापरता येतो. मात्र production साठी 443 port वरील HTTPS वापरण्याची ती ठाम शिफारस करते. या guide मधील पुढील रचना हेच गृहीत धरते.

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

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

Database section मध्ये बदल करू नका. Default configuration /var/lib/headscale/db.sqlite येथे SQLite वापरते. हा directory package ने तयार करून त्याच्या मालकीचा ठेवलेला आहे. या आकाराच्या 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 सुरू होताना एकदाच त्याचे configuration वाचते. त्यामुळे package ने सुरू केलेली process रीस्टार्ट करेपर्यंत वितरित केलेले server_url वापरत राहते. sudo systemctl enable --now headscale हे काम करत नाही. सेवा आधीच सुरू असल्यामुळे, --now start केल्याने काहीही बदलत नाही आणि जुनी value कार्यरत राहते. Boot वेळी सेवा सुरू करण्याचे काम enable चे आहे आणि ते आपोआप केले जात नाही. नवीन install वर package सेवा सुरू करते, पण तिला enable करत नाही. त्यामुळे वर दिल्याप्रमाणे sudo systemctl enable headscale एकदा चालवा.

is-active ने active व्यतिरिक्त काहीही दाखवले, किंवा curl ने 200 दाखवले नाही, तर sudo journalctl -u headscale -n 50 --no-pager वापरून journal वाचा. या टप्प्यावर अपयशाचे कारण जवळजवळ नेहमी configuration file असते. कारण socket उघडण्यापूर्वी headscale संपूर्ण file parse करते. त्यामुळे चुकीचा indent किंवा invalid required setting असल्यास कोणतीही process listen करण्यापूर्वीच थांबते. File दुरुस्त करा आणि नंतर sudo systemctl restart headscale चालवा. त्यानंतरच्या प्रत्येक configuration बदलासाठी हाच रीस्टार्ट आवश्यक आहे. त्यानंतर 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 करते आणि पुन्हा connect होण्यापूर्वी clients ना नवीन server key fetch करावी लागते. विद्यमान registrations database मध्ये कायम राहतात.

headscale च्या पुढे TLS लावा

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

sudo apt install -y caddy

/etc/caddy/Caddyfile च्या जागी headscale documentation मधील 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 दाखवते. फाइल format केलेली नाही असा warning दिसला, तरी तो केवळ cosmetic आहे. तुमच्या 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;
    }
}

या lines वगळल्यास सामान्य requests तरीही यशस्वी होतात. म्हणून /health 200 परत करते आणि सर्व काही योग्य दिसते. परंतु control connection कधीही तयार होत नाही. नवीन nodes register होऊ शकत नाहीत आणि विद्यमान nodes पुन्हा connect होऊन online स्थिती कळवू शकत नाहीत. nginx वापरणार असल्यास, nginx सह Ubuntu 24.04 वर 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 चे headscale कडे जाणारे control connection वाहून नेले जाते. नंतर embedded DERP relay सक्षम केल्यास 3478/udp देखील आवश्यक असेल; त्याचे तपशील खाली दिले आहेत. ACME (automatic certificate management environment) च्या HTTP challenge साठी आणि HTTPS कडे redirect करण्यासाठी 80 पोर्ट वापरले जाते. 80 पोर्ट बंद असतानाही Caddy प्रमाणपत्र मिळवू शकतो, कारण तो 443 पोर्टवरील TLS-ALPN challenge वापरू शकतो. मात्र 80 पोर्ट उघडे असल्यास दोन्ही challenge उपलब्ध राहतात आणि साध्या http:// requests चे redirect केले जाते.

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

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

sudo headscale users create alice
sudo headscale users list

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

users list प्रत्येक नावासमोर एक ID दाखवते. तुम्हाला तो क्रमांक आवश्यक आहे, कारण key कमांड नावाऐवजी numeric 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 मध्ये 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 ने assign केलेला address दाखवते. तो 100.64.0.1 सारखा दिसू शकतो. त्यानंतर server वर sudo headscale nodes list चालवल्यास ID, user आणि online state यांसह node दिसतो.

server_url मधील public HTTPS address --login-server साठी वापरा. Client त्याच्या control URL मधील शेवटचे slashes काढतो. त्यामुळे एखाद्या slash वगळल्याशिवाय exact string comparison आवश्यक नाही.

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

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

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

तुमच्या स्वतःच्या laptop साठी हा form अधिक सोयीचा आहे. Script द्वारे चालवल्या जाणाऱ्या गोष्टींसाठी preauth keys अधिक योग्य आहेत, कारण त्यासाठी कोणत्याही व्यक्तीने लक्ष ठेवण्याची गरज नसते. VPS स्वतः node झाल्यानंतर तो तुमच्या इतर मशीनचा internet traffic देखील वाहून नेऊ शकतो. यालाच exit node setup म्हणतात. फरक एवढाच आहे की advertised route ला hosted admin console मध्ये नव्हे, तर server वर headscale command वापरून approve करावे लागते. त्या VPS च्या मागे असलेल्या private network मध्ये पोहोचायचे असेल, internet कडे जाण्याचा मार्ग तयार करायचा नसेल, तर हाच approval step तो subnet तुमच्या उर्वरित tailnet ला advertise करण्यासाठी वापरता येतो. एखाद्या node वरून संपूर्ण network route करण्याऐवजी एक application publish करणे हे वेगळे काम आहे. ते करण्याचे दोन मार्ग म्हणजे serve आणि funnel. मात्र दोन्ही Tailscale च्या स्वतःच्या certificate आणि ingress machinery वर अवलंबून असतात. त्यामुळे त्यांना headscale कडून मिळणाऱ्या सुविधांऐवजी hosted-tailnet features म्हणून समजा.

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

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

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 सेट करा. वितरित केलेले ipv4: 198.51.100.1 आणि ipv6: 2001:db8::1 तुमच्या relay च्या public addresses ने बदला किंवा DNS वापरण्यासाठी दोन्ही settings काढून टाका. त्यानंतर headscale restart करा आणि sudo ufw allow 3478/udp वापरून STUN (session traversal utilities for NAT) port उघडा. या address settings DNS वर override करतात. त्यामुळे कोणताही placeholder तसाच ठेवल्यास clients unreachable address कडे पाठवले जातात. Configuration file मध्ये ही अट स्पष्टपणे नमूद आहे: server_url ने https वापरणे आवश्यक आहे, कारण DERP ला TLS आवश्यक असते. derp.urls list रिकामी केल्यास Tailscale चे relays map मधून काढले जातात. असे करण्यापूर्वी कार्यरत embedded किंवा custom relay ठेवा. रिकामा relay map असल्यास Headscale सुरू होण्यास नकार देते. फक्त unreachable relay असलेल्या map मुळे थेट connect न होणारे nodes परस्परांशी communicate करू शकत नाहीत.

Client वरून tailscale netcheck वापरल्यास त्याला माहीत असलेल्या प्रत्येक relay region पर्यंतची latency दिसते. tailscale status active peer connections साठी direct मध्ये address किंवा relay मध्ये region code दाखवते. relay वर अडकलेल्या peer चा direct path तपासणे आवश्यक आहे. त्यात NAT आणि firewall rules यांचा समावेश होतो. Peer direct असूनही slow असेल, तर तो वेगळा प्रश्न आहे. तिथे नेहमीचे उत्तर tunnel नसून MTU असते.

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

proxy upgrade request टाकून देत आहे. याचे लक्षण म्हणजे /health 200 परत करते, परंतु नवीन registrations अयशस्वी होतात किंवा विद्यमान nodes पुन्हा connect करू शकत नाहीत. Control connection ही Upgrade: tailscale-control-protocol घेऊन जाणारी POST request असते. ती forward न करणारा proxy registration आणि node state कळवणारा channel दोन्ही रोखतो. वरील upgrade lines शी तुमची nginx configuration तुलना करा किंवा proxy हे कारण नाही याची खात्री करण्यासाठी Caddy वापरा.

सार्वजनिक control address बदलला आहे. Nodes --login-server ने configure केलेल्या address वर सतत connection करण्याचा प्रयत्न करतात; server_url बदलल्याने त्या client setting मध्ये बदल होत नाही. जुना address आता तुमच्या server पर्यंत पोहोचत नसेल, तर प्रत्येक node वर sudo tailscale up --login-server https://headscale.example.com --force-reauth चालवा.

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

key ची मुदत संपली आहे. याचे वर्णन पुढील section मध्ये आहे.

तुम्ही चाचणी करत असताना server-side logs पाहण्यासाठी VPS वर sudo journalctl -u headscale -f चालवा आणि client वर tailscaled restart करा. Client journal देखील तपासा: headscale पर्यंत पोहोचणाऱ्या request मुळे default log level वर line नोंदवली जाईलच असे नाही. त्यामुळे server log शांत आहे एवढ्यावरून DNS, firewall किंवा proxy failure सिद्ध होत नाही.

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

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

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

Node keys हा दीर्घकाळ टिकणारा भाग आहे. config.yaml मधील node विभाग expiry: 0 सेट करतो आणि 0 म्हणजे कोणतीही डीफॉल्ट मुदतसमाप्ती नाही; तरीही client ने स्पष्टपणे दिलेली expiry किंवा OIDC expiry लागू होऊ शकते. Tagged nodes स्वयंचलित expiry मधून वगळले जातात, परंतु administrator त्यांची expiry स्पष्टपणे लागू करू शकतो. Non-tagged registrations साठी 180-day डीफॉल्ट हवी असल्यास expiry: 180d सेट करा; मात्र client ने मागितलेली expiry त्यावर प्राधान्य घेते आणि OIDC डीफॉल्ट बदलू शकते. ही setting बदलल्याने विद्यमान registrations ची मुदत पूर्वलक्ष्यी पद्धतीने बदलत नाही. Expiry असलेल्या node ला त्या deadline पूर्वी sudo tailscale up --login-server https://headscale.example.com --force-reauth वापरून पुन्हा authentication करावे लागते. कोणीही पुन्हा authentication न करणारा headless server registration ची मुदत संपल्यावर 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 मध्ये लेखन सुरू असू शकते आणि लोड असताना घेतलेली database प्रत विसंगत असू शकते.

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 आणि सर्व registration माहिती असते. त्यामुळे सर्व्हरइतकीच काळजी त्यांचीही घ्या. VPS वरील restic backups हे काम वेळापत्रकानुसार आणि encrypted पद्धतीने कसे करायचे ते स्पष्ट करते.

अपग्रेड करताना install प्रक्रिया पुन्हा करा: नवीन .deb, sudo apt install ./headscale.deb download करा. त्यानंतर सेवा restart करा आणि is-active व /health तपासण्या पुन्हा चालवा. 0.29 पासून upgrade path strict आहे. Minor version वगळून पुढे जाणे blocked आहे. जुन्या minor version वर downgrade करणेही blocked आहे. एका वेळी एकच minor version पुढे जा. प्रत्येक टप्प्यापूर्वी backup घ्या. त्या version च्या release notes आधी वाचा, कारण त्याच release मध्ये ACL policy चे वर्तन बदलले आणि अनेक configuration keys हलवण्यात आल्या. Version 0.29.6 मध्ये certificate validation आणि dependencies साठी security updates देखील आहेत. त्यामुळे विद्यमान 0.29 installations ने हा patch release लागू करावा.

FAQ

headscale install केल्यानंतर लगेच चालू होते का?

होय. पॅकेज install होताच सेवा सुरू करते. ती वितरित केलेल्या /etc/headscale/config.yaml वर सुरू होते. हा listener फक्त loopback वर असतो आणि server_url ची किंमत http://127.0.0.1:8080 वर सेट करतो. नवीन install मध्ये सेवा enable केलेली नसते. त्यामुळे sudo systemctl enable headscale चालवेपर्यंत ती boot वेळी सुरू होणार नाही. वितरित केलेला address clients साठी उपयोगी नसतो. म्हणून server_url, listen_addr आणि base_domain संपादित करा. त्यानंतर sudo systemctl restart headscale चालवा आणि sudo systemctl is-active headscale ने पडताळा. हे restart असणे आवश्यक आहे. headscale ही file फक्त सुरू होताना वाचते. आधीच चालू असलेल्या सेवेसाठी enable --now केल्याने ती boot साठी enable होते, पण सेवा restart होत नाही. त्यामुळे जुन्या value कार्यरत राहतात. restart नंतर सेवा अयशस्वी झाल्यास sudo journalctl -u headscale -n 50 --no-pager समस्या दाखवते. या टप्प्यावर कारण जवळजवळ नेहमी YAML error असते, कारण port bind करण्यापूर्वी headscale संपूर्ण file parse करते.

माझ्या machines वर नेहमीचा Tailscale client अजूनही install करावा लागेल का?

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

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

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

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

या setup साठी होय. domain name आणि HTTPS वापरा. Certificates bare IP addresses साठीही वापरता येतात. मात्र configuration file मध्ये DERP साठी TLS आवश्यक असल्याचे नमूद केले आहे. Domain आणि Caddy वापरल्यास सुमारे पाच मिनिटांत स्वतः renew होणारा HTTPS endpoint मिळतो. Plain HTTP शक्य आहे. तरी production साठी port 443 वर HTTPS वापरण्याची headscale documentation ठामपणे शिफारस करते. काही परिस्थितींमध्ये Tailscale client port 443 वर HTTPS गृहीत धरतो, असेही documentation नमूद करते.

हा लेख उपयुक्त होता का?

#headscale#tailscale#wireguard#vpn#self-hosting