Jinsi ya kuweka Headscale kwenye VPS yako

Headscale ni nini

Headscale ni utekelezaji wa seva ya kudhibiti ya Tailscale inayojiendesha (self-hosted), kwa hivyo mashine inayoratibu mtandao wako wa kibinafsi ni VPS unayomiliki. Huu ni mradi wa jamii na hauendeshwi na Tailscale Inc. Kila mashine bado inaendesha mteja rasmi wa tailscale, ikielekezwa kwenye seva yako kwa kutumia flag moja, --login-server.

Seva ya kudhibiti ndiyo sehemu inayojua nani anayehusika na mtandao. Inapa kila node anwani kutoka 100.64.0.0/10, inasambaza funguo za umma (public keys), na kuwaambia node mahali pa kupatana. Tunnels hubaki kuwa WireGuard, zikijengwa kutoka node hadi node. Trafiki kati ya mashine zako mbili haipiti kwenye kisanduku cha headscale, isipokuwa kama njia ya moja kwa moja haiwezi kujengwa na node zikarejea kwenye relay.

Headscale huhudumia tailnet moja (mtandao mmoja wa Tailscale) kwa kila instance, jambo ambalo mradi huu unaelezea kuwa linafaa kwa matumizi ya kibinafsi au shirika dogo. Ukiwa na mashine tatu au nne, VPN ya kawaida ya WireGuard kwenye VPS unayomiliki ni programu ndogo zaidi ya kuendesha na ni rahisi zaidi kutoharibika. Headscale inafaa zaidi wakati hutaki tena kuandika block ya [Peer] kwa mkono kwa kila laptop mpya. Ikiwa unataka control plane inayojiendesha lakini ungependelea kuwa na mteja wako mwenyewe na kiolesura cha wavuti cha kudhibiti peers badala ya mbadala wa moja kwa moja wa Tailscale, NetBird kwenye VPS moja ni mbadala unaostahili kuzingatiwa. Kwa ulinganisho mpana wa mifano hii miwili, angalia jinsi WireGuard na Tailscale zinavyotofautiana.

Mambo unayohitaji kabla ya kusakinisha

• VPS inayoendesha Ubuntu 24.04 yenye anwani ya IPv4 ya umma na ufikiaji wa sudo. Ikiwa seva ni mpya, kamilisha kwanza dakika kumi za kwanza kwenye VPS mpya.
• Rekodi ya DNS A inayoelekeza kwenye anwani hiyo. Mwongozo huu unatumia headscale.example.com.
• Domain ya pili au subdomain kwa ajili ya MagicDNS. Mwongozo huu unatumia tailnet.example.net. Hii haipaswi kuwa domain sawa na ile iliyo kwenye server_url.
• Mashine moja ya mteja ya kujiunga, inayoendesha Linux, macOS, Windows, Android au iOS.

Sakinisha headscale kutoka kwenye .deb rasmi

Mradi huu huchapisha vifurushi vya .deb kwenye ukurasa wake wa GitHub releases. Kufikia Julai 2026, toleo la sasa ni 0.29.3. Kwanza hakiki usanifu (architecture) wa mfumo wako, kwa sababu jina la faili linategemea usanifu huo.

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

Amri hiyo huchapisha amd64 kwenye VPS ya kawaida ya x86 na arm64 kwenye mpango wa aina ya Ampere au Graviton. Weka jibu hilo kwenye kigezo (variable) hapo chini.

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

Alama ya ./ mbele ya jina la faili ni ya lazima. Bila hiyo, apt hutafuta kifurushi kinachoitwa headscale.deb kwenye hazina (repositories) zako na kushindwa.

Kifurushi hiki hutengeneza mtumiaji wa mfumo wa headscale, huandika /etc/headscale/config.yaml ya msingi, na kusakinisha unit ya systemd. Haianzishi huduma hiyo, na huo ndio utaratibu sahihi. Usanidi uliokuja na programu huelekeza server_url kwenye http://127.0.0.1:8080, ambayo si anwani inayoweza kufikiwa na mteja wako yeyote, kwa hivyo huduma ikianzishwa sasa itakuwa na makosa hata kama itafanya kazi. Kuendesha sudo systemctl is-active headscale katika hatua hii huchapisha inactive. Hilo ni jambo linalotarajiwa, si hitilafu.

Sanidi server_url kabla ya kuanzisha huduma

Hariri /etc/headscale/config.yaml kwa kutumia sudo nano /etc/headscale/config.yaml, au fanya mabadiliko hayo matatu kwa kutumia sed. Hifadhi nakala ya faili asilia, kwa sababu faili hilo ni refu na lina maelezo mengi, na ndilo rejeleo bora zaidi ulilo nalo kwa ajili ya mipangilio mingine yote.

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 ndilo anwani ambalo headscale huandika katika kila usajili wa mteja. Wateja hupiga anwani hiyo kamili kila wakati baada ya hapo, kwa hivyo lazima liwe jina la umma lenye https:// mbele yake, na kamwe lisiwe 127.0.0.1.

listen_addr ndipo mchakato huu husikiliza (bind). Iache kwenye loopback. Reverse proxy iliyo kwenye seva hiyo hiyo hufanya TLS (transport layer security) termination na kupeleka maombi huko, kwa hivyo hakuna kitu chochote nje ya seva kinachohitaji kufikia port 8080.

base_domain ndicho kiambishi cha MagicDNS, kikoa ambacho nodi zako hupata majina chini yake. Lazima kiwe kikoa kamili (fully qualified domain name) bila nukta mwishoni, na lazima kiwe kikoa tofauti na kile kilicho katika server_url, kwa sababu nafasi hizo mbili za majina zitagongana.

Acha sehemu ya database kama ilivyo. Chaguo-msingi ni SQLite katika /var/lib/headscale/db.sqlite, kwenye saraka ambayo kifurushi kiliunda na kumiliki, na SQLite inatosha kwa tailnet ya ukubwa huu.

Anzisha headscale na uthibitishe kuwa inafanya kazi

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 huchapisha active na curl huchapisha 200. enable --now hufanya kazi zote mbili: huianzisha huduma na kuiweka alama ili ianze baada ya reboot.

Ikiwa is-active itachapisha failed, soma journal kwa kutumia sudo journalctl -u headscale -n 50 --no-pager. Kushindwa kuanza katika hatua hii mara nyingi husababishwa na faili ya configuration, kwa sababu headscale huchanganua faili nzima kabla ya kufungua socket; hivyo, indent mbaya au ufunguo usiojulikana husimamisha mchakato kabla ya chochote kuanza kusikiliza. Rekebisha faili, kisha tumia sudo systemctl restart headscale. Kila mabadiliko ya configuration baadaye yanahitaji restart hiyo hiyo. Wateja huunganisha tena wenyewe baada ya hapo. Ikiwa systemd units ni ngeni kwako, kuendesha huduma zako mwenyewe na timers kwa kutumia systemd inashughulikia amri zilizotumika hapa.

Kagua faili za hali (state files) ukiwa bado kwenye shell:

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

Mistari yote miwili huanza na headscale, mtumiaji asiye na upendeleo (unprivileged user) aliyeundwa na kifurushi hicho. noise_private.key ni utambulisho wa seva kwa wateja wake. Ihifadhi. Ukifuta faili hiyo, headscale itatengeneza nyingine mpya na kila node italazimika kujisajili upya.

Weka TLS mbele ya headscale

Wateja lazima wafikie server_url kupitia HTTPS. Caddy ndiyo njia fupi zaidi, kwa sababu huomba na kusasisha cheti chenyewe.

sudo apt install -y caddy

Badilisha /etc/caddy/Caddyfile na kizuizi kutoka kwenye nyaraka za 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

validate huchapisha adapted config to JSON wakati faili inapochanganuliwa. Onyo kwamba faili haijapangiliwa ni la kawaida tu. Kutoka kwenye laptop yako, curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health inapaswa pia kuchapisha 200. Uthibitisho huo mmoja unaonyesha kuwa DNS, firewall, cheti na proxy zote zinafanya kazi pamoja.

Hii hapa ni maelezo ya proxy ambayo huwapa watu wakati mgumu. Muunganisho wa udhibiti wa Tailscale ni HTTP upgrade, huanzishwa kwa POST badala ya GET, na thamani ya header ya Upgrade ni tailscale-control-protocol. Caddy hupitisha hiyo bila usanidi wa ziada. nginx haifanyi hivyo, kwa hivyo front end ya nginx inahitaji ramani ya upgrade:

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;
    }
}

Ukiacha mistari hiyo, maombi ya kawaida bado yatafanikiwa, ndiyo maana /health inarudisha 200 na kila kitu kinaonekana sawa, wakati muunganisho wa udhibiti wa muda mrefu haujawahi kutokea na nodi zako zinasajiliwa kisha zinabaki nje ya mtandao. Ikiwa utatumia njia ya nginx, Certbot kwenye Ubuntu 24.04 na nginx inashughulikia sehemu ya cheti.

Ni port zipi za kufungua katika UFW

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

Port 443 hubeba kila mawasiliano ya mteja. Port 80 ipo kwa ajili ya ACME (automatic certificate management environment) HTTP challenge na kuelekeza trafiki kwenye HTTPS, na Caddy inahitaji port hii ili kupata cheti.

Port 8080 inabaki imefungwa. listen_addr ni 127.0.0.1:8080, kwa hivyo proxy hufikia headscale kupitia loopback interface na hakuna sheria ya firewall inayohusika. Kufungua 8080 kwenye Internet huwapa wateja njia ya mawasiliano ya wazi (cleartext) na hakuna faida yoyote inayopatikana. Kumbuka kuwa watoa huduma wengi huendesha firewall ya pili kwenye control panel yao, tofauti na UFW, kwa hivyo port inaweza kuwa wazi kwenye seva lakini bado imefungwa kwenye edge. Misingi ya UFW firewall kwenye VPS inaelezea sintaksia ya sheria kwa kina zaidi.

Unda mtumiaji na ufunguo wa preauth

sudo headscale users create alice
sudo headscale users list

Amri ya headscale ni mteja. Inawasiliana na daemon inayofanya kazi kupitia unix socket iliyopo /var/run/headscale/headscale.sock, ambayo ina mode 0770 na inamilikiwa na kundi la headscale. Mambo mawili yanatokana na hili. Amri hii inafeli wakati huduma imesimamishwa, ambayo ndiyo sababu nyingine inayofanya mpangilio katika mwongozo huu kuwa muhimu, na inahitaji sudo isipokuwa uongeze akaunti yako kwenye kundi la headscale.

users list huchapisha ID kando ya kila jina. Unahitaji namba hiyo, kwa sababu amri ya ufunguo inahitaji ID ya mtumiaji ya namba na si jina.

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

Ufunguo huchapishwa mara moja. Nakili sasa. Ufunguo wa preauth hutumika mara moja na ni halali kwa saa moja isipokuwa useme vinginevyo, kwa hivyo --expiration 24h inafaa kuwekwa wakati bado unafanya majaribio. Ongeza --reusable kwa ufunguo unaosajili mashine kadhaa, na uuchukulie kama nenosiri, kwa sababu mtu yeyote aliye nao anaweza kujiunga na mtandao wako.

Unganisha mteja wako wa kwanza kwa kutumia --login-server

Kwenye mashine unayotaka kuunganisha:

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 huchapisha anwani iliyotolewa na headscale, kitu kama 100.64.0.1. Ukiwa umerejea kwenye seva, sudo headscale nodes list huonyesha nodi hiyo ikiwa na ID yake, mtumiaji wake, na hali yake ya mtandaoni.

Thamani ya --login-server lazima ilingane na server_url kikamilifu, ikijumuisha scheme na bila kuwa na slash ya ziada mwishoni. Hulinganishwa kama kamba za maandishi (strings), na kutolingana kunamaanisha mteja anajisajili kwenye anwani moja kisha anaambiwa awasiliane na nyingine.

Mashine iliyokuwa imeingia kwenye huduma ya Tailscale inayohifadhiwa na wao (hosted service) huendelea kubaki na login hiyo. Endesha sudo tailscale logout kwenye mashine hiyo kwanza, kisha endesha tailscale up ukiwa na --login-server.

Ukiacha --auth-key, mteja huchapisha URL badala yake. Ifungue na ukurasa utaonyesha kitambulisho cha jaribio hilo la usajili, ambacho unakikubali kwenye seva:

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

Fomu hiyo ni rahisi zaidi kwa kompyuta yako binafsi. Funguo za preauth ni bora zaidi kwa chochote kinachotumia script, kwa sababu hakuna binadamu anayehitajika kufuatilia. Mara tu VPS yenyewe inapokuwa nodi, inaweza pia kubeba trafiki ya mtandao ya mashine zako nyingine, jambo ambalo ni usanidi wa exit node, huku tofauti pekee ikiwa ni kwamba unakubali njia iliyotangazwa (advertised route) kwenye seva kwa kutumia amri ya headscale badala ya kutumia dashibodi ya utawala iliyohifadhiwa na mtoa huduma.

DERP, na kinachopeleka trafiki njia ya moja kwa moja inapofeli

DERP (designated encrypted relay for packets) ndiyo njia mbadala. Wakati nodi mbili haziwezi kufungua muunganisho wa moja kwa moja wa WireGuard, kwa kawaida kwa sababu zote ziko nyuma ya NAT (network address translation) kali, hutuma pakiti kupitia relay badala yake. Relay haina funguo zozote, kwa hivyo haiwezi kusoma trafiki yako. Inaona ni nodi zipi zinazozungumza na kiasi gani cha data kinachohamia.

Kuwa wazi kuhusu kile usanidi chaguo-msingi hufanya. Headscale inakuja ikiwa imeelekezwa kwenye https://controlplane.tailscale.com/derpmap/default na auto_update_enabled: true na update_frequency: 3h, kwa hivyo control plane ni yako wakati relay ni za Tailscale. Kwa watu wengi, huo ni ubadilishaji wa haki. Ikiwa sivyo, endesha yako mwenyewe.

Ili kuendesha relay yako mwenyewe, weka enabled: true chini ya derp.server katika config.yaml, anzisha upya headscale, na ufungue port ya STUN (session traversal utilities for NAT) kwa sudo ufw allow 3478/udp. Faili ya usanidi inaeleza hitaji hilo waziwazi: server_url lazima itumie https, kwa sababu DERP inahitaji TLS. Kuondoa orodha ya derp.urls hufuta relay za Tailscale kutoka kwenye ramani, na ukifanya hivyo bila relay iliyopachikwa inayofanya kazi, jozi yoyote ya nodi ambazo haziwezi kuunganishwa moja kwa moja haitaweza kuunganishwa kabisa.

Kutoka kwa client, tailscale netcheck huonyesha muda wa kusubiri hadi kila eneo la relay linalojulikana, na tailscale status huainisha kila peer kuwa ama direct yenye anwani au relay yenye msimbo wa eneo. Peer iliyokwama kwenye relay ina tatizo la NAT, si tatizo la headscale. Peer iliyo katika hali ya direct lakini bado ni polepole ni suala tofauti, na jibu la kawaida hapo ni MTU, si tunnel yenyewe.

Kwa nini nodi inaonekana kama iko nje ya mtandao (offline)?

Proxy inakata muunganisho wa upgrade. Hii ndiyo sababu ya kawaida, na dalili yake ni kwamba kila kitu kingine kinaonekana kuwa sawa: /health inarejesha 200, headscale nodes list inaonyesha nodi hiyo, na nodi haiji mtandaoni kamwe. Muunganisho wa udhibiti ni POST inayobeba Upgrade: tailscale-control-protocol, na proxy isiyoipitisha inakata njia pekee inayoripoti hali ya nodi. Linganisha usanidi wako wa nginx na block ya map hapo juu, au tumia Caddy ili kuondoa uwezekano wa tatizo la proxy.

server_url ilibadilika baada ya nodi kujisajili. Nodi zinaendelea kupiga simu kwa kutumia thamani waliyopewa wakati wa usajili. Ikiwa umeibadilisha, endesha sudo tailscale up --login-server https://headscale.example.com --force-reauth kwenye kila nodi.

Mteja (client) haifanyi kazi. Kwenye nodi, angalia sudo systemctl is-active tailscaled na sudo journalctl -u tailscaled -n 50 --no-pager. Mteja asiyeweza kutatua (resolve) au kufikia domain yako huandika majaribio yake ya kurudia (retries) hapo.

Ufunguo (key) umekwisha muda wake. Hili limefafanuliwa katika sehemu inayofuata.

Ili kufuatilia upande wa seva wakati unafanya majaribio, endesha sudo journalctl -u headscale -f kwenye VPS na uanzishe upya tailscaled kwenye mteja. Nodi inayofikia headscale hutoa mistari ya logi mara moja. Ukimya unamaanisha ombi halifiki, kwa hivyo angalia DNS, firewall na proxy kabla ya kuangalia headscale.

Kumalizika kwa muda wa ufunguo, na node inayoacha kufanya kazi wiki kadhaa baadaye

Kuna aina mbili tofauti za kumalizika kwa muda, na kuzichanganya hupoteza muda.

Preauth keys huisha muda wake haraka kwa makusudi. Muda chaguo-msingi ni saa moja na matumizi moja. Ikiwa tailscale up itakataa ufunguo huo, tengeneza mwingine mpya kwenye seva badala ya kuhariri chochote kwenye client.

Node keys ndizo zenye muda mrefu wa kuishi. Sehemu ya node ya config.yaml huweka expiry: 0, na 0 inamaanisha hakuna muda chaguo-msingi wa kumalizika: node iliyosajiliwa hubaki kuwa halali hadi utakapomaliza muda wake. Node zilizowekewa tag hazimalizi muda wake kamwe. Weka expiry: 180d ikiwa unataka usajili uwe na muda wa kuisha, na uelewe unachoomba: kila node isiyo na tag itahitaji sudo tailscale up --login-server https://headscale.example.com --force-reauth kulingana na ratiba hiyo, na seva isiyo na mtumiaji (headless) ambayo hakuna anayeifanyia re-authentication itatoka kwenye mtandao yenyewe.

Fanya hivi kwa mkono wakati mtu anapopoteza laptop. sudo headscale nodes list inakupa ID, kisha sudo headscale nodes expire -i 3 inaitoa node hiyo kwenye mfumo (logout), na sudo headscale nodes delete -i 3 inaiondoa kabisa kwenye mtandao.

Hifadhi nakala na maboresho

/var/lib/headscale na /etc/headscale kwa pamoja ndiyo seva nzima. Simamisha huduma kabla ya kuzinakili, kwa sababu SQLite inaweza kuwa na maandishi yanayoendelea na hifadhidata iliyokopiwa wakati wa mzigo inaweza kuwa na hitilafu.

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

Hamisha faili zote mbili nje ya seva. Zina funguo za siri (private keys) na kila usajili, kwa hivyo zinahitaji uangalizi uleule kama seva yenyewe. restic backups from a VPS inaelezea jinsi ya kufanya hivi kwa ratiba na kwa njia iliyosimbwa (encrypted).

Maboresho hurudia mchakato wa usakinishaji: pakua .deb, sudo apt install ./headscale.deb mpya, kisha uanzishe upya na uendeshe tena ukaguzi wa is-active na /health. Tangu toleo la 0.29, njia ya kuboresha ni madhubuti. Kuruka toleo dogo (minor version) kumezuiwa, na vilevile kushusha toleo (downgrade) kwenda toleo dogo la zamani. Hamia toleo moja dogo kwa wakati mmoja, chukua nakala kabla ya kila hatua, na usome maelezo ya toleo husika kwanza, kwa sababu toleo lilelile lilibadilisha tabia ya sera ya ACL na kuhamisha funguo kadhaa za usanidi.

FAQ

Kwa nini headscale inashindwa kuanza mara tu baada ya kusakinisha .deb?

Kifurushi hiki husakinisha unit lakini huacha huduma ikiwa imesimama, na /etc/headscale/config.yaml ya awali ni kiolezo badala ya usanidi unaofanya kazi. Hariri server_url, listen_addr na base_domain kwanza, kisha endesha sudo systemctl enable --now headscale na uthibitishe kwa sudo systemctl is-active headscale. Ikiwa bado inashindwa, sudo journalctl -u headscale -n 50 --no-pager inataja tatizo lenyewe, na katika hatua hii karibu kila mara ni kosa la YAML, kwa sababu headscale husoma faili nzima kabla ya kufungua port.

Je, bado nasakinisha mteja wa kawaida wa Tailscale kwenye mashine zangu?

Ndiyo. Headscale inachukua nafasi ya seva ya udhibiti pekee. Kila node huendesha mteja rasmi kutoka Tailscale, na unaielekeza kwenye seva yako kwa kutumia sudo tailscale up --login-server https://headscale.example.com. Flag hiyo ipo kwenye mteja wa kawaida, kwa hivyo hakuna haja ya kurekebisha au kujenga upya chochote.

Je, trafiki yangu hupitia kwenye seva ya headscale?

Kwa kawaida hapana. Headscale huratibu mtandao na kutoa funguo na anwani, wakati njia ya data ni WireGuard moja kwa moja kati ya node zako. Trafiki hupitia njia nyingine tu wakati node mbili haziwezi kufikiana moja kwa moja na kutumia DERP relay, na kwa usanidi uliopo, relay hizo ni zile za umma za Tailscale. Endesha tailscale status kwenye node ili kuona kama peer fulani ni direct au yuko kwenye relay.

Kwa nini node yangu inabaki nje ya mtandao baada ya kujisajili?

Node inayoonekana kwenye headscale nodes list lakini haiji mtandaoni kwa kawaida imepoteza muunganisho wake wa udhibiti kwenye reverse proxy. Muunganisho huo ni HTTP upgrade inayotumwa kama POST yenye header ya Upgrade: tailscale-control-protocol, na nginx huikataa isipokuwa uongeze block ya map $http_upgrade $connection_upgrade na mistari inayolingana ya proxy_set_header. Caddy huipitisha bila usanidi wa ziada, jambo linaloifanya kuwa njia ya haraka ya kupima kama proxy ndiyo chanzo cha tatizo.

Je, ninahitaji jina la domain na TLS kwa ajili ya headscale?

Kiutendaji, ndiyo. Wateja huunganisha kwenye mfuatano wowote wa herufi unaoweka kwenye server_url, vyeti hutolewa kwa majina na si kwa anwani za IP pekee, na faili ya usanidi inasema kuwa DERP inahitaji TLS. Domain pamoja na Caddy huchukua kama dakika tano na kukupa HTTPS endpoint inayojihuisha yenyewe. Kuendesha seva ya udhibiti kupitia HTTP ya kawaida inamaanisha kila mazungumzo ya mteja nayo yanavuka mtandao bila ulinzi.