ஆல் Matt Connor 2026-07-30 · புதுப்பிக்கப்பட்டது 2026-08-28

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

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

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

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

நடைமுறையில், ஆம். server_url-ல் நீங்கள் குறிப்பிடும் முகவரிக்குத்தான் client-கள் இணையும். சான்றிதழ்கள் (certificates) IP முகவரிகளுக்கு வழங்கப்படாமல், பெயர்களுக்கு மட்டுமே வழங்கப்படுகின்றன. மேலும், DERP-க்கு TLS அவசியம் என்று configuration கோப்பு குறிப்பிடுகிறது. ஒரு domain மற்றும் Caddy-ஐப் பயன்படுத்தினால், ஐந்து நிமிடங்களில் தானாகவே புதுப்பிக்கப்படும் HTTPS endpoint-ஐப் பெறலாம். Control server-ஐ plain HTTP-ல் இயக்கினால், client-களுடனான அனைத்துத் தொடர்புகளும் இணையத்தில் பாதுகாப்பற்ற முறையில் (clear text) செல்லும்.

உங்கள் VPS-ல் Headscale-ஐ நிறுவி சொந்தமாக Tailscale control server-ஐ உருவாக்குவது எப்படி என்பதை அறிக. .deb கோப்பு நிறுவல், server_url அமைப்பு மற்றும் முதல் node-ஐ இணைக்கும் முறைகள்.

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-லும் அதிகாரப்பூர்வமான tailscale client-ஐயே பயன்படுத்த வேண்டும். --login-server flag-ஐப் பயன்படுத்தி, அதை உங்கள் server-க்குச் சுட்டிக்காட்ட வேண்டும்.

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

Headscale ஒரு instance-க்கு ஒரு tailnet-ஐ (ஒரு Tailscale network) மட்டுமே கையாளும். இது தனிப்பட்ட பயன்பாட்டிற்கு அல்லது சிறிய நிறுவனங்களுக்கு ஏற்றது என்று இந்தத் திட்டம் குறிப்பிடுகிறது. மூன்று அல்லது நான்கு machine-கள் மட்டுமே இருந்தால், உங்களுக்குச் சொந்தமான VPS-ல் ஒரு சாதாரண WireGuard VPN அமைப்பது எளிது; இதில் மென்பொருள் குறைவு, சிக்கல்களும் குறைவு. ஒவ்வொரு புதிய laptop-க்கும் கைமுறையாக [Peer] block-ஐ எழுத விரும்பாதபோது Headscale பயனுள்ளதாக இருக்கும். உங்களுக்கு ஒரு self-hosted control plane தேவைப்பட்டு, Tailscale-க்கு மாற்றாக இல்லாமல், சொந்த client மற்றும் peers-ஐ நிர்வகிக்க web interface வேண்டும் என்றால், ஒரே VPS-ல் NetBird ஒரு சிறந்த மாற்றாகும். இந்த இரண்டு மாதிரிகளின் விரிவான ஒப்பீட்டிற்கு, 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-ஆக இருக்கக்கூடாது.
இணைக்கப்பட வேண்டிய ஒரு client machine (Linux, macOS, Windows, Android அல்லது iOS இயங்குதளத்தில் இருக்க வேண்டும்).

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

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

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

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

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

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

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

database பகுதியை மாற்ற வேண்டாம். இயல்புநிலை அமைப்பாக /var/lib/headscale/db.sqlite-ல் SQLite உள்ளது; இது தொகுப்பு (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 முழு கோப்பையும் parse செய்யும்; எனவே, தவறான indent அல்லது அறியப்படாத key இருந்தால், எதையும் listen செய்வதற்கு முன்பே process நின்றுவிடும். கோப்பைச் சரிசெய்துவிட்டு, பிறகு sudo systemctl restart headscale கட்டளையை இயக்கவும். பிற்காலத்தில் செய்யப்படும் ஒவ்வொரு configuration மாற்றத்திற்கும் இதேபோல் restart செய்ய வேண்டும். அதன் பிறகு clients தானாகவே மீண்டும் இணைந்துகொள்ளும். systemd units உங்களுக்குப் புதியவை என்றால், systemd மூலம் உங்கள் சொந்த services மற்றும் timers-ஐ இயக்குதல் என்ற பகுதி இங்கு பயன்படுத்தப்பட்ட கட்டளைகளை விளக்குகிறது.

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

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

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

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) என்ற எச்சரிக்கை ஒரு சாதாரண விஷயம். உங்கள் மடிக்கணினியிலிருந்து, 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 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-கள் பதிவு செய்யப்பட்டாலும் offline-லேயே இருக்கும். நீங்கள் nginx-ஐத் தேர்வு செய்தால், Certbot on Ubuntu 24.04 with nginx பகுதியில் 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 செய்வதற்காகவும் மட்டுமே உள்ளது; certificate பெறுவதற்கு Caddy-க்கு இது அவசியம்.

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

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

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

இந்த key ஒருமுறை மட்டுமே திரையில் காட்டப்படும். அதை இப்போதே நகலெடுத்துக் கொள்ளுங்கள். ஒரு preauth key என்பது ஒருமுறை மட்டுமே பயன்படுத்தக்கூடியது மற்றும் ஒரு மணி நேரம் மட்டுமே செல்லுபடியாகும். எனவே, நீங்கள் சோதனையில் இருக்கும்போது --expiration 24h-ஐ அமைப்பது பயனுள்ளதாக இருக்கும். பல இயந்திரங்களை இணைக்கக்கூடிய 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 போன்ற வடிவில் இருக்கும். மீண்டும் server-ல், sudo headscale nodes list கட்டளையானது அந்த node-ன் ID, அதன் பயனர் மற்றும் அதன் online நிலையை காட்டும்.

--login-server-ன் மதிப்பு server_url-உடன் சரியாகப் பொருந்த வேண்டும்; இதில் scheme-ஐயும் சேர்க்க வேண்டும், இறுதியில் slash (/) இருக்கக்கூடாது. இவை string-களாக ஒப்பிடப்படுகின்றன, எனவே இதில் மாற்றம் இருந்தால், client ஒரு முகவரியில் பதிவு செய்துவிட்டு, வேறொரு முகவரியுடன் தொடர்பு கொள்ளுமாறு அறிவுறுத்தப்படும்.

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

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

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

அந்தப் படிவம் உங்கள் சொந்த மடிக்கணினிக்கு வசதியாக இருக்கும். ஸ்கிரிப்ட் மூலம் செய்யப்படும் எதற்கும் Preauth keys சிறந்தது, ஏனெனில் அப்போது மனிதர் யாரும் அதைக் கவனிக்க வேண்டிய அவசியமில்லை. VPS ஒரு node-ஆக மாறியவுடன், அது உங்கள் மற்ற கணினிகளின் இணைய போக்குவரத்தையும் கையாள முடியும், இதுவே exit node அமைப்பு ஆகும். இதில் உள்ள ஒரே வித்தியாசம் என்னவென்றால், hosted admin console-க்கு பதிலாக, நீங்கள் headscale கட்டளையைப் பயன்படுத்தி server-ல் advertised route-ஐ அங்கீகரிக்க வேண்டும்.

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

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

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

உங்கள் சொந்த ரிலேவை இயக்க, config.yaml-ல் உள்ள derp.server-ன் கீழ் enabled: true-ஐ அமைக்கவும், headscale-ஐ மறுதொடக்கம் செய்யவும், மேலும் sudo ufw allow 3478/udp-ஐப் பயன்படுத்தி STUN (session traversal utilities for NAT) port-ஐத் திறக்கவும். கட்டமைப்பு கோப்பு (configuration file) தேவையைத் தெளிவாகக் கூறுகிறது: server_url கண்டிப்பாக https-ஐப் பயன்படுத்த வேண்டும், ஏனெனில் DERP-க்கு TLS தேவைப்படுகிறது. derp.urls பட்டியலை காலி செய்வது Tailscale-ன் ரிலேக்களை வரைபடத்திலிருந்து நீக்கிவிடும். அவ்வாறு செய்யும்போது, சரியாகச் செயல்படும் embedded relay இல்லையென்றால், நேரடியாக இணைய முடியாத எந்தவொரு முனை ஜோடியும் எவ்விதத்திலும் இணைய முடியாது.

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

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

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

Nodes பதிவு செய்த பிறகு server_url மாற்றப்பட்டது. பதிவு செய்யும் போது வழங்கப்பட்ட மதிப்பையே 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, தனது மறுமுயற்சிகளை (retries) அங்கே பதிவு செய்யும்.

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

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

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

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

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

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

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

Backups and upgrades

/var/lib/headscale மற்றும் /etc/headscale ஆகிய இரண்டும் முழு server-ஐயும் குறிக்கின்றன. இவற்றை நகலெடுக்கும் முன் service-ஐ நிறுத்தவும், ஏனெனில் SQLite-ல் தரவுகள் எழுதப்படும்போது நகலெடுத்தால் database சீரற்றதாக (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 பகுதியில், இதை எவ்வாறு கால அட்டவணைப்படி (schedule) மற்றும் குறியாக்கத்துடன் (encrypted) செய்வது என்பது விளக்கப்பட்டுள்ளது.

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

FAQ

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

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

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

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

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

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

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

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

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

நடைமுறையில், ஆம். server_url-ல் நீங்கள் குறிப்பிடும் முகவரிக்குத்தான் client-கள் இணையும். சான்றிதழ்கள் (certificates) IP முகவரிகளுக்கு வழங்கப்படாமல், பெயர்களுக்கு மட்டுமே வழங்கப்படுகின்றன. மேலும், DERP-க்கு TLS அவசியம் என்று configuration கோப்பு குறிப்பிடுகிறது. ஒரு domain மற்றும் Caddy-ஐப் பயன்படுத்தினால், ஐந்து நிமிடங்களில் தானாகவே புதுப்பிக்கப்படும் HTTPS endpoint-ஐப் பெறலாம். Control server-ஐ plain HTTP-ல் இயக்கினால், client-களுடனான அனைத்துத் தொடர்புகளும் இணையத்தில் பாதுகாப்பற்ற முறையில் (clear text) செல்லும்.

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

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

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

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

சேவையைத் தொடங்கும் முன் server_url-ஐ உள்ளமைக்கவும்

headscale-ஐத் தொடங்கி அது இயங்குவதை உறுதிப்படுத்துதல்

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

UFW-ல் எந்தெந்த ports-ஐ திறக்க வேண்டும்

பயனர் மற்றும் preauth key-ஐ உருவாக்குதல்

--login-server மூலம் உங்கள் முதல் client-ஐ இணைத்தல்

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

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

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

Backups and upgrades

FAQ

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

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

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

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

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