ద్వారా Matt Connor 2026-07-30 · అప్‌డేట్ చేయబడింది 2026-08-01

Headscaleతో మీ స్వంత Tailscale నడపడం ఎలా

Q: నేను .deb ఇన్స్టాల్ చేసిన వెంటనే headscale ప్రారంభం కాకపోవడానికి కారణం ఏమిటి?

ప్యాకేజ్ unitను ఇన్స్టాల్ చేస్తుంది, కానీ serviceను ఆపివేసిన స్థితిలో ఉంచుతుంది. డిఫాల్ట్ /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 లోపమే. ఎందుకంటే portతో bind కావడానికి ముందు headscale మొత్తం ఫైల్ను parse చేస్తుంది.

Q: నా node register అయిన తర్వాత offlineగానే ఉండటానికి కారణం ఏమిటి?

headscale nodes listలో కనిపించినా onlineలోకి రాని node, సాధారణంగా reverse proxy వద్ద తన control connectionను కోల్పోయి ఉంటుంది. ఆ connection Upgrade: tailscale-control-protocol headerతో పంపే HTTP upgradeగా ఉంటుంది. మీరు map $http_upgrade $connection_upgrade block మరియు దానికి సరిపోయే proxy_set_header linesను జోడించకపోతే nginx దాన్ని తొలగిస్తుంది. Caddyకి అదనపు configuration అవసరం లేకుండానే దాన్ని forward చేస్తుంది. అందువల్ల proxy కారణమా కాదా త్వరగా పరీక్షించవచ్చు.

Q: headscale కోసం domain name మరియు TLS అవసరమా?

ఆచరణలో, అవును. Clients server_urlలో ఉంచిన stringకు connect అవుతాయి. Certificates పేర్ల కోసం జారీ చేయబడతాయి; bare IP addresses కోసం జారీ చేయబడవు. DERPకు TLS అవసరమని configuration file పేర్కొంటుంది. Domainతో పాటు Caddyను ఏర్పాటు చేయడానికి సుమారు ఐదు నిమిషాలు పడుతుంది. దాంతో తానే renew అయ్యే HTTPS endpoint లభిస్తుంది. Control serverను plain HTTPపై నడిపితే, ప్రతి client conversation internet మీదుగా clear textలో వెళ్తుంది.

VPSలో మీ స్వంత Tailscale control server‌ను నడపండి. అధికారిక .debతో headscale install చేసి, start చేయకముందే server_url సెట్ చేసి, మొదటి node‌ను join చేయండి.

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

headscale అంటే ఏమిటి

headscale అనేది Tailscale control server యొక్క self-hosted implementation. అందువల్ల మీ private network‌ను సమన్వయం చేసే machine మీరు స్వంతం చేసుకున్న VPS అవుతుంది. ఇది community project. దీన్ని Tailscale Inc. నిర్వహించదు. ప్రతి machine ఇప్పటికీ అధికారిక tailscale client‌ను నడుపుతుంది. ఆ client‌ను మీ server‌కు ఒక flag, --login-server,తో point చేయాలి.

ఎవరు network‌లో భాగమో control server‌కు తెలుసు. ఇది ప్రతి node‌కు 100.64.0.0/10 పరిధి నుంచి ఒక address ఇస్తుంది. ఇది public keys‌ను పంపిణీ చేస్తుంది. Nodes ఒకదానినొకటి ఎక్కడ కనుగొనాలో కూడా ఇది తెలియజేస్తుంది. Tunnels మాత్రం WireGuardగానే ఉంటాయి. అవి node నుంచి node‌కు నేరుగా నిర్మించబడతాయి. మీ రెండు machines మధ్య traffic headscale box ద్వారా వెళ్లదు. Direct path‌ను నిర్మించలేనప్పుడు మాత్రమే nodes relay‌కు fallback అవుతాయి.

ప్రతి headscale instance ఒక tailnet (ఒక Tailscale network)ను అందిస్తుంది. Personal use లేదా చిన్న organisation‌కు ఇది సరిపోతుందని project వివరిస్తుంది. మూడు లేదా నాలుగు machines ఉన్నప్పుడు, మీరు స్వంతం చేసుకున్న VPS‌లో plain WireGuard VPNను నడపడం అంటే తక్కువ software నిర్వహించాలి, తక్కువ సమస్యలు ఎదురవుతాయి. ప్రతి కొత్త laptop కోసం [Peer] block‌ను చేతితో రాయాల్సిన అవసరం లేకపోయినప్పుడు headscale ఉపయోగకరంగా ఉంటుంది. ఈ రెండు models‌ యొక్క విస్తృత పోలిక కోసం WireGuard మరియు Tailscale ఎలా వేరు అవుతాయో చూడండి.

ఇన్‌స్టాల్ చేయడానికి ముందు అవసరమైనవి

public IPv4 address మరియు sudo access ఉన్న Ubuntu 24.04తో నడుస్తున్న VPS. server కొత్తదైతే, ముందుగా కొత్త VPSలో మొదటి పది నిమిషాల దశలను పూర్తి చేయండి.
ఆ address వైపు చూపించే DNS A record. ఈ guideలో headscale.example.comను ఉపయోగిస్తుంది.
MagicDNS కోసం రెండవ domain లేదా subdomain. ఈ guideలో tailnet.example.netను ఉపయోగిస్తుంది. ఇది server_urlలో ఉన్న domainతో ఒకటే కాకూడదు.
Linux, macOS, Windows, Android లేదా iOSలో నడుస్తున్న, networkలో చేర్చే ఒక client machine.

అధికారిక .deb నుండి headscale ఇన్‌స్టాల్ చేయడం

ప్రాజెక్ట్ తన GitHub releases పేజీలో .deb ప్యాకేజీలను విడుదల చేస్తుంది. July 2026 నాటికి ప్రస్తుత release 0.29.3. ముందుగా మీ 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

ఫైల్ పేరుకు ముందు ఉన్న ./ అవసరం. అది లేకపోతే, apt మీ repositoriesలో headscale.deb అనే package కోసం చూస్తుంది మరియు విఫలమవుతుంది.

ఈ package headscale system userను సృష్టిస్తుంది, డిఫాల్ట్ /etc/headscale/config.yaml ను రాస్తుంది మరియు systemd unitను ఇన్‌స్టాల్ చేస్తుంది. ఇది serviceను ప్రారంభించదు. ఇదే సరైన క్రమం. పంపిణీ చేసిన configuration server_url ను http://127.0.0.1:8080 కు సూచిస్తుంది. మీ clientలలో ఏదీ చేరుకోలేని address అది. అందువల్ల ఇప్పుడు ప్రారంభించిన service సక్రమంగా పనిచేసినా configuration తప్పుగా ఉంటుంది. ఈ దశలో 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 అనేది ప్రాసెస్ బైండ్ అయ్యే చిరునామా. దాన్ని loopback పై ఉంచండి. అదే సర్వర్‌లోని reverse proxy TLS (transport layer security) ను ముగించి, అభ్యర్థనలను దానికి ఫార్వర్డ్ చేస్తుంది. అందువల్ల సర్వర్ వెలుపల నుంచి port 8080 ను చేరుకోవాల్సిన అవసరం లేదు.

base_domain అనేది MagicDNS suffix. మీ నోడ్‌లకు పేర్లు లభించే domain ఇది. ఇది trailing dot లేని fully qualified domain name అయి ఉండాలి. అలాగే server_url లో ఉన్న domain కు ఇది భిన్నంగా ఉండాలి. లేకపోతే రెండు name space లు పరస్పరం ఢీకొంటాయి.

database విభాగాన్ని మార్చవద్దు. డిఫాల్ట్‌గా SQLite /var/lib/headscale/db.sqlite వద్ద ఉంటుంది. ఈ directory ను package సృష్టించి, దాని యాజమాన్యంలో ఉంచింది. ఈ పరిమాణంలోని 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 పని యొక్క రెండు భాగాలను నిర్వహిస్తుంది: ఇది serviceను ప్రారంభిస్తుంది మరియు reboot తర్వాత ప్రారంభమయ్యేలా దాన్ని గుర్తిస్తుంది.

is-active, failedను ప్రింట్ చేస్తే, sudo journalctl -u headscale -n 50 --no-pagerతో journalను చదవండి. ఈ దశలో వైఫల్యానికి దాదాపు ఎల్లప్పుడూ configuration file కారణమవుతుంది. ఎందుకంటే socketను తెరవడానికి ముందు headscale మొత్తం fileను parse చేస్తుంది. అందువల్ల తప్పు indent లేదా తెలియని key ఉంటే, ఏదీ listen చేయకముందే process ఆగిపోతుంది. fileను సరిచేసి, తర్వాత sudo systemctl restart headscaleను అమలు చేయండి. తర్వాత చేసే ప్రతి configuration మార్పుకూ ఇదే restart అవసరం. ఆ తర్వాత clients స్వయంగా reconnect అవుతాయి. 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 కూడా package సృష్టించిన unprivileged user అయిన headscaleతో ప్రారంభమవుతాయి. noise_private.key, server తన clientsకు చూపించే identity. దాన్ని అలాగే ఉంచండి. దాన్ని delete చేస్తే, headscale కొత్తదాన్ని 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

ఫైల్‌ను సరిగ్గా parse చేసినప్పుడు validate, adapted config to JSONను ప్రింట్ చేస్తుంది. ఫైల్ format చేయబడలేదని వచ్చే హెచ్చరిక కేవలం రూపకల్పనకు సంబంధించినది. మీ 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 విలువ tailscale-control-protocol. Caddy దీనిని అదనపు configuration లేకుండా pass through చేస్తుంది. 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ను return చేస్తుంది మరియు అన్నీ సరిగ్గా ఉన్నట్లు కనిపిస్తాయి. కానీ దీర్ఘకాలం కొనసాగుతున్న 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 పోర్ట్ ద్వారా అన్ని క్లయింట్ సంభాషణలు సాగుతాయి. 80 పోర్ట్ ACME (automatic certificate management environment) HTTP సవాలుకు మరియు HTTPSకు దారి మళ్లించడానికి మాత్రమే అవసరం. Caddy సర్టిఫికేట్ పొందడానికి కూడా ఈ పోర్ట్ అవసరం.

8080 పోర్ట్ మూసి ఉండాలి. listen_addr అనేది 127.0.0.1:8080, కాబట్టి proxy loopback interface ద్వారా headscaleను చేరుకుంటుంది. అందువల్ల ఎటువంటి firewall నియమం అవసరం లేదు. 8080 పోర్ట్‌ను internetకు తెరవడం వల్ల క్లయింట్లకు 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 command ఒక client. ఇది నడుస్తున్న daemon‌తో /var/run/headscale/headscale.sock వద్ద ఉన్న unix socket ద్వారా కమ్యూనికేట్ చేస్తుంది. ఆ socket mode 0770లో ఉంటుంది మరియు headscale groupకు చెందినది. దీనివల్ల రెండు విషయాలు స్పష్టమవుతాయి. service ఆపివేసి ఉంటే command విఫలమవుతుంది. ఈ guideలో ఆర్డర్ ముఖ్యం కావడానికి ఇది మరో కారణం. అలాగే, మీ స్వంత accountను headscale groupకు జోడించకపోతే దీనికి sudo అవసరం.

users list ప్రతి name పక్కన ఒక IDని చూపిస్తుంది. మీకు ఆ number అవసరం, ఎందుకంటే key command nameను కాకుండా numeric user IDని తీసుకుంటుంది.

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

key ఒక్కసారి మాత్రమే చూపించబడుతుంది. దాన్ని ఇప్పుడే copy చేయండి. preauth key single use మరియు ఒక గంటపాటు మాత్రమే చెల్లుతుంది. మీరు వేరే విధంగా పేర్కొనకపోతే ఇది వర్తిస్తుంది. అందువల్ల మీరు ఇంకా testing చేస్తున్నప్పుడే --expiration 24h సెట్ చేయడం మంచిది. అనేక machinesను enroll చేసే key కోసం --reusable జోడించండి. దాన్ని passwordలాగా రక్షించండి, ఎందుకంటే దాన్ని కలిగి ఉన్న ఎవరైనా మీ networkలో చేరవచ్చు.

మీరు చేరదలచిన మెషీన్‌లో:

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 ఆ nodeను దాని ID, user మరియు online స్థితితో చూపిస్తుంది.

--login-server విలువ, schemeతో సహా మరియు చివరలో slash లేకుండా, server_urlతో ఖచ్చితంగా సరిపోవాలి. వీటిని stringsగా పోలుస్తారు. సరిపోలకపోతే, క్లయింట్ ఒక చిరునామాకు register అయి, తర్వాత మరో చిరునామాతో సంప్రదించమని చెప్పబడుతుంది.

గతంలో Tailscale యొక్క hosted serviceకు sign in చేసిన మెషీన్ ఆ loginను కొనసాగిస్తుంది. ముందుగా దానిపై sudo tailscale logout అమలు చేయండి. తర్వాత --login-serverతో tailscale up అమలు చేయండి.

మీరు --auth-keyను వదిలేస్తే, క్లయింట్ బదులుగా ఒక URLను ముద్రిస్తుంది. దాన్ని తెరిస్తే, ఆ registration ప్రయత్నానికి సంబంధించిన identifier కనిపిస్తుంది. సర్వర్‌లో దాన్ని approve చేయండి:

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

మీ స్వంత laptopకు ఈ విధానం సౌకర్యంగా ఉంటుంది. Script ద్వారా నడిపే వాటికి preauth keys మెరుగైనవి, ఎందుకంటే వాటిని పర్యవేక్షించడానికి ఎవరూ అవసరం లేదు.

DERP, ప్రత్యక్ష మార్గం విఫలమైనప్పుడు ట్రాఫిక్‌ను రిలే చేసే విధానం

DERP (designated encrypted relay for packets) అనేది ప్రత్యామ్నాయ మార్గం. రెండు నోడ్‌లు ప్రత్యక్ష WireGuard కనెక్షన్‌ను తెరవలేనప్పుడు, సాధారణంగా రెండూ కఠినమైన NAT (network address translation) వెనుక ఉన్నప్పుడు, అవి ప్యాకెట్‌లను రిలే ద్వారా పంపుతాయి. రిలే వద్ద ఎలాంటి కీలు ఉండవు. అందువల్ల అది మీ ట్రాఫిక్‌ను చదవలేడు. అయితే ఏ నోడ్‌లు పరస్పరం కమ్యూనికేట్ చేస్తున్నాయో, ఎంత డేటా మార్పిడి జరుగుతోందో అది చూడగలదు.

డిఫాల్ట్ కాన్ఫిగరేషన్ ఏమి చేస్తుందో స్పష్టంగా తెలుసుకోండి. Headscale, https://controlplane.tailscale.com/derpmap/default ను auto_update_enabled: true మరియు update_frequency: 3h తో సూచించే విధంగా విడుదలవుతుంది. అందువల్ల మీ కంట్రోల్ ప్లేన్ మీ ఆధీనంలో ఉంటుంది, కానీ మీ రిలేలు Tailscale ఆధీనంలో ఉంటాయి. చాలా మందికి ఇది సముచితమైన మార్పిడి. మీకు ఇది సరిపోకపోతే, మీ స్వంత రిలేను అమలు చేయండి.

మీ స్వంత రిలేను అమలు చేయడానికి, config.yaml లోని derp.server కింద enabled: true ను సెట్ చేసి, headscale ను పునఃప్రారంభించండి. తర్వాత STUN (session traversal utilities for NAT) పోర్ట్‌ను sudo ufw allow 3478/udp తో తెరవండి. కాన్ఫిగరేషన్ ఫైల్ ఈ అవసరాన్ని స్పష్టంగా పేర్కొంటుంది: server_url తప్పనిసరిగా https ను ఉపయోగించాలి, ఎందుకంటే DERP కు TLS అవసరం. derp.urls జాబితాను ఖాళీ చేస్తే, మ్యాప్ నుండి Tailscale రిలేలు తొలగిపోతాయి. పనిచేస్తున్న embedded relay లేకుండా ఇలా చేస్తే, ప్రత్యక్షంగా కనెక్ట్ కాలేని ఏ రెండు నోడ్‌లు కూడా పరస్పరం కనెక్ట్ కాలేవు.

క్లయెంట్ నుంచి tailscale netcheck అమలు చేస్తే, దానికి తెలిసిన ప్రతి రిలే ప్రాంతానికి ఉన్న latency ను చూపిస్తుంది. tailscale status ప్రతి peer ను చిరునామా ఉన్న direct లేదా region code ఉన్న relay గా గుర్తిస్తుంది. relay స్థితిలో నిలిచిపోయిన peer సమస్య NAT లో ఉంది, headscale లో కాదు.

నోడ్ ఆఫ్‌లైన్‌గా ఎందుకు కనిపిస్తుంది?

Proxy upgrade‌ను drop చేస్తోంది. ఇది సాధారణ కారణం. దీని లక్షణం ఏమిటంటే మిగతావన్నీ సరిగ్గా కనిపిస్తాయి: /health 200ని తిరిగి ఇస్తుంది, headscale nodes list నోడ్‌ను చూపిస్తుంది, కానీ నోడ్ ఎప్పుడూ online‌కి రాదు. Control connection అనేది Upgrade: tailscale-control-protocolను కలిగిన POST. దాన్ని forward చేయని proxy నోడ్ స్థితిని నివేదించే ఏకైక channel‌ను నిలిపివేస్తుంది. మీ nginx configuration‌ను పైన ఉన్న map block‌తో పోల్చండి. లేదా proxy సమస్య కాదని నిర్ధారించడానికి Caddyకి మారండి.

నోడ్‌లు register అయిన తర్వాత server_url మారింది. Registration సమయంలో ఇచ్చిన విలువకు నోడ్‌లు నిరంతరం 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 చేయలేని లేదా చేరుకోలేని client తన retryలను అక్కడ log చేస్తుంది.

Key గడువు ముగిసింది. దీని గురించి తదుపరి విభాగంలో ఉంది.

మీరు పరీక్షిస్తున్నప్పుడు server వైపు activityని monitor చేయడానికి VPSలో sudo journalctl -u headscale -fను అమలు చేసి, clientలో tailscaledను restart చేయండి. headscale‌ను చేరుకున్న నోడ్ వెంటనే log lines‌ను ఉత్పత్తి చేస్తుంది. ఏ output లేకపోతే request చేరడం లేదని అర్థం. కాబట్టి headscale‌ను పరిశీలించే ముందు DNS, firewall మరియు proxyని తనిఖీ చేయండి.

కీ గడువు ముగియడం, వారాల తర్వాత పనిచేయడం ఆపే node

రెండు వేర్వేరు గడువు విధానాలు ఉన్నాయి. వాటిని కలిపి అర్థం చేసుకుంటే సమయం వృథా అవుతుంది.

Preauth keys ఉద్దేశపూర్వకంగా త్వరగా గడువు ముగుస్తాయి. డిఫాల్ట్ ఒక గంట మరియు ఒక వినియోగం. tailscale up keyను తిరస్కరిస్తే, clientలో ఏదైనా మార్చకుండా serverలో కొత్తదాన్ని రూపొందించండి.

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 అవసరం అవుతుంది. ఎవరూ మళ్లీ authenticate చేయని headless server స్వయంగా network నుంచి తొలగిపోతుంది.

ఎవరైనా laptop పోగొట్టుకున్నప్పుడు దీన్ని manualగా చేయండి. 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

రెండు ఫైళ్లను సర్వర్‌కి వేరుగా సురక్షితంగా ఉంచండి. వీటిలో ప్రైవేట్ కీలు మరియు అన్ని రిజిస్ట్రేషన్‌లు ఉంటాయి. అందువల్ల సర్వర్‌కు ఇచ్చే భద్రతనే వీటికీ ఇవ్వాలి. VPS నుంచి restic బ్యాకప్‌లు అనే విభాగంలో దీన్ని షెడ్యూల్ ప్రకారం మరియు ఎన్‌క్రిప్షన్‌తో ఎలా చేయాలో వివరించారు.

అప్‌గ్రేడ్‌లు కూడా ఇన్‌స్టాలేషన్‌నే పునరావృతం చేస్తాయి: కొత్త .deb, sudo apt install ./headscale.deb డౌన్‌లోడ్ చేసి, తరువాత సేవను పునఃప్రారంభించండి. ఆపై is-active మరియు /health తనిఖీలను మళ్లీ అమలు చేయండి. 0.29 నుంచి అప్‌గ్రేడ్ మార్గం కఠినంగా ఉంది. చిన్న వెర్షన్‌ను దాటవేయడం నిరోధించబడుతుంది. పాత చిన్న వెర్షన్‌కు downgrade చేయడం కూడా నిరోధించబడుతుంది. ఒక్కసారి ఒక చిన్న వెర్షన్‌నే మార్చండి. ప్రతి దశకు ముందు బ్యాకప్ తీసుకోండి. ముందుగా ఆ వెర్షన్ విడుదల గమనికలను చదవండి. అదే విడుదల ACL విధాన ప్రవర్తనను మార్చి, అనేక కాన్ఫిగరేషన్ కీల స్థానాలను మార్చింది.

FAQ

నేను .deb ఇన్‌స్టాల్ చేసిన వెంటనే headscale ప్రారంభం కాకపోవడానికి కారణం ఏమిటి?

ప్యాకేజ్ unitను ఇన్‌స్టాల్ చేస్తుంది, కానీ serviceను ఆపివేసిన స్థితిలో ఉంచుతుంది. డిఫాల్ట్ /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 లోపమే. ఎందుకంటే portతో bind కావడానికి ముందు headscale మొత్తం ఫైల్‌ను parse చేస్తుంది.

నా యంత్రాల్లో సాధారణ Tailscale clientను ఇంకా ఇన్‌స్టాల్ చేయాలా?

అవును. Headscale control serverను మాత్రమే భర్తీ చేస్తుంది. ప్రతి node Tailscale అందించే అధికారిక clientను అమలు చేస్తుంది. sudo tailscale up --login-server https://headscale.example.comతో ఆ clientను మీ serverకు సూచించండి. ఆ flag ప్రామాణిక clientలోనే ఉంటుంది. కాబట్టి దానికి patch చేయడం లేదా తిరిగి build చేయడం అవసరం లేదు.

నా network traffic headscale server ద్వారా వెళ్తుందా?

సాధారణంగా వెళ్లదు. Headscale networkను సమన్వయం చేసి keys మరియు addressesను అందిస్తుంది. Data path మాత్రం మీ nodes మధ్య నేరుగా WireGuard ద్వారా ఉంటుంది. రెండు nodes ఒకదానితో ఒకటి నేరుగా చేరుకోలేనప్పుడు మాత్రమే traffic DERP relay ద్వారా మళ్లుతుంది. పంపిణీ అయ్యే configurationలో ఆ relays Tailscale యొక్క public relaysగా ఉంటాయి. ఒక nodeపై tailscale statusను అమలు చేసి, నిర్దిష్ట peer directలో ఉందో లేదా relayలో ఉందో చూడండి.

నా node register అయిన తర్వాత offlineగానే ఉండటానికి కారణం ఏమిటి?

headscale nodes listలో కనిపించినా onlineలోకి రాని node, సాధారణంగా reverse proxy వద్ద తన control connectionను కోల్పోయి ఉంటుంది. ఆ connection Upgrade: tailscale-control-protocol headerతో పంపే HTTP upgradeగా ఉంటుంది. మీరు map $http_upgrade $connection_upgrade block మరియు దానికి సరిపోయే proxy_set_header linesను జోడించకపోతే nginx దాన్ని తొలగిస్తుంది. Caddyకి అదనపు configuration అవసరం లేకుండానే దాన్ని forward చేస్తుంది. అందువల్ల proxy కారణమా కాదా త్వరగా పరీక్షించవచ్చు.

headscale కోసం domain name మరియు TLS అవసరమా?

ఆచరణలో, అవును. Clients server_urlలో ఉంచిన stringకు connect అవుతాయి. Certificates పేర్ల కోసం జారీ చేయబడతాయి; bare IP addresses కోసం జారీ చేయబడవు. DERPకు TLS అవసరమని configuration file పేర్కొంటుంది. Domainతో పాటు Caddyను ఏర్పాటు చేయడానికి సుమారు ఐదు నిమిషాలు పడుతుంది. దాంతో తానే renew అయ్యే HTTPS endpoint లభిస్తుంది. Control serverను plain HTTPపై నడిపితే, ప్రతి client conversation internet మీదుగా clear textలో వెళ్తుంది.

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