Headscale மூலம் சொந்தமாக Tailscale server அமைப்பது எப்படி?

Headscale என்றால் என்ன

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

Control server என்பது network-ல் யார் இருக்கிறார்கள் என்பதைத் தீர்மானிக்கும் பகுதியாகும். இது ஒவ்வொரு node-க்கும் 100.64.0.0/10-லிருந்து ஒரு முகவரியை வழங்குகிறது, public keys-ஐப் பகிர்கிறது, மேலும் node-கள் ஒன்றையொன்று எங்கே கண்டறிய வேண்டும் என்று கூறுகிறது. Tunnel-கள் தொடர்ந்து WireGuard-ஆகவே இருக்கும், அவை node-க்கு-node உருவாக்கப்படுகின்றன. நேரடிப் பாதை (direct path) உருவாக்க முடியாத சூழலில் node-கள் relay-க்கு மாறினால் ஒழிய, உங்கள் இரண்டு machine-களுக்கு இடையிலான traffic headscale box வழியாகச் செல்லாது. இந்த ஒருங்கிணைப்புப் பணியை நீங்களே மேற்கொள்வது, அந்தப் பணியின் தன்மையை மாற்றாது, அதன் உரிமையாளரை மட்டுமே மாற்றுகிறது. எனவே, இந்த மாற்றத்தை ஒரு பாதுகாப்பு வெற்றியாகக் கருதும் முன், இந்த மாதிரியில் control server எதை அணுக முடியும், எதை அணுக முடியாது என்பதைப் புரிந்துகொள்வது அவசியம்.

ஒரு instance-க்கு Headscale ஒரு tailnet (ஒரு Tailscale network) மட்டுமே வழங்குகிறது. இதை project தனிப்பட்ட பயன்பாடு அல்லது சிறிய organisation-க்கு ஏற்றதாகக் குறிப்பிடுகிறது. மூன்று அல்லது நான்கு machines மட்டுமே இருந்தால், உங்களுக்குச் சொந்தமான VPS-ல் plain WireGuard VPN இயக்குவது குறைந்த software நிர்வாகத்தையும் குறைந்த சிக்கல்களையும் கொண்டிருக்கும். ஒவ்வொரு புதிய laptop-க்கும் [Peer] block-ஐ கைமுறையாக எழுத விரும்பாத நிலைக்கு வந்தபோது Headscale பயனுள்ளதாக இருக்கும். முதலில் மக்கள் இதைப் பரிசீலிக்கச் செய்வது பெரும்பாலும் cost ஆகும். எனவே, server-ஐ நிர்வகிக்கும் பொறுப்பை ஏற்கும் முன் hosted free plan உண்மையில் எதை உள்ளடக்குகிறது என்பதைப் படிப்பது பயனுள்ளது. ஏனெனில் சில personal machines பொதுவாக அதற்குள் பொருந்தும். அந்த வரம்பை ஏற்கனவே கடந்திருந்தால், ஒவ்வொரு user மற்றும் tagged resource-க்கான paid plans-ன் cost எவ்வளவு என்பதுடன் கணக்கிட்டுப் பாருங்கள். User devices-க்கு வரம்பில்லை; tagged resources-க்கு தனி allowances மற்றும் charges உள்ளன. Self-hosted control plane வேண்டும், ஆனால் Tailscale-ன் drop-in replacement-க்கு பதிலாக உங்களுடைய சொந்த client மற்றும் peers-ஐ நிர்வகிக்க web interface வேண்டும் என்றால், ஒரே VPS-ல் NetBird பரிசீலிக்க வேண்டிய alternative ஆகும். இரண்டும் WireGuard மூலம் உங்கள் traffic-ஐ எடுத்துச் செல்கின்றன. எனவே, access rules-ஐ நீங்கள் எவ்வாறு எழுதுகிறீர்கள், relays எவ்வாறு செயல்படுகின்றன என்பதில்தான் தேர்வு அமையும். அவற்றை install செய்வதற்கு முன், இந்த அம்சங்களில் NetBird மற்றும் Tailscale-ஐ ஒப்பிடுவது பயனுள்ளது. இந்த இரண்டு models பற்றிய விரிவான comparison-க்கு WireGuard மற்றும் Tailscale எவ்வாறு வேறுபடுகின்றன என்பதைப் பார்க்கவும்.

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

• பொது IPv4 முகவரி மற்றும் sudo அணுகல் கொண்ட Ubuntu 24.04 இயங்கும் ஒரு VPS. சர்வர் புதியது என்றால், முதலில் புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற வழிகாட்டியைப் பின்பற்றி முடிக்கவும்.
• அந்த முகவரியைச் சுட்டிக்காட்டும் ஒரு DNS A record. இந்த வழிகாட்டி headscale.example.com-ஐப் பயன்படுத்துகிறது.
• MagicDNS-க்காக இரண்டாவது டொமைன் அல்லது சப்-டொமைன். இந்த வழிகாட்டி tailnet.example.net-ஐப் பயன்படுத்துகிறது. இது server_url-ல் உள்ள அதே டொமைனாக இருக்கக்கூடாது.
• இணைக்கப்பட வேண்டிய ஒரு கிளையண்ட் மெஷின் (Linux, macOS, Windows, Android அல்லது iOS இயங்குதளத்தில்). Headscale 0.29.6 பதிப்பிற்கு Tailscale கிளையண்ட் பதிப்பு 1.80.0 அல்லது அதற்குப் பிந்தையது தேவை.

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

இந்தத் திட்டம் அதன் GitHub releases பக்கத்தில் .deb தொகுப்புகளை வெளியிடுகிறது. அக்டோபர் 27, 2026 நிலவரப்படி, சமீபத்திய நிலையான பதிப்பு 0.29.6 ஆகும், இது அக்டோபர் 24, 2026 அன்று வெளியிடப்பட்டது. கோப்பின் பெயரில் architecture குறிப்பிடப்பட்டிருப்பதால், முதலில் உங்கள் architecture-ஐச் சரிபார்க்கவும்.

sudo apt update
sudo apt install -y wget
dpkg --print-architecture

இது ஒரு சாதாரண x86 VPS-ல் amd64 என்றும், Ampere அல்லது Graviton வகை திட்டங்களில் 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

கோப்பின் பெயருக்கு முன்னால் ./ இருப்பது அவசியம். அது இல்லையென்றால், apt உங்கள் repositories-ல் headscale.deb என்ற தொகுப்பைத் தேடும், அது கிடைக்காததால் தோல்வியடையும்.

இந்தத் தொகுப்பு headscale என்ற system user-ஐ உருவாக்குகிறது, ஒரு இயல்புநிலை /etc/headscale/config.yaml-ஐ எழுதுகிறது, ஒரு systemd unit-ஐ நிறுவுகிறது, பின்னர் service-ஐத் தொடங்குகிறது. எனவே apt முடிவடையும் போது headscale ஏற்கனவே இயங்கிக் கொண்டிருக்கும், மேலும் sudo systemctl is-active headscale கட்டளை active-ஐ அச்சிடும். புதிய நிறுவலில், இந்தத் தொகுப்பு unit-ஐ enable செய்யாது, எனவே நீங்கள் அதை enable செய்யும் வரை reboot-க்குப் பிறகு service மீண்டும் தொடங்காது; கீழே உள்ள restart படிநிலை இதைச் செய்யும். இது வழங்கப்பட்ட configuration-ல் இயங்குகிறது, அது server_url-ஐ http://127.0.0.1:8080-க்குச் சுட்டிக்காட்டுகிறது; இது உங்கள் client-கள் எவராலும் அணுக முடியாத முகவரி ஆகும். வழங்கப்பட்ட listen_addr-ம் loopback-ல் இருப்பதால், இதுவரை எதுவும் வெளிப்படுத்தப்படவில்லை. இருப்பினும், நீங்கள் server_url-ஐ அமைத்து service-ஐ restart செய்யும் வரை எந்த client-ஐயும் இணைக்க வேண்டாம்; அடுத்த இரண்டு படிநிலைகள் இதைச் செய்யும்.

எந்தவொரு client-ம் இணைவதற்கு முன்பே 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 என்பது registration URL-களை உருவாக்கும்போது headscale பயன்படுத்தும் பொது முகவரியாகும். --login-server-ல் உள்ளமைக்கப்பட்ட control முகவரியையே client-கள் பயன்படுத்துகின்றன, எனவே https://-ல் இரண்டிற்கும் ஒரே பொதுப் பெயரைப் பயன்படுத்தவும், ஒருபோதும் 127.0.0.1-ஐப் பயன்படுத்த வேண்டாம். Headscale ஆவணங்களின்படி, plain HTTP அல்லது 443 அல்லாத port-ல் HTTPS-ஐப் பயன்படுத்த முடியும் என்றாலும், production சூழலுக்கு 443 port-ல் HTTPS-ஐப் பயன்படுத்தவே அது கடுமையாகப் பரிந்துரைக்கிறது. இந்த வழிகாட்டியின் பிற பகுதிகள் இதையே அடிப்படையாகக் கொண்டுள்ளன.

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

base_domain என்பது MagicDNS suffix ஆகும்; இது உங்கள் nodes-களுக்குப் பெயர்கள் கிடைக்கும் domain ஆகும். இது trailing dot இல்லாத முழுமையான domain பெயராக (FQDN) இருக்க வேண்டும். மேலும், இது server_url-ல் உள்ள domain-லிருந்து மாறுபட்டதாக இருக்க வேண்டும், இல்லையெனில் இரண்டு name space-களும் ஒன்றோடொன்று மோதிக்கொள்ளும்.

Database பகுதியை மாற்ற வேண்டாம். இயல்புநிலை அமைப்பாக /var/lib/headscale/db.sqlite-ல் SQLite உள்ளது; இது package-ஆல் உருவாக்கப்பட்டு, அதற்குச் சொந்தமான directory-ல் உள்ளது. இந்த அளவிலான 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-ஐ அச்சிடுகிறது. நீங்கள் செய்த மாற்றங்களைச் செயல்படுத்துவதற்கு மறுதொடக்கம் (restart) அவசியமான படியாகும். Headscale தனது configuration-ஐ அது தொடங்கும் போது ஒருமுறை மட்டுமே வாசிக்கும்; எனவே, நீங்கள் மறுதொடக்கம் செய்யும் வரை, package நிறுவிய process பழைய server_url-ஐயே தொடர்ந்து பயன்படுத்தும். sudo systemctl enable --now headscale இந்த வேலையைச் செய்யாது: service ஏற்கனவே இயங்கிக்கொண்டிருப்பதால், --now start கட்டளை எதையும் மாற்றாது, பழைய மதிப்பே தொடர்ந்து பயன்பாட்டில் இருக்கும். கணினி தொடங்கும் போது (boot) service-ஐத் தொடங்குவது enable-ன் வேலை, இது தானாகவே நடக்காது: புதிய நிறுவலின் போது, package service-ஐத் தொடங்குமே தவிர, அதை enable செய்யாது. எனவே, மேலே குறிப்பிட்டபடி sudo systemctl enable headscale கட்டளையை ஒருமுறை இயக்கவும்.

is-active கட்டளை active என்பதைத் தவிர வேறு எதையாவது அச்சிட்டாலோ, அல்லது curl கட்டளை 200 என்பதை அச்சிடவில்லை என்றாலோ, sudo journalctl -u headscale -n 50 --no-pager கட்டளையைப் பயன்படுத்தி journal-ஐப் படிக்கவும். இந்த நிலையில் ஏற்படும் தோல்விக்கு பெரும்பாலும் configuration கோப்பே காரணமாக இருக்கும். ஏனெனில், socket-ஐத் திறப்பதற்கு முன்பே headscale முழு கோப்பையும் parse செய்யும்; எனவே, தவறான indent அல்லது அவசியமான setting விடுபட்டிருந்தால், எதற்கும் முன்பே process நின்றுவிடும். கோப்பைச் சரிசெய்துவிட்டு, பிறகு sudo systemctl restart headscale கட்டளையை இயக்கவும். பிற்காலத்தில் செய்யப்படும் ஒவ்வொரு configuration மாற்றத்திற்கும் இதே மறுதொடக்கம் தேவைப்படும். அதன் பிறகு clients தானாகவே மீண்டும் இணைந்துகொள்ளும். systemd units உங்களுக்குப் புதியது என்றால், running your own services and timers with systemd என்ற பகுதி இங்கே பயன்படுத்தப்பட்ட கட்டளைகளை விளக்குகிறது.

நீங்கள் shell-ல் இருக்கும்போதே state கோப்புகளைச் சரிபார்க்கவும்:

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

இரண்டு வரிகளும் headscale என்ற பயனர் பெயரில் தொடங்குகின்றன; இது package-ஆல் உருவாக்கப்பட்ட, privileged அல்லாத பயனராகும். noise_private.key என்பது அதன் clients-க்கு அந்த server-ன் அடையாளமாகும். இதை அப்படியே வைத்திருக்கவும். இதை நீங்கள் நீக்கினால், headscale புதிய அடையாளத்தை உருவாக்கும்; அப்போது clients மீண்டும் இணைவதற்கு முன்பு புதிய server key-ஐப் பெற வேண்டியிருக்கும். ஏற்கனவே உள்ள பதிவுகள் database-ல் அப்படியே இருக்கும்.

headscale-க்கு முன்னால் TLS-ஐ அமைத்தல்

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

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-ஐ வெளியீடாகக் காட்டும். கோப்பு முறைப்படுத்தப்படவில்லை (formatted) என்ற எச்சரிக்கை ஒரு சாதாரண விஷயம் மட்டுமே. உங்கள் 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 இதை எந்தக் கூடுதல் அமைப்பும் இன்றி அப்படியே கடத்தும். ஆனால் nginx அவ்வாறு செய்யாது, எனவே nginx-ஐப் பயன்படுத்தினால் Upgrade மற்றும் Connection headers-ஐ வெளிப்படையாக forward செய்ய வேண்டும். headscale ஆவணங்கள் இதை ஒரு 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;
    }
}

இந்த வரிகளைத் தவிர்த்தால், சாதாரண கோரிக்கைகள் (ordinary requests) வெற்றி பெறும்; இதனால்தான் /health ஆனது 200 என்ற குறியீட்டைத் தரும் மற்றும் எல்லாம் சரியாக இருப்பது போலத் தோன்றும். ஆனால், control connection உருவாகாது: புதிய nodes-களைப் பதிவு செய்ய முடியாது, ஏற்கனவே உள்ள nodes-கள் மீண்டும் இணையவோ அல்லது online-ல் இருப்பதை அறிவிக்கவோ முடியாது. நீங்கள் nginx-ஐத் தேர்வு செய்தால், nginx உடன் Ubuntu 24.04-ல் 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-களின் control connection-ஐயும் headscale-க்குக் கொண்டு செல்கிறது. நீங்கள் பிற்காலத்தில் embedded DERP relay-ஐ இயக்கினால், அதற்கு 3478/udp தேவைப்படும், அது கீழே விவரிக்கப்பட்டுள்ளது. Port 80 என்பது ACME (automatic certificate management environment) HTTP challenge-க்காகவும், HTTPS-க்கு redirect செய்வதற்காகவும் உள்ளது. Port 80 மூடப்பட்டிருந்தாலும் Caddy-ஆல் certificate பெற முடியும், ஏனெனில் அது port 443-ல் TLS-ALPN challenge-ஐப் பயன்படுத்தும். ஆனால் 80 திறந்திருந்தால், இரண்டு challenge-களும் கிடைக்கும் மற்றும் plain http:// கோரிக்கைகள் redirect செய்யப்படும்.

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

users list ஒவ்வொரு பெயருக்கும் அருகில் ஒரு ID-ஐ அச்சிடும். உங்களுக்கு அந்த எண் தேவை, ஏனெனில் key கட்டளை பெயருக்குப் பதிலாக எண் சார்ந்த user ID-ஐயே எடுத்துக்கொள்ளும்.

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

இந்த key ஒருமுறை மட்டுமே அச்சிடப்படும். அதை இப்போதே நகலெடுத்துக் கொள்ளுங்கள். நீங்கள் வேறுவிதமாகக் குறிப்பிடாதவரை, ஒரு preauth key ஒருமுறை மட்டுமே பயன்படுத்தக்கூடியது மற்றும் ஒரு மணிநேரம் மட்டுமே செல்லுபடியாகும். எனவே, நீங்கள் இன்னும் சோதனையில் இருக்கும்போது --expiration 24h-ஐ அமைப்பது பயனுள்ளதாக இருக்கும். பல இயந்திரங்களை இணைக்கும் key-க்கு --reusable-ஐச் சேர்க்கவும். அத்தகைய key-ஐ கடவுச்சொல் போலக் கையாளவும், ஏனெனில் அதை வைத்திருக்கும் எவரும் உங்கள் network-ல் இணைய முடியும்.

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

--login-server-க்கு server_url-ல் உள்ள பொது HTTPS முகவரியைப் பயன்படுத்தவும். client அதன் control URL-ல் உள்ள trailing slashes-ஐ நீக்கிவிடும்; எனவே, ஒன்றை நீக்க வேண்டும் என்ற கட்டாயமான string ஒப்பீடு எதுவும் இல்லை.

ஏற்கனவே Tailscale-ன் hosted சேவையில் உள்நுழைந்திருந்த ஒரு கணினி அந்த login-ஐ அப்படியே வைத்திருக்கும். முதலில் அதில் sudo tailscale logout கட்டளையை இயக்கவும், பிறகு --login-server உடன் tailscale up கட்டளையை இயக்கவும்.

நீங்கள் --auth-key-ஐத் தவிர்த்தால், client ஒரு URL-ஐ அச்சிடும். அதைத் திறந்து பார்த்தால், அந்தப் பதிவு முயற்சியின் அடையாளங்காட்டி (identifier) தெரியும், அதை நீங்கள் சர்வரில் அங்கீகரிக்க வேண்டும்:

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

அந்தப் படிவம் உங்கள் சொந்த மடிக்கணினிக்கு வசதியாக இருக்கும். ஸ்கிரிப்ட் மூலம் செய்யப்படும் எதற்கும் Preauth keys சிறந்தது, ஏனெனில் மனிதர்கள் யாரும் அதைக் கவனிக்க வேண்டிய அவசியமில்லை. VPS ஒரு node-ஆக மாறியவுடன், அது உங்கள் பிற கணினிகளின் இணைய போக்குவரத்தையும் கையாள முடியும், இதுவே exit node அமைப்பு ஆகும். இதில் உள்ள ஒரே வித்தியாசம் என்னவென்றால், hosted admin console-க்கு பதிலாக headscale கட்டளையைப் பயன்படுத்தி சர்வரிலேயே அந்த route-ஐ நீங்கள் அங்கீகரிக்க வேண்டும். உங்களுக்குத் தேவை இணையத்திற்கான வழி அல்ல, மாறாக அந்த VPS-க்கு பின்னால் உள்ள ஒரு private network-ஐ அணுகுவது என்றால், அதே அங்கீகாரப் படிமுறை அந்த subnet-ஐ உங்கள் tailnet-ன் பிற பகுதிகளுக்கு விளம்பரப்படுத்த உதவும். ஒரு node-லிருந்து முழு நெட்வொர்க்கையும் routing செய்வதற்குப் பதிலாக, ஒரு குறிப்பிட்ட application-ஐ மட்டும் வெளியிடுவது வேறொரு பணியாகும், மேலும் serve மற்றும் funnel ஆகிய இரண்டும் அதைச் செய்வதற்கான வழிகள். இவை இரண்டும் Tailscale-ன் சொந்த certificate மற்றும் ingress கட்டமைப்பைச் சார்ந்தவை என்பதால், இவற்றை headscale வழங்கும் வசதியாகப் பார்க்காமல், hosted-tailnet அம்சங்களாகப் புரிந்துகொள்ளவும்.

DERP, மற்றும் நேரடிப் பாதை தோல்வியடையும் போது போக்குவரத்தை ரிலே செய்வது எப்படி

DERP (designated encrypted relay for packets) என்பது ஒரு மாற்றுப் பாதையாகும். இரண்டு முனைகளுக்கு (nodes) இடையே நேரடி WireGuard இணைப்பை ஏற்படுத்த முடியாதபோது, பொதுவாக இரண்டுமே கடுமையான NAT (network address translation)-க்கு பின்னால் இருப்பதால், அவை பாக்கெட்டுகளை ஒரு ரிலே (relay) வழியாக அனுப்புகின்றன. இந்த ரிலேவிடம் எந்த சாவிகளும் (keys) இல்லாததால், உங்கள் போக்குவரத்தை அதனால் படிக்க முடியாது. எந்தெந்த முனைகள் பேசுகின்றன மற்றும் எவ்வளவு தரவு பரிமாறப்படுகிறது என்பதை மட்டுமே அதனால் பார்க்க முடியும்.

இயல்புநிலை கட்டமைப்பு என்ன செய்கிறது என்பதில் தெளிவாக இருங்கள். Headscale இயல்பாகவே https://controlplane.tailscale.com/derpmap/default-ஐ auto_update_enabled: true மற்றும் update_frequency: 3h உடன் சுட்டிக்காட்டும் வகையில் வருகிறது, எனவே உங்கள் கட்டுப்பாட்டு தளம் (control plane) உங்களுடையது, ஆனால் ரிலேக்கள் Tailscale-னுடையவை. பெரும்பாலான மக்களுக்கு இது ஒரு நியாயமான பரிமாற்றம். இது உங்களுக்குப் பொருந்தவில்லை என்றால், உங்களுக்கான சொந்த ரிலேவை இயக்கவும்.

உங்கள் சொந்த ரிலேவை இயக்க, config.yaml-ல் உள்ள derp.server-க்கு கீழ் enabled: true-ஐ அமைக்கவும். வழங்கப்பட்ட ipv4: 198.51.100.1 மற்றும் ipv6: 2001:db8::1 ஆகியவற்றை உங்கள் ரிலேவின் பொது முகவரிகளைக் கொண்டு மாற்றவும், அல்லது DNS-ஐப் பயன்படுத்த இரண்டு அமைப்புகளையும் நீக்கவும். பின்னர் headscale-ஐ மறுதொடக்கம் செய்து, sudo ufw allow 3478/udp மூலம் STUN (session traversal utilities for NAT) போர்ட்டைத் திறக்கவும். அந்த முகவரி அமைப்புகள் DNS-ஐ மீறிச் செயல்படும், எனவே ஏதேனும் ஒரு placeholder-ஐ அப்படியே விட்டால், அது வாடிக்கையாளர்களை அடைய முடியாத முகவரிக்கு அனுப்பிவிடும். கட்டமைப்பு கோப்பு தேவையைத் தெளிவாகக் கூறுகிறது: server_url கண்டிப்பாக https-ஐப் பயன்படுத்த வேண்டும், ஏனெனில் DERP-க்கு TLS தேவை. derp.urls பட்டியலை காலி செய்வது Tailscale-ன் ரிலேக்களை வரைபடத்திலிருந்து நீக்கிவிடும்; அவ்வாறு செய்வதற்கு முன், செயல்படும் உட்பொதிக்கப்பட்ட (embedded) அல்லது தனிப்பயன் ரிலே இருப்பதை உறுதிப்படுத்தவும். ரிலே வரைபடம் காலியாக இருந்தால் Headscale தொடங்க மறுக்கும், மேலும் அடைய முடியாத ரிலேவை மட்டும் கொண்ட வரைபடம், நேரடியாக இணைக்க முடியாத முனைகளைத் தொடர்புகொள்ள முடியாமல் செய்துவிடும்.

ஒரு கிளையண்டிலிருந்து, tailscale netcheck தனக்குத் தெரிந்த ஒவ்வொரு ரிலே பிராந்தியத்திற்கும் உள்ள தாமதத்தை (latency) அச்சிடும், மேலும் tailscale status செயலில் உள்ள சக இணைப்புகளுக்கு (peer connections) direct-ஐ முகவரியுடனும் அல்லது relay-ஐ பிராந்திய குறியீட்டுடனும் காட்டும். relay-ல் சிக்கியுள்ள ஒரு சக இணைப்பிற்கு, NAT மற்றும் firewall விதிகள் உட்பட அதன் நேரடிப் பாதையைச் சரிபார்க்க வேண்டும். direct நிலையில் இருந்தும் மெதுவாக இருக்கும் ஒரு சக இணைப்பு வேறொரு சிக்கலாகும், மேலும் அதற்கான பொதுவான பதில் tunnel-ஐ விட MTU தொடர்பானதாகவே இருக்கும்.

ஒரு node ஏன் offline-ல் காட்டுகிறது?

Proxy மேம்படுத்தலை (upgrade) தடுக்கிறது. இதன் அறிகுறி என்னவென்றால், /health 200 என்ற குறியீட்டைத் தரும், ஆனால் புதிய பதிவுகள் (registrations) தோல்வியடையும் அல்லது ஏற்கனவே உள்ள node-கள் மீண்டும் இணைய முடியாது. கட்டுப்பாட்டு இணைப்பு (control connection) என்பது Upgrade: tailscale-control-protocol-ஐக் கொண்டு செல்லும் ஒரு POST கோரிக்கையாகும்; இதை முன்னோக்கி அனுப்பாத (forward) ஒரு proxy, பதிவையும் node-ன் நிலையைத் தெரிவிக்கும் channel-ஐயும் தடுக்கும். உங்கள் nginx அமைப்பை மேலே உள்ள upgrade வரிகளுடன் ஒப்பிட்டுப் பாருங்கள், அல்லது proxy-ல் சிக்கல் இல்லை என்பதை உறுதிப்படுத்த Caddy-க்கு மாறிப் பாருங்கள்.

பொதுக் கட்டுப்பாட்டு முகவரி (public control address) மாறிவிட்டது. Node-கள் --login-server-ல் உள்ளமைக்கப்பட்ட முகவரிக்கே தொடர்ந்து அழைப்பு விடுக்கின்றன; server_url-ஐ மாற்றுவது அந்த client அமைப்பைப் புதுப்பிக்காது. பழைய முகவரி உங்கள் 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) அல்லது அடையவோ முடியாத client, அதன் மறுமுயற்சிகளை (retries) அங்கு பதிவு செய்யும்.

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

நீங்கள் சோதிக்கும்போது server பக்கத்தைக் கண்காணிக்க, VPS-ல் sudo journalctl -u headscale -f-ஐ இயக்கி, client-ல் tailscaled-ஐ restart செய்யவும். Client journal-ஐயும் சரிபார்க்கவும்: headscale-க்கு வரும் ஒரு கோரிக்கை, இயல்புநிலை log நிலையில் ஒரு வரியை உருவாக்கும் என்பதற்கு உத்தரவாதம் இல்லை. எனவே, server log-ல் எந்தத் தகவலும் இல்லை என்பது மட்டும் DNS, firewall அல்லது proxy தோல்வியை உறுதிப்படுத்தாது.

Key expiry, மற்றும் சில வாரங்களுக்குப் பிறகு இயங்குவதை நிறுத்தும் node

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

Preauth keys வடிவமைப்பின்படி விரைவாகவே காலாவதியாகிவிடும். இயல்பான அமைப்பு ஒரு மணிநேரம் மற்றும் ஒரு பயன்பாடு மட்டுமே. tailscale up அந்த key-ஐ ஏற்கவில்லை என்றால், client-ல் எதையும் மாற்றாமல், server-ல் புதிய key-ஐ உருவாக்கவும்.

Node keys நீண்ட காலம் நீடிக்கும் தன்மை கொண்டவை. config.yaml-ன் node பகுதி expiry: 0-ஐ அமைக்கிறது; 0 என்பது இயல்பான காலாவதி தேதி இல்லை என்பதைக் குறிக்கிறது. இருப்பினும், client கோரும் காலாவதி தேதி அல்லது OIDC காலாவதி தேதி இன்னும் பொருந்தக்கூடும். Tagged nodes தானியங்கி காலாவதியிலிருந்து விலக்கு அளிக்கப்பட்டுள்ளன, ஆனால் ஒரு நிர்வாகி அவற்றை நேரடியாகக் காலாவதியாக்க முடியும். Tag செய்யப்படாத பதிவுகளுக்கு 180-நாள் காலாவதி தேவைப்பட்டால் expiry: 180d-ஐ அமைக்கவும். ஆனால், client கோரும் காலாவதி தேதிக்கு முன்னுரிமை உண்டு, மேலும் OIDC இந்த இயல்பான அமைப்பை மீறக்கூடும். இந்த அமைப்பை மாற்றுவது ஏற்கனவே உள்ள பதிவுகளைப் பின்னோக்கி மாற்றாது. காலாவதி தேதி கொண்ட ஒரு node, அந்த காலக்கெடுவுக்கு முன் sudo tailscale up --login-server https://headscale.example.com --force-reauth-ஐப் பயன்படுத்தி மீண்டும் அங்கீகாரம் (re-authentication) பெற வேண்டும். யாரும் மீண்டும் அங்கீகரிக்காத ஒரு headless server, அதன் பதிவு காலாவதியாகும் போது network-லிருந்து வெளியேறிவிடும்.

யாராவது laptop-ஐத் தொலைத்துவிட்டால், அதை நீங்களே கையாளுங்கள். sudo headscale nodes list உங்களுக்கு ID-ஐ வழங்கும், பின் sudo headscale nodes expire -i 3 அந்த node-ஐ logout செய்யும், மேலும் sudo headscale nodes delete -i 3 அதை network-லிருந்து முழுமையாக நீக்கும்.

Backups and upgrades

/var/lib/headscale மற்றும் /etc/headscale ஆகிய இரண்டும் முழு server-ஐயும் குறிக்கின்றன. இவற்றை நகலெடுக்கும் முன் service-ஐ நிறுத்திவிடவும். ஏனெனில், SQLite தரவுத்தளத்தில் தரவுகள் எழுதப்படும்போது நகலெடுத்தால், தரவுத்தளம் சீரற்ற நிலையில் (inconsistent) இருக்க வாய்ப்புள்ளது.

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

இரண்டு கோப்புகளையும் server-லிருந்து வெளியே நகர்த்தவும். இவை private keys மற்றும் அனைத்து registration விவரங்களையும் கொண்டிருப்பதால், server-க்கு அளிக்கப்படும் அதே பாதுகாப்பை இவற்றிற்கும் அளிக்க வேண்டும். VPS-லிருந்து restic backups பகுதியில், இவற்றை எவ்வாறு கால அட்டவணைப்படி குறியாக்கத்துடன் (encrypted) காப்புப் பிரதி எடுப்பது என்பது விளக்கப்பட்டுள்ளது.

Upgrades செய்வதற்கு, நிறுவல் முறையை மீண்டும் பின்பற்றவும்: புதிய .deb, sudo apt install ./headscale.deb ஆகியவற்றைத் தரவிறக்கம் செய்து, பின் restart செய்யவும். அதன் பிறகு is-active மற்றும் /health சோதனைகளை மீண்டும் இயக்கவும். 0.29 பதிப்பிலிருந்து, upgrade முறை மிகவும் கண்டிப்பானது. ஒரு minor version-ஐத் தவிர்த்துவிட்டு அடுத்த பதிப்பிற்குச் செல்வது தடுக்கப்பட்டுள்ளது; அதேபோல் பழைய minor version-க்குத் திரும்புவதும் (downgrading) இயலாது. ஒவ்வொரு முறையும் ஒரு minor version-ஆக மட்டும் முன்னேறவும், ஒவ்வொரு படிக்கும் முன் backup எடுக்கவும். அந்தந்த பதிப்பின் release notes-ஐ முதலில் வாசிக்கவும், ஏனெனில் அதே release-ல் ACL policy செயல்பாடுகள் மாற்றப்பட்டு, பல configuration keys மாற்றப்பட்டுள்ளன. Version 0.29.6-ல் certificate validation மற்றும் dependencies தொடர்பான பாதுகாப்பு மேம்பாடுகள் உள்ளதால், ஏற்கனவே 0.29 பதிப்பைப் பயன்படுத்துபவர்கள் இந்த patch release-க்கு மாற வேண்டும்.

FAQ

.deb கோப்பை நிறுவிய உடனேயே headscale இயங்கத் தொடங்கிவிடுமா?

ஆம். தொகுப்பு (package) நிறுவப்பட்டவுடன், அது /etc/headscale/config.yaml-ல் சேவையைத் தொடங்கும். இது loopback-ல் மட்டுமே கேட்கும் (listen) மற்றும் server_url-ஐ http://127.0.0.1:8080 என அமைக்கும். புதிய நிறுவலில் இது சேவையை enable செய்யாது, எனவே நீங்கள் sudo systemctl enable headscale-ஐ இயக்கும் வரை boot-ன் போது அது தொடங்காது. இதில் உள்ள முகவரி வாடிக்கையாளர்களுக்குப் பயன்படாது, எனவே server_url, listen_addr மற்றும் base_domain ஆகியவற்றைத் திருத்தி, பின் sudo systemctl restart headscale-ஐ இயக்கி sudo systemctl is-active headscale மூலம் உறுதிப்படுத்தவும். இது கண்டிப்பாக restart செய்யப்பட வேண்டும்: headscale தொடங்கும் போது மட்டுமே கோப்பை வாசிக்கும், மேலும் ஏற்கனவே இயங்கும் சேவையில் enable --now செய்வது அதை boot-க்காக enable செய்யும், ஆனால் restart செய்யாது, எனவே பழைய மதிப்புகளே செயல்பாட்டில் இருக்கும். restart செய்த பிறகு அது தோல்வியுற்றால், sudo journalctl -u headscale -n 50 --no-pager சிக்கலைத் தெளிவாகக் காட்டும். headscale ஒரு port-ஐ bind செய்வதற்கு முன்பே முழு கோப்பையும் parse செய்வதால், இந்த நிலையில் இது பெரும்பாலும் YAML பிழையாகவே இருக்கும்.

எனது கணினிகளில் சாதாரண Tailscale client-ஐ நிறுவ வேண்டுமா?

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

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

பொதுவாக இல்லை. Headscale பிணையத்தை ஒருங்கிணைத்து, keys மற்றும் முகவரிகளை வழங்கும்; தரவுப் பாதை (data path) உங்கள் node-களுக்கு இடையே நேரடியாக WireGuard மூலம் அமையும். இரண்டு node-கள் நேரடியாகத் தொடர்புகொள்ள முடியாமல் DERP relay-க்கு மாறும்போது மட்டுமே traffic மாற்றுப் பாதையில் செல்லும். வழங்கப்பட்ட configuration-ல் அந்த relay-கள் Tailscale-ன் பொதுவான relay-களாகவே இருக்கும். ஒரு குறிப்பிட்ட peer direct-ல் உள்ளதா அல்லது relay-ல் உள்ளதா என்பதைப் பார்க்க, node-ல் tailscale status-ஐ இயக்கவும்.

எனது node பதிவு செய்த பிறகும் ஏன் offline-லேயே இருக்கிறது?

headscale nodes list-ல் தோன்றும் ஒரு node online-க்கு வரவில்லை என்றால், reverse proxy உட்பட அதன் கட்டுப்பாட்டு இணைப்பைச் (control connection) சரிபார்க்க வேண்டும். அந்த இணைப்பு Upgrade: tailscale-control-protocol header-உடன் POST ஆக அனுப்பப்படும் ஒரு HTTP upgrade ஆகும். நீங்கள் Upgrade மற்றும் Connection header-களை proxy_set_header மூலம் வெளிப்படையாக forward செய்யாவிட்டால், nginx அதைத் தடுத்துவிடும். மேலே உள்ள configuration அதன் map $http_upgrade $connection_upgrade block மூலம் இதைச் செய்கிறது. அந்த header-களைத் தடுக்காமல் இருந்தால், புதிய node-கள் பதிவு செய்வதையும் அது தடுக்கும். Caddy எந்த கூடுதல் configuration-ம் இன்றி இதை forward செய்யும், எனவே proxy-ல் பிழை உள்ளதா என்பதைச் சோதிக்க இது ஒரு விரைவான வழியாகும்.

headscale-க்கு domain name மற்றும் TLS அவசியமா?

இந்த அமைப்புக்கு, ஆம்: domain name மற்றும் HTTPS-ஐப் பயன்படுத்தவும். சான்றிதழ்கள் (certificates) வெறும் IP முகவரிகளையும் உள்ளடக்கும், ஆனால் DERP-க்கு TLS தேவை என்று configuration கோப்பு குறிப்பிடுகிறது. ஒரு domain மற்றும் Caddy-ஐப் பயன்படுத்தினால், ஐந்து நிமிடங்களில் தானாகவே புதுப்பிக்கும் HTTPS endpoint-ஐப் பெறலாம். Plain HTTP சாத்தியம் என்றாலும், headscale-ன் ஆவணங்கள் production பயன்பாட்டிற்கு port 443-ல் HTTPS-ஐப் பயன்படுத்தவே கடுமையாகப் பரிந்துரைக்கின்றன. மேலும், சில சூழ்நிலைகளில் Tailscale client port 443-ல் HTTPS இருக்கும் என்று கருதுவதையும் அது குறிப்பிடுகிறது.