Headscale மூலம் உங்கள் சொந்த Tailscale control server

headscale என்றால் என்ன

Headscale என்பது Tailscale control server-ன் self-hosted implementation ஆகும். எனவே, உங்கள் private network-ஐ ஒருங்கிணைக்கும் machine, நீங்கள் வைத்திருக்கும் VPS ஆக இருக்கும். இது community project ஆகும். இதை Tailscale Inc. இயக்குவதில்லை. ஒவ்வொரு machine-லும் official tailscale client இயங்கும். அந்த client-க்கு உங்கள் server-ஐ சுட்டிக்காட்ட --login-server flag-ஐ பயன்படுத்த வேண்டும்.

Control server-க்கு network-ல் யார் சேர்கிறார்கள் என்பது தெரியும். இது ஒவ்வொரு node-க்கும் 100.64.0.0/10 இலிருந்து ஓர் address வழங்கும். Public keys-ஐ விநியோகிக்கும். Nodes ஒன்றையொன்று எங்கு கண்டறிய வேண்டும் என்பதையும் தெரிவிக்கும். Tunnels, node-க்கு node இடையிலான WireGuard ஆகவே இருக்கும். உங்கள் இரண்டு machines-க்கு இடையிலான traffic headscale box வழியாக செல்லாது. Direct path உருவாக்க முடியாதபோது மட்டும் nodes relay-க்கு மாறும்.

Headscale ஒவ்வொரு instance-க்கும் ஒரு tailnet-ஐ (ஒரு Tailscale network) வழங்கும். இது தனிப்பட்ட பயன்பாடு அல்லது சிறிய organisation-க்கு ஏற்றது என்று project குறிப்பிடுகிறது. மூன்று அல்லது நான்கு machines மட்டுமே இருந்தால், நீங்கள் வைத்திருக்கும் VPS-ல் plain WireGuard VPN இயக்குவது குறைந்த software-ஐ மட்டுமே தேவைப்படுத்தும். அதனால் பழுதடையக்கூடிய கூறுகளும் குறையும். ஒவ்வொரு புதிய laptop-க்கும் [Peer] block-ஐ கைமுறையாக எழுத வேண்டாம் என்று நீங்கள் விரும்பும் போது headscale பயனுள்ளதாக இருக்கும். இந்த இரண்டு models பற்றிய விரிவான ஒப்பீட்டுக்கு, WireGuard மற்றும் Tailscale எவ்வாறு வேறுபடுகின்றன என்பதைப் பார்க்கவும்.

நிறுவுவதற்கு முன் தேவையானவை

• பொது IPv4 முகவரியுடனும் sudo அணுகலுடனும் Ubuntu 24.04 இயங்கும் VPS. Server புதியதாக இருந்தால், முதலில் புதிய VPS-இல் முதல் பத்து நிமிடங்கள் வழிகாட்டியைப் பின்பற்றவும்.
• அந்த முகவரியைச் சுட்டும் DNS A record. இந்த வழிகாட்டி headscale.example.com-ஐப் பயன்படுத்துகிறது.
• MagicDNS-க்கான இரண்டாவது domain அல்லது subdomain. இந்த வழிகாட்டி tailnet.example.net-ஐப் பயன்படுத்துகிறது. இது server_url-இல் உள்ள domain-ஐப் போன்றதாக இருக்கக்கூடாது.
• Linux, macOS, Windows, Android அல்லது iOS இயங்கும், network-இல் இணைக்க வேண்டிய ஒரு client machine.

அதிகாரப்பூர்வ .deb இலிருந்து headscale-ஐ நிறுவுதல்

இந்தத் திட்டம் அதன் GitHub releases பக்கத்தில் .deb packages-ஐ வெளியிடுகிறது. 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-ஐ உருவாக்கி, இயல்புநிலை /etc/headscale/config.yaml-ஐ எழுதுகிறது, மேலும் systemd unit-ஐ நிறுவுகிறது. இது service-ஐ தொடங்காது. அதுவே சரியான வரிசையாகும். நிறுவப்பட்ட configuration, server_url-ஐ http://127.0.0.1:8080-க்கு சுட்டுகிறது. உங்கள் எந்த client-ம் அணுக முடியாத address அது. எனவே இப்போது தொடங்கப்படும் service இயங்கத் தொடங்கினாலும் தவறாக இருக்கும். இந்த நிலையில் 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 ஒவ்வொரு client registration-லும் எழுதும் முகவரி. அதன் பிறகு clients அதே சரத்தை மட்டுமே பயன்படுத்தி எப்போதும் இணையும். எனவே இது https://-ஐ முன்னொட்டாகக் கொண்ட public name ஆக இருக்க வேண்டும். 127.0.0.1 ஆக இருக்கக் கூடாது.

listen_addr என்பது process bind ஆகும் முகவரி. இதை loopback-ல் வைத்திருக்கவும். அதே server-ல் இயங்கும் reverse proxy, TLS (transport layer security)-ஐ நிறைவு செய்து, கோரிக்கைகளை இதற்கு forward செய்கிறது. எனவே server-க்கு வெளியிலிருந்து port 8080-ஐ அணுக வேண்டியதில்லை.

base_domain என்பது MagicDNS suffix. உங்கள் nodes பெறும் domain names இதன் கீழ் அமையும். இது trailing dot இல்லாத fully qualified domain name ஆக இருக்க வேண்டும். மேலும், இது server_url-ல் உள்ள domain-இலிருந்து வேறுபட்டதாக இருக்க வேண்டும். இல்லையெனில் இரண்டு name spaces ஒன்றுடன் ஒன்று மோதும்.

database section-ஐ மாற்றாமல் விடவும். இயல்புநிலை database /var/lib/headscale/db.sqlite-ல் உள்ள 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 இரண்டு பணிகளையும் செய்கிறது: சேவையைத் தொடங்குகிறது, மேலும் reboot பிறகு அது தொடங்குமாறு அமைக்கிறது.

is-active, failed என்பதை அச்சிட்டால், sudo journalctl -u headscale -n 50 --no-pager மூலம் journal-ஐப் படிக்கவும். இந்த நிலையில் ஏற்படும் தோல்விக்கு பெரும்பாலும் configuration file-தான் காரணம். ஏனெனில் socket-ஐத் திறப்பதற்கு முன் headscale முழு file-ஐ parse செய்கிறது. எனவே தவறான indentation அல்லது அறியப்படாத 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

இரண்டு வரிகளும் package உருவாக்கிய unprivileged user-ஆன headscale என்பதிலேயே தொடங்குகின்றன. noise_private.key என்பது clients-க்கு server-ன் identity ஆகும். அதை வைத்திருக்கவும். அதை delete செய்தால், headscale புதிய identity-ஐ உருவாக்கும்; ஒவ்வொரு node-ம் மீண்டும் register செய்ய வேண்டும்.

headscale முன் TLS-ஐ அமைக்கவும்

Clients, server_url-ஐ HTTPS வழியாக அணுக வேண்டும். Caddy எளிய வழியாகும். ஏனெனில் அது தானாகவே certificate-ஐ கோரி புதுப்பிக்கிறது.

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

File parse ஆகும்போது validate, adapted config to JSON-ஐ print செய்கிறது. File formatted இல்லை என்ற warning-ஐப் பொருட்படுத்த வேண்டாம். உங்கள் laptop-இலிருந்து curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health இயக்கினாலும் 200 print ஆக வேண்டும். இந்த ஒரே check, DNS, firewall, certificate மற்றும் 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-ஐ return செய்து, அனைத்தும் சரியாக இருப்பது போலத் தோன்றும். ஆனால் நீண்டநேர control connection உருவாகாது. உங்கள் nodes register ஆன பிறகு offline நிலையில் இருக்கும். nginx வழியைத் தேர்ந்தெடுத்தால், Ubuntu 24.04-ல் nginx உடன் Certbot certificate பகுதியை விளக்குகிறது.

UFW-ல் திறக்க வேண்டிய ports

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

Port 443 அனைத்து client தொடர்புகளையும் கையாளுகிறது. Port 80, ACME (automatic certificate management environment) HTTP challenge மற்றும் HTTPS-க்கு redirect செய்வதற்காக மட்டுமே உள்ளது. Caddy-க்கு certificate பெற Port 80 தேவை.

Port 8080 மூடப்பட்டே இருக்கும். listen_addr என்பது 127.0.0.1:8080 ஆகும். எனவே proxy, loopback interface வழியாக headscale-ஐ அணைகிறது; firewall rule தேவையில்லை. Port 8080-ஐ இணையத்திற்கு திறந்தால், clients-க்கு cleartext control channel கிடைக்கும்; அதனால் எந்தப் பயனும் இல்லை. பெரும்பாலான providers, UFW-யிலிருந்து தனியாக தங்கள் control panel-ல் இரண்டாவது firewall-ஐ இயக்குகின்றன என்பதை நினைவில் கொள்ளுங்கள். எனவே ஒரு port server-ல் திறந்திருந்தாலும், edge-ல் மூடப்பட்டிருக்கலாம். VPS-ல் UFW firewall அடிப்படைகள் பகுதியில் rule 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 தோல்வியடையும். இந்த வழிகாட்டியில் ordering முக்கியமானதற்கான மற்றொரு காரணம் இதுவாகும். மேலும், உங்கள் சொந்த account-ஐ headscale group-ல் சேர்க்காவிட்டால், இதற்கு sudo தேவைப்படும்.

users list ஒவ்வொரு name-க்கும் அருகில் ஒரு ID-ஐ அச்சிடும். அந்த எண்ணை நீங்கள் பயன்படுத்த வேண்டும். ஏனெனில் key command-க்கு name அல்ல, 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-ஐ இணைக்கவும்

இணைக்க வேண்டிய machine-ல்:

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 ஒதுக்கிய address-ஐ அச்சிடும். அது 100.64.0.1 போன்றதாக இருக்கும். server-க்கு திரும்பி, sudo headscale nodes list அந்த node-ஐ அதன் ID, user மற்றும் online நிலை ஆகியவற்றுடன் காட்டும்.

--login-server இன் மதிப்பு, scheme உட்படவும் trailing slash இல்லாமலும், server_url உடன் துல்லியமாகப் பொருந்த வேண்டும். இவை strings ஆக ஒப்பிடப்படுகின்றன. பொருத்தமின்மை ஏற்பட்டால், client ஒரு address-க்கு register செய்து, பின்னர் வேறு address-ஐத் தொடர்புகொள்ளுமாறு அறிவுறுத்தப்படும்.

முன்பு Tailscale-ன் hosted service-ல் sign in செய்யப்பட்ட machine, அந்த login-ஐ வைத்திருக்கும். முதலில் அதில் sudo tailscale logout-ஐ இயக்கவும். பின்னர் --login-server உடன் tailscale up-ஐ இயக்கவும்.

--auth-key-ஐ விடுத்தால், client அதற்கு பதிலாக ஒரு URL-ஐ அச்சிடும். அந்த URL-ஐத் திறக்கவும். அந்தப் பக்கம் அந்த registration முயற்சிக்கான identifier-ஐக் காட்டும். அதை server-ல் approve செய்யவும்:

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

இந்த முறை உங்கள் சொந்த laptop-க்கு வசதியானது. Script மூலம் இயக்கப்படும் எதற்கும் preauth keys சிறந்தவை. ஏனெனில் மனிதர் ஒருவர் கண்காணித்துக் கொண்டிருக்க வேண்டியதில்லை.

DERP மற்றும் நேரடி பாதை தோல்வியுற்றால் traffic-ஐ relay செய்யும் அமைப்பு

DERP (designated encrypted relay for packets) என்பது fallback பாதையாகும். இரண்டு nodes-ஆல் நேரடி WireGuard connection-ஐ தொடங்க முடியாதபோது, பொதுவாக இரண்டும் strict NAT (network address translation)-க்குப் பின்னால் இருப்பதால், அவை packets-ஐ relay வழியாக அனுப்புகின்றன. 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-ஐ காலியாக்கினால், map-இலிருந்து Tailscale-ன் relays நீக்கப்படும். செயல்படும் embedded relay இல்லாமல் இதைச் செய்தால், நேரடியாக connect ஆக முடியாத எந்த nodes ஜோடியும் ஒன்றுடன் ஒன்று connect ஆக முடியாது.

ஒரு client-இலிருந்து, tailscale netcheck அது அறிந்துள்ள ஒவ்வொரு relay region-க்கும் latency-ஐக் காட்டுகிறது. tailscale status ஒவ்வொரு peer-ஐயும் address உடன் direct அல்லது region code உடன் relay எனக் குறிக்கிறது. relay நிலையில் சிக்கியுள்ள peer-க்கு NAT பிரச்சினை உள்ளது; இது headscale பிரச்சினை அல்ல.

ஒரு node offline என ஏன் காட்டப்படுகிறது?

proxy upgrade கோரிக்கையைத் தடுக்கிறது. இது பொதுவாக ஏற்படும் காரணம். மற்ற அனைத்தும் சரியாக இருப்பது இதன் அறிகுறியாகும்: /health 200-ஐ திருப்பி அளிக்கிறது, headscale nodes list node-ஐ காட்டுகிறது, ஆனால் node online ஆகாது. Control connection என்பது Upgrade: tailscale-control-protocol-ஐ கொண்ட POST கோரிக்கையாகும். இதை forward செய்யாத proxy, node நிலையைத் தெரிவிக்கும் ஒரே channel-ஐ முடக்குகிறது. உங்கள் nginx configuration-ஐ மேலே உள்ள map block-உடன் ஒப்பிடுங்கள். அல்லது proxy காரணமல்ல என்பதை உறுதிப்படுத்த Caddy-க்கு மாறுங்கள்.

nodes பதிவு செய்யப்பட்ட பிறகு server_url மாறிவிட்டது. பதிவு செய்யும் போது வழங்கப்பட்ட value-ஐயே nodes தொடர்ந்து பயன்படுத்துகின்றன. அதைத் திருத்தியிருந்தால், ஒவ்வொரு 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 செய்யவோ அணுகவோ முடியாத client, தனது retry முயற்சிகளை அங்கே log செய்கிறது.

key காலாவதியாகிவிட்டது. இது அடுத்த பகுதியில் விளக்கப்பட்டுள்ளது.

சோதனை செய்யும் போது server பக்கத்தைப் பார்க்க, VPS-ல் sudo journalctl -u headscale -f இயக்கி, client-ல் tailscaled-ஐ restart செய்யுங்கள். headscale-ஐ அடையும் node உடனடியாக log lines உருவாக்கும். எந்த output-மும் இல்லையெனில் request வந்தடையவில்லை என்று பொருள். எனவே headscale-ஐ ஆய்வு செய்வதற்கு முன் DNS, firewall மற்றும் proxy ஆகியவற்றைச் சரிபாருங்கள்.

Key expiry, மற்றும் சில வாரங்களுக்குப் பிறகு செயல்படாமல் போகும் node

இரண்டு தனித்தனி expiry காலங்கள் உள்ளன. அவற்றைக் குழப்புவது நேரத்தை வீணாக்கும்.

Preauth keys வடிவமைப்பின்படி விரைவாக expire ஆகும். இயல்புநிலை one hour மற்றும் one use ஆகும். tailscale up key-ஐ ஏற்கவில்லை என்றால், client-ல் எதையும் திருத்துவதற்குப் பதிலாக server-ல் புதிய key-ஐ உருவாக்கவும்.

Node keys நீண்டகாலம் செயல்படும் பகுதி. config.yaml-ன் node section, expiry: 0-ஐ அமைக்கிறது. 0 என்பது இயல்புநிலை expiry இல்லை என்பதைக் குறிக்கும். பதிவு செய்யப்பட்ட node-ஐ நீங்கள் expire செய்யும் வரை அது valid ஆக இருக்கும். 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-ஐ இழந்தால், இதை கையால் செய்யவும். sudo headscale nodes list node-ன் ID-ஐ வழங்கும். அதன் பிறகு sudo headscale nodes expire -i 3 அந்த node-ஐ logout செய்யும். sudo headscale nodes delete -i 3 அதை network-இலிருந்து முழுமையாக நீக்கும்.

காப்புப்பிரதிகள் மற்றும் மேம்படுத்தல்கள்

/var/lib/headscale மற்றும் /etc/headscale ஆகிய இரண்டும் சேர்ந்து முழு server ஆகும். அவற்றை copy செய்வதற்கு முன் service-ஐ நிறுத்தவும். SQLite-ல் எழுதும் செயல்பாடுகள் நடந்து கொண்டிருக்கலாம். Load நிலையில் copy செய்யப்பட்ட 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

இரண்டு files-ஐயும் இந்த box-இலிருந்து வெளியே நகர்த்தவும். அவற்றில் private keys மற்றும் அனைத்து registrations-உம் உள்ளன. எனவே அவற்றை server-க்கு வழங்கும் அதே பாதுகாப்புடன் கையாள வேண்டும். VPS-இலிருந்து restic backups என்ற பகுதி, இதை திட்டமிட்ட நேரஅட்டவணைப்படியும் encrypted முறையிலும் செய்வதை விளக்குகிறது.

Upgrades, install செயல்முறையை மீண்டும் செய்கின்றன: புதிய .deb, sudo apt install ./headscale.deb-ஐ download செய்து, பின்னர் restart செய்து is-active மற்றும் /health checks-ஐ மீண்டும் இயக்கவும். 0.29 முதல் upgrade path கடுமையாகக் கட்டுப்படுத்தப்படுகிறது. Minor version-ஐத் தவிர்த்து முன்னேறுவது தடுக்கப்படுகிறது. பழைய minor version-க்கு downgrade செய்வதும் தடுக்கப்படுகிறது. ஒவ்வொரு முறையும் ஒரு minor version மட்டுமே முன்னேறவும். ஒவ்வொரு படிக்கும் முன் backup எடுக்கவும். முதலில் அந்த version-ன் release notes-ஐப் படிக்கவும். ஏனெனில் அதே release ACL policy-யின் நடத்தையை மாற்றியதுடன், பல configuration keys-ஐ இடமாற்றியது.

FAQ

headscale-ஐ .deb நிறுவிய உடனே தொடங்குவதில் ஏன் தோல்வி ஏற்படுகிறது?

Package 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 பிழையாக இருக்கும். ஏனெனில் headscale port-ஐ bind செய்வதற்கு முன் முழு file-ஐ parse செய்கிறது.

எனது machines-ல் வழக்கமான Tailscale client-ஐ இன்னும் நிறுவ வேண்டுமா?

ஆம். Headscale control server-ஐ மட்டுமே மாற்றுகிறது. ஒவ்வொரு node-லும் Tailscale வழங்கும் official client இயங்கும். sudo tailscale up --login-server https://headscale.example.com மூலம் அந்த client-ஐ உங்கள் server-க்கு சுட்டிக்காட்டலாம். அந்த flag standard client-ல் உள்ளது. எனவே patch செய்வதோ rebuild செய்வதோ தேவையில்லை.

எனது traffic headscale server வழியாகச் செல்கிறதா?

பொதுவாக இல்லை. Headscale network-ஐ ஒருங்கிணைத்து keys மற்றும் addresses-ஐ வழங்குகிறது. Data path-ல் WireGuard உங்கள் nodes-க்கு இடையே நேரடியாக இயங்குகிறது. இரண்டு nodes-ம் ஒன்றையொன்று நேரடியாக அடைய முடியாதபோது மட்டுமே traffic மாற்றுப்பாதையில் செல்கிறது. அப்போது அது DERP relay-ஐப் பயன்படுத்தும். Shipped configuration-ல் அந்த relays Tailscale-ன் public relays ஆகும். குறிப்பிட்ட peer direct ஆக உள்ளதா அல்லது relay-ல் உள்ளதா என்பதை node-ல் tailscale status இயக்கிப் பார்க்கவும்.

பதிவு செய்த பிறகும் எனது node 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 தேவையில்லை. இதனால் proxy காரணமா என்பதை விரைவாகச் சோதிக்க Caddy உதவும்.

headscale-க்கு domain name மற்றும் TLS தேவையா?

நடைமுறையில், ஆம். Clients server_url-ல் நீங்கள் இடும் string-க்கு connect ஆகும். Certificates names-க்காக issue செய்யப்படுகின்றன; bare IP addresses-க்காக அல்ல. மேலும், DERP-க்கு TLS தேவை என்று configuration file குறிப்பிடுகிறது. Domain மற்றும் Caddy அமைக்க சுமார் five minutes ஆகும். இதனால் தானாக renew ஆகும் HTTPS endpoint கிடைக்கும். Control server-ஐ plain HTTP வழியாக இயக்கினால், அதனுடன் ஒவ்வொரு client-ன் communication-மும் internet வழியாக encryption இல்லாமல் செல்கிறது.