Headscale: Sariling Tailscale Control Server sa VPS

Ano ang headscale

Ang headscale ay isang self-hosted na implementasyon ng Tailscale control server. Ibig sabihin, ang VPS na pagmamay-ari mo ang nagko-coordinate sa iyong private network. Community project ito at hindi pinapatakbo ng Tailscale Inc. Gumagamit pa rin ang bawat machine ng opisyal na tailscale client, na itinuturo sa iyong server gamit ang isang flag, --login-server.

Ang control server ang bahaging nakaaalam kung sino ang kabilang sa network. Binibigyan nito ang bawat node ng address mula sa 100.64.0.0/10, ipinapamahagi ang mga public key, at sinasabi sa mga node kung saan nila mahahanap ang isa't isa. WireGuard pa rin ang mga tunnel at node-to-node ang pagkakabuo ng mga ito. Hindi dumadaan sa headscale box ang traffic sa pagitan ng dalawa mong machine, maliban kung hindi makabuo ng direct path at kailangan ng mga node na gumamit ng relay. Kapag ikaw mismo ang nagpapatakbo ng coordination role na ito, nagbabago kung sino ang may hawak nito, hindi kung ano ang kaya nitong gawin. Kaya mahalagang maunawaan muna kung ano ang maaabot at hindi maaabot ng control server sa modelong ito bago mo ituring ang paglipat bilang security improvement.

Isang tailnet (isang Tailscale network) lang ang sinusuportahan ng bawat headscale instance. Ayon sa proyekto, angkop ito para sa personal na paggamit o maliit na organisasyon. Kung tatlo o apat lang ang machine, mas kaunting software ang kailangang patakbuhin at mas kaunti ang maaaring masira kung plain WireGuard VPN sa VPS na pagmamay-ari mo ang gamitin. Mas kapaki-pakinabang ang headscale kapag ayaw mo nang manu-manong gumawa ng [Peer] block para sa bawat bagong laptop. Kadalasan, gastos ang unang nagtutulak sa mga tao na maghanap ng alternatibo. Kaya basahin muna kung ano talaga ang saklaw ng hosted free plan bago ka magpatakbo ng server, dahil karaniwang kasya rito ang kaunting personal machine. Kung lampas ka na sa limitasyong iyon, ikumpara ang kabuuan sa gastos ng paid plans, na nakabatay sa user at hindi sa device, dahil maaaring manatiling mura ang household na iisang account ang gamit kahit dumami ang device. Kung gusto mo ng self-hosted control plane pero mas nais mong magkaroon ng sarili mong client at web interface para sa pamamahala ng mga peer kaysa sa drop-in replacement para sa Tailscale, ang NetBird sa isang VPS ang alternatibong dapat suriin. Para sa mas malawak na paghahambing ng dalawang modelong ito, tingnan ang pagkakaiba ng WireGuard at Tailscale.

Mga kailangan bago mag-install

• Isang VPS na nagpapatakbo ng Ubuntu 24.04, may public IPv4 address, at may sudo access. Kung bago ang server, gawin muna ang mga hakbang sa unang sampung minuto sa bagong VPS.
• Isang DNS A record na nakaturo sa address na iyon. Ginagamit ng gabay na ito ang headscale.example.com.
• Isang hiwalay na domain o subdomain para sa MagicDNS. Ginagamit ng gabay na ito ang tailnet.example.net. Hindi ito dapat kapareho ng domain sa server_url.
• Isang client machine na sasali, na nagpapatakbo ng Linux, macOS, Windows, Android, o iOS.

I-install ang headscale mula sa opisyal na .deb

Naglalabas ang proyekto ng mga package na .deb sa pahina ng GitHub releases nito. Noong Hulyo 2026, ang kasalukuyang release ay 0.29.3. Suriin muna ang architecture dahil kasama ito sa pangalan ng file.

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

Nagpi-print ito ng amd64 sa karaniwang x86 VPS at arm64 sa planong uri ng Ampere o Graviton. Ilagay ang resulta sa variable sa ibaba.

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

Kailangan ang ./ bago ang pangalan ng file. Kung wala ito, hahanapan ng apt ang mga repository mo ng package na headscale.deb at mabibigo.

Gumagawa ang package ng system user na headscale, nagsusulat ng default na /etc/headscale/config.yaml, nag-i-install ng systemd unit, at ine-enable at sinisimulan ang serbisyo. Kaya tumatakbo na ang headscale kapag nagbalik ang apt, at nagpi-print ang sudo systemctl is-active headscale ng active. Tumatakbo ito gamit ang configuration na kasama sa package, ngunit itinuturo nito ang server_url sa http://127.0.0.1:8080, na hindi address na maaabot ng alinman sa client mo. Wala pang inilalantad na serbisyo dahil loopback din ang listen_addr na kasama sa package, ngunit huwag munang mag-join ng client hanggang maitakda mo ang server_url at ma-restart ang serbisyo. Iyan ang ginagawa ng susunod na dalawang hakbang.

I-configure ang server_url bago sumali ang anumang client

I-edit ang /etc/headscale/config.yaml gamit ang sudo nano /etc/headscale/config.yaml, o ilapat ang parehong tatlong pagbabago gamit ang sed. Magtabi ng kopya ng orihinal, dahil mahaba at maraming komento ang file at ito ang pinakamainam mong reference para sa iba pang setting.

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

Ang server_url ang address na isinusulat ng headscale sa bawat client registration. Tatawagan ng mga client ang eksaktong string na iyon sa lahat ng susunod na pagkakataon, kaya dapat itong public name na may https:// sa unahan, hindi kailanman 127.0.0.1.

Ang listen_addr ang address kung saan nagbi-bind ang process. Iwanan itong nasa loopback. Isang reverse proxy sa parehong server ang nagte-terminate ng TLS (transport layer security) at nagpapasa ng mga request dito, kaya walang nasa labas ng server ang kailangang makaabot sa port 8080.

Ang base_domain ang MagicDNS suffix, o domain kung saan nakukuha ng iyong mga node ang kanilang mga pangalan. Dapat itong fully qualified domain name na walang trailing dot, at dapat itong ibang domain kaysa sa nasa server_url, dahil kung hindi ay mag-o-overlap ang dalawang namespace.

Huwag galawin ang database section. Ang default ay SQLite sa /var/lib/headscale/db.sqlite, sa isang directory na ginawa at pagmamay-ari ng package, at sapat ang SQLite para sa tailnet na ganito ang laki.

I-restart ang headscale at patunayang tumatakbo ito

sudo systemctl restart headscale
sudo systemctl is-active headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/health

Ang is-active ay nagpi-print ng active, at ang curl ay nagpi-print ng 200. Ang restart ang hakbang na naglo-load ng iyong mga pagbabago. Binabasa ng headscale ang configuration nang isang beses, kapag nagsisimula ito. Kaya patuloy na ipinapamahagi ng prosesong sinimulan ng package ang inilabas na server_url hanggang sa i-restart mo ito. Hindi ginagawa ng sudo systemctl enable --now headscale ang trabahong ito. Na-enable at nasimulan na ng package ang service, kaya walang binabago ang command na iyon at nananatiling aktibo ang lumang value. Nakaayos na ang pagsisimula sa boot, at nagpi-print ang sudo systemctl is-enabled headscale ng enabled upang kumpirmahin ito.

Kung may i-print ang is-active maliban sa active, o hindi nagpi-print ang curl ng 200, basahin ang journal gamit ang sudo journalctl -u headscale -n 50 --no-pager. Halos palaging configuration file ang sanhi ng failure sa yugtong ito. Binabasa muna ng headscale ang buong file bago ito magbukas ng socket, kaya pinahihinto ng maling indent o hindi kilalang key ang proseso bago ito magsimulang makinig. Ayusin ang file, pagkatapos ay sudo systemctl restart headscale. Kailangan ang kaparehong restart sa bawat susunod na pagbabago sa configuration. Awtomatikong kumokonekta muli ang mga client pagkatapos nito. Kung bago sa iyo ang systemd units, ipinapaliwanag ng pagpapatakbo ng sarili mong services at timers gamit ang systemd ang mga command na ginamit dito.

Suriin ang state files habang nasa shell ka:

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

Nagsisimula sa headscale ang dalawang linya. Ito ang unprivileged user na ginawa ng package. Ang noise_private.key ang identity ng server para sa mga client nito. Huwag itong tanggalin. Kapag tinanggal mo ito, gagawa ang headscale ng bago at kailangang mag-register muli ang bawat node.

Ilagay ang TLS sa harap ng headscale

Dapat maabot ng mga client ang server_url gamit ang HTTPS. Ang Caddy ang pinakamaikling paraan dahil awtomatiko nitong hinihiling at nire-renew ang certificate.

sudo apt install -y caddy

Palitan ang /etc/caddy/Caddyfile ng block mula sa dokumentasyon ng headscale:

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

Ipinapakita ng validate ang adapted config to JSON kapag tama ang pag-parse sa file. Cosmetic lamang ang warning na hindi naka-format ang file. Mula sa iyong laptop, dapat ding ipakita ng curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health ang 200. Pinatutunayan ng simpleng check na iyon na gumagana nang magkakasama ang DNS, firewall, certificate, at proxy.

Narito ang detalye sa proxy na madalas magpaubos ng isang gabi. Ang control connection ng Tailscale ay isang HTTP upgrade. Sinisimulan ito gamit ang POST sa halip na GET, at ang value ng Upgrade header ay tailscale-control-protocol. Ipinapasa ito ng Caddy nang walang karagdagang configuration. Hindi ito ginagawa ng nginx, kaya kailangan ng nginx front end ang 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;
    }
}

Kapag hindi isinama ang mga linyang iyon, gumagana pa rin ang mga ordinaryong request. Kaya nagbabalik ang /health ng 200 at mukhang maayos ang lahat, ngunit hindi nabubuo ang long-lived control connection at nagre-register ang iyong mga node bago maging offline. Kung nginx ang gagamitin mo, ipinapaliwanag ng Certbot sa Ubuntu 24.04 gamit ang nginx ang bahagi tungkol sa certificate.

Aling mga port ang dapat buksan sa UFW

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

Dumaan ang lahat ng pakikipag-ugnayan ng client sa port 443. Ang port 80 ay para lamang sa ACME (automatic certificate management environment) HTTP challenge at sa redirect papuntang HTTPS. Kailangan ito ng Caddy upang makakuha ng certificate.

Nananatiling sarado ang port 8080. Ang listen_addr ay 127.0.0.1:8080, kaya ina-access ng proxy ang headscale sa loopback interface at walang kailangang firewall rule. Kapag binuksan ang 8080 sa internet, magkakaroon ang mga client ng cleartext control channel nang walang pakinabang. Tandaan na karamihan sa mga provider ay may hiwalay na second firewall sa kanilang control panel, bukod sa UFW. Kaya maaaring bukas ang isang port sa server ngunit sarado pa rin sa edge. Ipinapaliwanag nang mas detalyado ng Mga pangunahing kaalaman sa UFW firewall sa isang VPS ang syntax ng mga rule.

Gumawa ng user at preauth key

sudo headscale users create alice
sudo headscale users list

Client ang headscale command. Kumokonekta ito sa tumatakbong daemon gamit ang unix socket sa /var/run/headscale/headscale.sock, na may mode na 0770 at pagmamay-ari ng headscale group. Dalawang bagay ang resulta nito. Magfa-fail ang command kapag naka-stop ang service. Ito ang isa pang dahilan kung bakit mahalaga ang pagkakasunod-sunod sa gabay na ito. Kailangan din nito ng sudo maliban kung idaragdag mo ang sarili mong account sa headscale group.

Nagpi-print ang users list ng ID sa tabi ng bawat pangalan. Kailangan mo ang numerong iyon dahil numeric user ID ang tinatanggap ng key command, hindi pangalan.

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

Isang beses lang pini-print ang key. Kopyahin ito ngayon. Isang beses lang magagamit ang preauth key at valid ito nang isang oras maliban kung iba ang itatakda mo. Kaya mainam na itakda ang --expiration 24h habang nagte-test ka pa. Idagdag ang --reusable para sa key na mag-e-enroll ng ilang machine. Ituring ito na parang password dahil maaaring sumali sa network mo ang sinumang may hawak nito.

Ikonekta ang unang client gamit ang --login-server

Sa machine na gusto mong isali:

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

Ipinapakita ng tailscale ip -4 ang address na itinalaga ng headscale, gaya ng 100.64.0.1. Bumalik sa server at ipinapakita ng sudo headscale nodes list ang node kasama ang ID nito, user nito, at online state nito.

Dapat eksaktong tumugma ang value ng --login-server sa server_url, kasama ang scheme at walang trailing slash. Bilang mga string ang paghahambing sa mga ito. Kapag hindi nagtugma, magre-register ang client sa isang address at pagkatapos ay uutusan itong kumonekta sa ibang address.

Ang machine na dati nang naka-sign in sa hosted service ng Tailscale ay mananatiling naka-login doon. Patakbuhin muna rito ang sudo tailscale logout, pagkatapos ay patakbuhin ang tailscale up gamit ang --login-server.

Kapag hindi mo isinama ang --auth-key, magpi-print na lang ang client ng URL. Buksan ito. Ipapakita ng page ang identifier para sa registration attempt na iyon, at aaprubahan mo ito sa server:

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

Mas angkop ang form na ito para sa sarili mong laptop. Mas mainam ang preauth keys para sa anumang naka-script, dahil walang taong kailangang magbantay. Kapag node na ang VPS mismo, maaari rin nitong dalhin ang internet traffic ng iba mong machine. Ito ang setup ng exit node, ngunit inaaprubahan mo ang in-advertise na route sa server gamit ang command na headscale sa halip na sa hosted admin console. Kung ang kailangan mo ay access sa private network na nasa likod ng VPS, sa halip na daan palabas sa internet, saklaw din ng parehong approval step ang pag-advertise ng subnet na iyon sa iba pang bahagi ng tailnet mo. Iba naman ang pag-publish ng isang application mula sa isang node kaysa sa pag-route ng buong network dito. Ang serve at funnel ang dalawang paraan para gawin ito, ngunit umaasa ang mga ito sa sariling certificate at ingress machinery ng Tailscale. Ituring ang mga ito bilang hosted-tailnet features, hindi bilang functionality na ibinibigay ng headscale.

DERP, at kung ano ang nagre-relay ng traffic kapag nabigo ang direktang path

Ang DERP (designated encrypted relay for packets) ang fallback path. Kapag hindi makapagbukas ng direktang WireGuard connection ang dalawang node, karaniwan dahil parehong nasa likod ng mahigpit na NAT (network address translation), sa relay nila ipinapadaan ang mga packet. Walang hawak na key ang relay, kaya hindi nito mababasa ang traffic mo. Nakikita nito kung aling mga node ang nag-uusap at kung gaano karaming data ang dumadaan.

Maging malinaw sa ginagawa ng default configuration. Ang Headscale ay naka-configure na tumuro sa https://controlplane.tailscale.com/derpmap/default gamit ang auto_update_enabled: true at update_frequency: 3h, kaya iyo ang control plane habang sa Tailscale naman ang mga relay. Para sa karamihan, makatuwirang trade-off ito. Kung hindi ito katanggap-tanggap sa iyo, magpatakbo ka ng sarili mong relay.

Para magpatakbo ng sarili mong relay, itakda ang enabled: true sa ilalim ng derp.server sa config.yaml, i-restart ang Headscale, at buksan ang STUN (session traversal utilities for NAT) port gamit ang sudo ufw allow 3478/udp. Malinaw na nakasaad sa configuration file ang requirement: dapat https ang server_url dahil nangangailangan ang DERP ng TLS. Kapag inalis laman ang listahan ng derp.urls, mawawala sa map ang mga relay ng Tailscale. Kung gagawin mo ito nang walang gumaganang embedded relay, hindi na makakakonekta ang anumang pares ng node na hindi direktang makakonekta.

Mula sa isang client, inililista ng tailscale netcheck ang latency sa bawat relay region na alam nito, at minamarkahan ng tailscale status ang bawat peer bilang direct na may address o relay na may region code. Ang peer na nananatili sa relay ay problema sa NAT, hindi problema sa Headscale. Ang peer na direct pero mabagal pa rin ay ibang usapin, at karaniwang MTU ang sagot dito, hindi ang tunnel mismo.

Bakit lumalabas na offline ang isang node?

Ibinabagsak ng proxy ang upgrade. Ito ang karaniwang sanhi. Makikita ito kapag maayos ang lahat ng iba pa: nagbabalik ang /health ng 200, ipinapakita ng headscale nodes list ang node, ngunit hindi kailanman nagiging online ang node. Ang control connection ay isang POST na naglalaman ng Upgrade: tailscale-control-protocol. Kapag hindi ito ipinapasa ng proxy, nawawala ang tanging channel na nag-uulat ng state ng node. Ihambing ang configuration ng nginx sa map block sa itaas, o lumipat sa Caddy upang maalis ang proxy bilang sanhi.

Nagbago ang server_url matapos mag-register ang mga node. Patuloy na ginagamit ng mga node ang value na ibinigay sa kanila noong registration. Kung in-edit mo ito, patakbuhin ang sudo tailscale up --login-server https://headscale.example.com --force-reauth sa bawat node.

Hindi tumatakbo ang client. Sa node, patakbuhin ang sudo systemctl is-active tailscaled at sudo journalctl -u tailscaled -n 50 --no-pager. Nagtatala roon ng mga retry ang client na hindi makapag-resolve o makakonekta sa iyong domain.

Nag-expire ang key. Tinalakay ito sa susunod na seksyon.

Para ma-monitor ang server side habang nagsusuri ka, patakbuhin ang sudo journalctl -u headscale -f sa VPS at i-restart ang tailscaled sa client. Agad na gumagawa ng mga log line ang node kapag nakakarating ito sa headscale. Kapag walang lumalabas, hindi nakakarating ang request. Suriin muna ang DNS, firewall, at proxy bago ang headscale.

Pag-expire ng key, at ang node na humihinto pagkalipas ng ilang linggo

May dalawang magkahiwalay na expiry, at nakapagdudulot ng aksaya sa oras kapag napagpalit ang mga ito.

Mabilis mag-expire ang preauth key ayon sa disenyo. Ang default ay isang oras at isang paggamit. Kung tinatanggihan ng tailscale up ang key, bumuo ng panibagong key sa server sa halip na mag-edit ng anuman sa client.

Ang node key ang pangmatagalang bahagi. Itinatakda ng seksyong node ng config.yaml ang expiry: 0, at nangangahulugan ang 0 na walang default na expiry: mananatiling valid ang isang naka-register na node hanggang i-expire mo ito. Hindi kailanman nag-e-expire ang mga naka-tag na node. Itakda ang expiry: 180d kung gusto mong awtomatikong mag-expire ang mga registration, at unawain ang epekto nito: kakailanganin ng bawat node na walang tag ang sudo tailscale up --login-server https://headscale.example.com --force-reauth ayon sa itinakdang iskedyul, at awtomatikong mawawala sa network ang isang headless server na walang muling nag-a-authenticate.

Manu-mano itong gawin kapag may nawalan ng laptop. Ibinibigay ng sudo headscale nodes list ang ID, pagkatapos ay ila-log out ng sudo headscale nodes expire -i 3 ang node na iyon, at tuluyang aalisin ito ng sudo headscale nodes delete -i 3 sa network.

Mga backup at upgrade

Ang /var/lib/headscale at /etc/headscale ang bumubuo sa buong server. Ihinto ang service bago kopyahin ang mga ito, dahil maaaring may kasalukuyang write ang SQLite at maaaring maging inconsistent ang database na kinopya habang may load.

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

Ilipat ang dalawang file palabas ng server. Naglalaman ang mga ito ng private key at lahat ng registration, kaya dapat silang pangalagaan gaya mismo ng server. Tinalakay sa mga restic backup mula sa VPS kung paano ito gawin nang naka-schedule at encrypted.

Ulitin ng mga upgrade ang proseso ng installation: i-download ang bagong .deb at sudo apt install ./headscale.deb, pagkatapos ay i-restart at muling patakbuhin ang mga check na is-active at /health. Simula sa 0.29, mahigpit ang upgrade path. Naka-block ang paglaktaw ng minor version, pati ang pag-downgrade sa mas lumang minor version. Mag-upgrade nang tig-iisang minor version, gumawa ng backup bago ang bawat hakbang, at basahin muna ang release notes ng bersyong iyon, dahil binago ng parehong release ang behavior ng ACL policy at inilipat ang ilang configuration key.

FAQ

Tumatakbo na ba ang headscale agad pagkatapos kong i-install ang .deb?

Oo. Ine-enable at sinisimulan ng package ang service agad pagkatapos nitong ma-install, gamit ang shipped na /etc/headscale/config.yaml, na nakikinig lamang sa loopback at nagse-set ng server_url sa http://127.0.0.1:8080. Hindi magagamit ng mga client ang address na iyon, kaya i-edit ang server_url, listen_addr, at base_domain, pagkatapos ay patakbuhin ang sudo systemctl restart headscale at kumpirmahin gamit ang sudo systemctl is-active headscale. Dapat itong maging restart: binabasa ng headscale ang file kapag nagsisimula lamang ito, at walang epekto ang enable --now sa service na tumatakbo na. Kung mabigo ito pagkatapos ng restart, tinutukoy ng sudo journalctl -u headscale -n 50 --no-pager ang problema. Sa yugtong ito, halos palaging YAML error ito dahil bina-parse ng headscale ang buong file bago ito makinig sa isang port.

Kailangan ko pa bang i-install ang karaniwang Tailscale client sa aking mga machine?

Oo. Ang control server lamang ang pinapalitan ng Headscale. Ang bawat node ay nagpapatakbo ng official client mula sa Tailscale, at itinuturo mo ito sa iyong server gamit ang sudo tailscale up --login-server https://headscale.example.com. Bahagi ang flag na iyon ng standard client, kaya walang kailangang i-patch o i-rebuild.

Dumadaan ba ang traffic ko sa headscale server?

Karaniwan, hindi. Kino-coordinate ng Headscale ang network at namamahagi ito ng mga key at address, habang direktang dumadaan ang data sa WireGuard sa pagitan ng iyong mga node. Lumulihis lamang ang traffic kapag hindi direktang maabot ng dalawang node ang isa't isa at gumagamit sila ng DERP relay. Sa shipped na configuration, ang mga relay na ito ay mga public relay ng Tailscale. Patakbuhin ang tailscale status sa isang node upang makita kung ang isang peer ay direct o gumagamit ng relay.

Bakit nananatiling offline ang node ko pagkatapos nitong mag-register?

Ang node na lumalabas sa headscale nodes list ngunit hindi kailanman nagiging online ay karaniwang nawalan ng control connection sa reverse proxy. HTTP upgrade ang connection na ito na ipinapadala bilang POST na may header na Upgrade: tailscale-control-protocol, at ibinabagsak ito ng nginx maliban kung idagdag mo ang map $http_upgrade $connection_upgrade block at ang katugmang mga linya ng proxy_set_header. Ipinapasa ito ng Caddy nang walang karagdagang configuration, kaya mabilis itong gamitin para masuri kung ang proxy ang may problema.

Kailangan ko ba ng domain name at TLS para sa headscale?

Sa praktika, oo. Kumokonekta ang mga client sa string na inilagay mo sa server_url. Ini-issue ang mga certificate para sa mga pangalan, hindi para sa mga bare IP address, at nakasaad sa configuration file na kailangan ng DERP ang TLS. Ang domain at Caddy ay karaniwang limang minuto lang i-set up at nagbibigay ng HTTPS endpoint na awtomatikong nagre-renew. Kapag pinatakbo ang control server gamit ang plain HTTP, dumadaan sa internet nang walang encryption ang bawat pag-uusap ng client dito.