Cara Pasang Headscale Sebagai Pelayan Tailscale Sendiri

Apakah itu Headscale

Headscale ialah implementasi pelayan kawalan Tailscale yang dihoskan sendiri, jadi mesin yang menyelaraskan rangkaian peribadi anda ialah VPS milik anda sendiri. Ia merupakan projek komuniti dan tidak dikendalikan oleh Tailscale Inc. Setiap mesin masih menjalankan klien tailscale rasmi, yang dihalakan ke pelayan anda dengan satu flag, --login-server.

Pelayan kawalan ialah bahagian yang mengetahui siapa yang tergolong dalam rangkaian tersebut. Ia memberikan setiap nod alamat daripada 100.64.0.0/10, mengedarkan kunci awam, dan memberitahu nod di mana untuk mencari antara satu sama lain. Terowong kekal menggunakan WireGuard, yang dibina dari nod ke nod. Trafik antara dua mesin anda tidak melalui kotak headscale, melainkan laluan terus tidak dapat dibina dan nod terpaksa menggunakan relay. Menjalankan peranan penyelarasan itu sendiri mengubah siapa yang memegangnya dan bukannya apa yang mampu dilakukannya, jadi adalah berbaloi untuk memahami apa yang boleh dan tidak boleh dicapai oleh pelayan kawalan dalam model ini sebelum anda menganggap langkah ini sebagai kemenangan keselamatan semata-mata.

Headscale menyediakan satu tailnet (satu rangkaian Tailscale) bagi setiap instance. Projek ini menerangkannya sebagai sesuai untuk kegunaan peribadi atau organisasi kecil. Dengan tiga atau empat mesin, VPN WireGuard biasa pada VPS milik anda memerlukan kurang perisian untuk dijalankan dan kurang perkara yang boleh rosak. Headscale mula berbaloi apabila anda tidak lagi mahu menulis blok [Peer] secara manual untuk setiap komputer riba baharu. Kos sering menjadi sebab orang mula mencari pilihan seperti ini. Oleh itu, baca perkara yang sebenarnya diliputi oleh pelan percuma berhos sebelum anda mengurus pelayan, kerana beberapa mesin peribadi biasanya masih boleh menggunakan pelan tersebut. Jika anda sudah melebihi had itu, buat pengiraan berdasarkan kos pelan berbayar bagi setiap pengguna dan setiap sumber bertanda, kerana peranti pengguna tidak terhad, manakala sumber bertanda mempunyai kuota dan caj berasingan. Jika anda mahukan control plane yang dihos sendiri tetapi lebih suka menggunakan klien anda sendiri serta antara muka web untuk mengurus peer, dan bukannya pengganti terus kepada Tailscale, NetBird pada satu VPS ialah alternatif yang wajar dipertimbangkan. Kedua-duanya membawa trafik anda melalui WireGuard. Oleh itu, pilihan bergantung pada cara anda menulis peraturan akses dan cara relay berfungsi. Anda wajar membandingkan NetBird dengan Tailscale dari segi tersebut sebelum memasang mana-mana daripadanya. Untuk perbandingan lebih luas antara kedua-dua model ini, lihat perbezaan antara WireGuard dengan Tailscale.

Keperluan sebelum pemasangan

• Sebuah VPS yang menjalankan Ubuntu 24.04 dengan alamat IPv4 awam dan akses sudo. Jika pelayan tersebut baharu, selesaikan sepuluh minit pertama pada VPS baharu terlebih dahulu.
• Satu rekod DNS A yang menghala ke alamat tersebut. Panduan ini menggunakan headscale.example.com.
• Domain kedua atau subdomain untuk MagicDNS. Panduan ini menggunakan tailnet.example.net. Ia tidak boleh menjadi domain yang sama dengan yang digunakan dalam server_url.
• Satu mesin klien untuk disambungkan, yang menjalankan Linux, macOS, Windows, Android atau iOS. Headscale 0.29.6 memerlukan klien Tailscale versi 1.80.0 atau lebih baharu.

Memasang headscale daripada fail .deb rasmi

Projek ini menerbitkan pakej .deb pada halaman GitHub releases mereka. Setakat 27 Oktober 2026, keluaran stabil terkini ialah 0.29.6, yang dikeluarkan pada 24 Oktober 2026. Semak seni bina sistem anda terlebih dahulu, kerana nama fail bergantung padanya.

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

Perintah tersebut memaparkan amd64 pada VPS x86 biasa dan arm64 pada pelan jenis Ampere atau Graviton. Masukkan jawapan tersebut ke dalam pemboleh ubah di bawah.

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

Tanda ./ di hadapan nama fail adalah wajib. Tanpanya, apt akan mencari pakej bernama headscale.deb dalam repositori anda dan gagal.

Pakej ini mencipta pengguna sistem headscale, menulis /etc/headscale/config.yaml lalai, memasang unit systemd, dan kemudian memulakan servis tersebut. Oleh itu, headscale sudah pun berjalan apabila apt selesai, dan sudo systemctl is-active headscale memaparkan active. Walau bagaimanapun, pada pemasangan baharu, pakej tersebut tidak mendayakan unit berkenaan, jadi servis tidak akan bermula semula selepas but semula sehingga anda mendayakannya, seperti langkah mulakan semula di bawah. Ia juga berjalan menggunakan konfigurasi asal, yang menghalakan server_url ke http://127.0.0.1:8080, iaitu alamat yang tidak boleh dicapai oleh mana-mana klien anda. Tiada apa-apa yang terdedah lagi, kerana listen_addr asal juga berada pada loopback, tetapi jangan sambungkan mana-mana klien sehingga anda menetapkan server_url dan memulakan semula servis tersebut, seperti yang dilakukan dalam dua langkah seterusnya.

Konfigurasikan server_url sebelum mana-mana klien menyertai

Sunting /etc/headscale/config.yaml dengan sudo nano /etc/headscale/config.yaml, atau gunakan tiga perubahan yang sama dengan sed. Simpan salinan asal, kerana fail tersebut panjang dan mempunyai banyak ulasan, menjadikannya rujukan terbaik yang anda miliki untuk tetapan selebihnya.

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 ialah alamat awam yang digunakan oleh headscale semasa membina URL pendaftaran. Klien menggunakan alamat kawalan yang dikonfigurasikan dengan --login-server, jadi gunakan nama awam yang sama dengan https:// di kedua-dua tempat, jangan gunakan 127.0.0.1. Dokumentasi Headscale menyatakan bahawa HTTP biasa, atau HTTPS pada port selain 443, adalah mungkin, tetapi ia sangat mengesyorkan HTTPS pada port 443 untuk pengeluaran, dan baki panduan ini menganggap tetapan tersebut.

listen_addr ialah tempat proses tersebut diikat (bind). Biarkan ia pada loopback. Reverse proxy pada mesin yang sama menamatkan TLS (transport layer security) dan memajukannya ke sana, jadi tiada apa-apa di luar pelayan perlu mencapai port 8080.

base_domain ialah akhiran MagicDNS, domain yang digunakan oleh nod anda untuk mendapatkan nama. Ia mestilah nama domain yang layak sepenuhnya (fully qualified domain name) tanpa titik di hujung, dan ia mestilah domain yang berbeza daripada domain dalam server_url, kerana jika tidak, kedua-dua ruang nama tersebut akan bertembung.

Biarkan bahagian pangkalan data seperti sedia ada. Lalai bagi pangkalan data ialah SQLite pada /var/lib/headscale/db.sqlite, dalam direktori yang dicipta dan dimiliki oleh pakej tersebut, dan SQLite sudah memadai untuk tailnet sebesar ini.

Mulakan semula headscale dan pastikan ia sedang berjalan

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 mencetak active, is-enabled mencetak enabled, dan curl mencetak 200. Langkah memulakan semula adalah langkah yang memuatkan suntingan anda. Headscale membaca konfigurasinya sekali sahaja, iaitu semasa ia bermula, jadi proses yang dimulakan oleh pakej tersebut akan terus menggunakan server_url yang dibekalkan sehingga anda memulakan semulanya. sudo systemctl enable --now headscale tidak melakukan tugas ini: servis tersebut sudah pun berjalan, jadi --now start tidak mengubah apa-apa dan nilai lama kekal aktif. Memulakan servis semasa but adalah tugas enable, dan ia tidak dilakukan secara automatik untuk anda: pada pemasangan baharu, pakej tersebut memulakan servis tanpa mendayakannya, jadi jalankan sudo systemctl enable headscale sekali, seperti di atas.

Jika is-active mencetak apa-apa selain daripada active, atau curl tidak mencetak 200, baca jurnal dengan sudo journalctl -u headscale -n 50 --no-pager. Kegagalan pada peringkat ini hampir selalu berpunca daripada fail konfigurasi, kerana headscale menghuraikan keseluruhan fail sebelum ia membuka soket, jadi indentasi yang salah atau tetapan wajib yang tidak sah akan menghentikan proses sebelum sebarang port mendengar. Betulkan fail tersebut, kemudian sudo systemctl restart headscale. Setiap perubahan konfigurasi seterusnya memerlukan langkah memulakan semula yang sama. Klien akan menyambung semula secara automatik selepas itu. Jika unit systemd adalah perkara baharu bagi anda, menjalankan servis dan pemasa anda sendiri dengan systemd merangkumi arahan yang digunakan di sini.

Semak fail keadaan semasa anda berada dalam shell:

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

Kedua-dua baris bermula dengan headscale, pengguna tanpa keistimewaan yang dicipta oleh pakej tersebut. noise_private.key ialah identiti pelayan kepada kliennya. Simpan fail ini. Jika anda memadamkannya, headscale akan menjana identiti baharu dan klien perlu mendapatkan kunci pelayan yang baharu sebelum menyambung semula; pendaftaran sedia ada kekal dalam pangkalan data.

Meletakkan TLS di hadapan headscale

Pelanggan harus mencapai server_url melalui HTTPS. Caddy merupakan laluan paling singkat kerana ia meminta dan memperbaharui sijil secara automatik.

sudo apt install -y caddy

Gantikan /etc/caddy/Caddyfile dengan blok daripada dokumentasi 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 akan mencetak adapted config to JSON apabila fail tersebut dihurai. Amaran bahawa fail tidak diformat hanyalah bersifat kosmetik. Dari komputer riba anda, curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health juga sepatutnya mencetak 200. Semakan tunggal itu membuktikan DNS, firewall, sijil dan proksi semuanya berfungsi bersama.

Berikut adalah perincian proksi yang sering memakan masa pengguna. Sambungan kawalan Tailscale adalah naik taraf HTTP, ia dimulakan dengan POST dan bukannya GET, dan nilai pengepala Upgrade adalah tailscale-control-protocol. Caddy melalukan perkara tersebut tanpa konfigurasi tambahan. nginx tidak melakukannya, jadi bahagian hadapan nginx perlu memajukan pengepala Upgrade dan Connection secara eksplisit. Dokumentasi headscale melakukannya dengan peta naik taraf (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;
    }
}

Jika anda meninggalkan baris-baris tersebut, permintaan biasa masih akan berjaya, itulah sebabnya /health mengembalikan 200 dan segala-galanya kelihatan baik, sedangkan sambungan kawalan tidak pernah terbentuk: nod baharu tidak dapat mendaftar, dan nod sedia ada tidak dapat menyambung semula serta melaporkan status dalam talian. Jika anda memilih laluan nginx, Certbot pada Ubuntu 24.04 dengan nginx merangkumi bahagian sijil.

Port yang perlu dibuka dalam UFW

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

Port 443 membawa setiap sambungan kawalan pelanggan ke headscale. Jika anda mengaktifkan relay DERP terbenam kemudian, ia juga memerlukan 3478/udp, yang diterangkan di bawah. Port 80 disediakan untuk cabaran HTTP ACME (automatic certificate management environment) dan lencongan ke HTTPS. Caddy masih boleh mendapatkan sijil walaupun port 80 ditutup, kerana ia boleh menggunakan cabaran TLS-ALPN pada port 443, tetapi dengan port 80 dibuka, kedua-dua cabaran tersedia dan permintaan http:// biasa akan dilencongkan.

Port 8080 kekal ditutup. listen_addr adalah 127.0.0.1:8080, jadi proksi mencapai headscale melalui antara muka loopback dan tiada peraturan firewall yang terlibat. Membuka 8080 dalam UFW tidak akan mendedahkan apa-apa, memandangkan tiada apa yang mendengar padanya dari luar, dan ia juga tidak memberikan sebarang kelebihan. Perlu diingat bahawa kebanyakan penyedia menjalankan firewall kedua dalam panel kawalan mereka, berasingan daripada UFW, jadi port boleh dibuka pada pelayan tetapi masih ditutup di bahagian tepi (edge). Asas firewall UFW pada VPS membincangkan sintaks peraturan dengan lebih terperinci.

Mencipta pengguna dan kunci pra-pengesahan

sudo headscale users create alice
sudo headscale users list

Perintah headscale ialah klien. Ia berhubung dengan daemon yang sedang berjalan melalui soket unix di /var/run/headscale/headscale.sock, yang mempunyai mod 0770 dan dimiliki oleh kumpulan headscale. Dua perkara terhasil daripada keadaan ini. Perintah tersebut gagal apabila servis dihentikan, yang merupakan sebab lain mengapa urutan dalam panduan ini penting, dan ia memerlukan sudo melainkan anda menambah akaun anda sendiri ke dalam kumpulan headscale.

users list mencetak ID bersebelahan dengan setiap nama. Anda memerlukan nombor tersebut kerana perintah kunci memerlukan ID pengguna berangka dan bukannya nama.

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

Kunci tersebut dicetak sekali sahaja. Salin kunci itu sekarang. Kunci pra-pengesahan adalah untuk kegunaan sekali sahaja dan sah selama satu jam melainkan anda menetapkan sebaliknya, jadi --expiration 24h berbaloi untuk ditetapkan semasa anda masih dalam fasa ujian. Tambahkan --reusable untuk kunci yang mendaftarkan beberapa mesin, dan kendalikan kunci tersebut seperti kata laluan, kerana sesiapa yang memegangnya boleh menyertai rangkaian anda.

Sambungkan klien pertama anda dengan --login-server

Pada mesin yang ingin anda sertai:

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 akan memaparkan alamat yang diberikan oleh headscale, contohnya seperti 100.64.0.1. Kembali ke pelayan, sudo headscale nodes list akan menunjukkan nod tersebut berserta ID, pengguna dan status dalam taliannya.

Gunakan alamat HTTPS awam daripada server_url untuk --login-server. Klien akan membuang garis miring (trailing slash) daripada URL kawalan; tiada perbandingan rentetan tepat yang memerlukan anda untuk membuangnya.

Mesin yang sebelum ini telah log masuk ke perkhidmatan hos Tailscale akan mengekalkan log masuk tersebut. Jalankan sudo tailscale logout pada mesin itu terlebih dahulu, kemudian jalankan tailscale up dengan --login-server.

Jika anda tidak menyertakan --auth-key, klien akan mencetak URL sebagai ganti. Buka URL tersebut dan halaman itu akan memaparkan pengecam bagi percubaan pendaftaran tersebut, yang kemudiannya perlu anda luluskan pada pelayan:

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

Borang tersebut lebih mudah digunakan untuk komputer riba anda sendiri. Preauth key adalah lebih baik untuk sebarang skrip, kerana tiada manusia yang perlu memantau proses tersebut. Sebaik sahaja VPS itu sendiri menjadi nod, ia juga boleh membawa trafik internet mesin anda yang lain, iaitu persediaan exit node, dengan satu perbezaan iaitu anda meluluskan laluan (route) yang diiklankan pada pelayan menggunakan arahan headscale dan bukannya melalui konsol pentadbir yang dihoskan. Jika matlamat anda adalah untuk mencapai rangkaian peribadi di sebalik VPS tersebut dan bukannya laluan keluar ke internet, langkah kelulusan yang sama merangkumi pengiklanan subnet tersebut kepada seluruh tailnet anda. Menerbitkan satu aplikasi daripada nod, berbanding menghalakan keseluruhan rangkaian melaluinya, adalah tugas yang berbeza, dan serve dan funnel adalah dua cara untuk melakukannya, walaupun kedua-duanya bergantung pada sijil dan jentera ingress milik Tailscale sendiri, jadi anggaplah ia sebagai ciri tailnet yang dihoskan dan bukannya sesuatu yang disediakan oleh headscale.

DERP, dan perkara yang menyalurkan trafik apabila laluan terus gagal

DERP (designated encrypted relay for packets) ialah laluan sandaran. Apabila dua nod tidak dapat membuka sambungan WireGuard secara terus, biasanya kerana kedua-duanya berada di sebalik NAT (network address translation) yang ketat, nod tersebut akan menghantar paket melalui relay. Relay tidak memegang sebarang kunci, jadi ia tidak boleh membaca trafik anda. Ia hanya melihat nod mana yang sedang berhubung dan jumlah data yang dipindahkan.

Fahami dengan jelas tindakan konfigurasi lalai. Headscale dihantar dengan menunjuk kepada https://controlplane.tailscale.com/derpmap/default menggunakan auto_update_enabled: true dan update_frequency: 3h, jadi pelan kawalan adalah milik anda manakala relay adalah milik Tailscale. Bagi kebanyakan orang, ini adalah pertukaran yang adil. Jika tidak, jalankan relay anda sendiri.

Untuk menjalankan relay sendiri, tetapkan enabled: true di bawah derp.server dalam config.yaml, gantikan ipv4: 198.51.100.1 dan ipv6: 2001:db8::1 yang disertakan dengan alamat awam relay anda, atau buang kedua-dua tetapan tersebut untuk menggunakan DNS, kemudian mulakan semula headscale dan buka port STUN (session traversal utilities for NAT) dengan sudo ufw allow 3478/udp. Tetapan alamat tersebut mengatasi DNS, jadi membiarkan mana-mana pemegang tempat (placeholder) di situ akan menghantar klien ke alamat yang tidak boleh dicapai. Fail konfigurasi menyatakan keperluan tersebut dengan jelas: server_url mesti menggunakan https, kerana DERP memerlukan TLS. Mengosongkan senarai derp.urls akan membuang relay Tailscale daripada peta; pastikan relay terbenam atau relay tersuai yang berfungsi tersedia sebelum melakukan perkara tersebut. Headscale enggan bermula dengan peta relay yang kosong, dan peta yang hanya mengandungi relay yang tidak boleh dicapai akan menyebabkan nod yang tidak dapat bersambung secara terus gagal untuk berkomunikasi.

Daripada klien, tailscale netcheck mencetak kependaman (latency) ke setiap wilayah relay yang diketahui, dan tailscale status menunjukkan direct dengan alamat atau relay dengan kod wilayah untuk sambungan rakan setara (peer) yang aktif. Rakan setara yang tersekat pada relay perlu diperiksa laluan terusnya, termasuk peraturan NAT dan firewall. Rakan setara yang berada dalam status direct tetapi masih perlahan adalah isu yang berbeza, dan jawapan lazim bagi masalah tersebut ialah MTU dan bukannya terowong itu sendiri.

Mengapa nod dipaparkan sebagai luar talian (offline)?

Proksi menggugurkan naik taraf (upgrade). Tandanya ialah /health mengembalikan 200 manakala pendaftaran baharu gagal atau nod sedia ada tidak dapat menyambung semula. Sambungan kawalan adalah POST yang membawa Upgrade: tailscale-control-protocol, dan proksi yang tidak memajukannya akan menyekat pendaftaran serta saluran yang melaporkan status nod. Bandingkan konfigurasi nginx anda dengan baris naik taraf di atas, atau tukar kepada Caddy untuk memastikan proksi bukan puncanya.

Alamat kawalan awam telah berubah. Nod terus mendail alamat yang dikonfigurasikan dengan --login-server; menukar server_url tidak mengemas kini tetapan klien tersebut. Jika alamat lama tidak lagi mencapai pelayan anda, jalankan sudo tailscale up --login-server https://headscale.example.com --force-reauth pada setiap nod.

Klien tidak berjalan. Pada nod, gunakan sudo systemctl is-active tailscaled dan sudo journalctl -u tailscaled -n 50 --no-pager. Klien yang tidak dapat menyelesaikan atau mencapai domain anda akan merekodkan percubaan semula di sana.

Kunci telah tamat tempoh. Dibincangkan dalam bahagian seterusnya.

Untuk memantau bahagian pelayan semasa anda menguji, jalankan sudo journalctl -u headscale -f pada VPS dan mulakan semula tailscaled pada klien. Semak juga jurnal klien: permintaan yang sampai ke headscale tidak menjamin penghasilan baris pada tahap log lalai, jadi ketiadaan log pelayan sahaja tidak membuktikan kegagalan DNS, firewall atau proksi.

Tamat tempoh kunci, dan nod yang berhenti berfungsi beberapa minggu kemudian

Terdapat dua jenis tamat tempoh yang berbeza, dan mencampuradukkannya hanya membuang masa.

Kunci preauth direka untuk tamat tempoh dengan cepat. Nilai lalai ialah satu jam dan satu penggunaan. Jika tailscale up menolak kunci tersebut, jana kunci baharu pada pelayan dan bukannya menyunting apa-apa pada klien.

Kunci nod ialah bahagian yang mempunyai jangka hayat panjang. Bahagian node dalam config.yaml menetapkan expiry: 0, dan 0 bermaksud tiada tamat tempoh lalai; tamat tempoh klien secara eksplisit atau tamat tempoh OIDC masih boleh digunakan. Nod yang ditag dikecualikan daripada tamat tempoh automatik, walaupun pentadbir boleh menamatkan tempohnya secara eksplisit. Tetapkan expiry: 180d jika anda mahukan tempoh lalai 180 hari untuk pendaftaran yang tidak ditag, namun tamat tempoh yang diminta oleh klien akan diutamakan dan OIDC boleh mengatasi nilai lalai tersebut. Menukar tetapan ini tidak akan mengubah pendaftaran sedia ada secara retroaktif. Nod yang mempunyai tamat tempoh memerlukan pengesahan semula sebelum tarikh akhir tersebut, menggunakan sudo tailscale up --login-server https://headscale.example.com --force-reauth, dan pelayan tanpa kepala (headless) yang tidak disahkan semula oleh sesiapa akan terkeluar daripada rangkaian apabila pendaftarannya tamat.

Lakukan secara manual apabila seseorang kehilangan komputer riba. sudo headscale nodes list memberikan anda ID tersebut, kemudian sudo headscale nodes expire -i 3 akan melog keluar nod itu, dan sudo headscale nodes delete -i 3 akan membuangnya daripada rangkaian sepenuhnya.

Sandaran dan naik taraf

/var/lib/headscale dan /etc/headscale secara bersama membentuk keseluruhan pelayan. Hentikan servis sebelum anda menyalin fail tersebut, kerana SQLite mungkin mempunyai proses penulisan yang sedang berjalan dan pangkalan data yang disalin semasa beban kerja boleh menjadi tidak konsisten.

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

Alihkan kedua-dua fail keluar dari pelayan. Fail tersebut mengandungi kunci peribadi dan setiap pendaftaran, jadi ia memerlukan penjagaan yang sama seperti pelayan itu sendiri. sandaran restic daripada VPS merangkumi cara melakukan perkara ini mengikut jadual dan dalam bentuk yang disulitkan.

Naik taraf mengulangi proses pemasangan: muat turun .deb, sudo apt install ./headscale.deb yang baharu, kemudian mulakan semula dan jalankan semula semakan is-active dan /health. Sejak versi 0.29, laluan naik taraf adalah ketat. Melangkau versi minor adalah disekat, begitu juga dengan menurunkan versi kepada versi minor yang lebih lama. Bergerak satu versi minor pada satu masa, buat sandaran sebelum setiap langkah, dan baca nota keluaran versi tersebut terlebih dahulu, kerana keluaran yang sama telah mengubah tingkah laku polisi ACL dan memindahkan beberapa kunci konfigurasi. Versi 0.29.6 juga merangkumi kemas kini keselamatan untuk pengesahan sijil dan dependensi, jadi pemasangan 0.29 sedia ada perlu menggunakan keluaran tampalan ini.

FAQ

Adakah headscale sudah berjalan sebaik sahaja saya memasang .deb?

Ya. Pakej tersebut memulakan servis sebaik sahaja ia dipasang, pada /etc/headscale/config.yaml yang dibekalkan, yang hanya mendengar pada loopback dan menetapkan server_url kepada http://127.0.0.1:8080. Pada pemasangan baharu, ia tidak mengaktifkan servis tersebut, jadi ia tidak akan bermula semasa but sehingga anda menjalankan sudo systemctl enable headscale. Alamat yang dibekalkan tidak berguna kepada klien, jadi sunting server_url, listen_addr dan base_domain, kemudian jalankan sudo systemctl restart headscale dan sahkan dengan sudo systemctl is-active headscale. Ia mestilah restart: headscale membaca fail tersebut hanya apabila ia bermula, dan enable --now pada servis yang sedang berjalan hanya mengaktifkannya untuk but tetapi tidak memulakannya semula, jadi nilai lama masih kekal aktif. Jika ia gagal selepas dimulakan semula, sudo journalctl -u headscale -n 50 --no-pager akan menamakan masalah tersebut, dan pada peringkat ini ia hampir selalu merupakan ralat YAML, kerana headscale menghuraikan keseluruhan fail sebelum ia mengikat port.

Adakah saya masih perlu memasang klien Tailscale biasa pada mesin saya?

Ya. Headscale hanya menggantikan pelayan kawalan. Setiap nod menjalankan klien rasmi daripada Tailscale, dan anda menghalakannya ke pelayan anda dengan sudo tailscale up --login-server https://headscale.example.com. Flag tersebut wujud dalam klien standard, jadi tiada apa-apa yang perlu ditampal atau dibina semula.

Adakah trafik saya melalui pelayan headscale?

Biasanya tidak. Headscale menyelaraskan rangkaian serta memberikan kunci dan alamat, manakala laluan data adalah WireGuard terus antara nod anda. Trafik hanya melencong apabila dua nod tidak dapat mencapai satu sama lain secara terus dan beralih kepada relay DERP, dan dengan konfigurasi yang dibekalkan, relay tersebut adalah relay awam milik Tailscale. Jalankan tailscale status pada nod untuk melihat sama ada peer tertentu adalah direct atau pada relay.

Mengapa nod saya kekal luar talian selepas ia mendaftar?

Nod yang muncul dalam headscale nodes list tetapi tidak pernah dalam talian perlu diperiksa sambungan kawalannya, termasuk reverse proxy. Sambungan tersebut adalah HTTP upgrade yang dihantar sebagai POST dengan header Upgrade: tailscale-control-protocol, dan nginx akan menggugurkannya melainkan anda menghantar header Upgrade dan Connection secara eksplisit dengan proxy_set_header, yang dilakukan oleh konfigurasi di atas melalui blok map $http_upgrade $connection_upgrade miliknya. Menggugurkan header tersebut juga menghalang nod baharu daripada mendaftar. Caddy menghantarnya tanpa konfigurasi tambahan, yang menjadikannya cara pantas untuk menguji sama ada proxy menjadi punca masalah.

Adakah saya memerlukan nama domain dan TLS untuk headscale?

Untuk persediaan ini, ya: gunakan nama domain dan HTTPS. Sijil juga boleh meliputi alamat IP kosong, tetapi fail konfigurasi menyatakan bahawa DERP memerlukan TLS. Domain berserta Caddy mengambil masa kira-kira lima minit dan memberikan anda titik akhir HTTPS yang diperbaharui secara automatik. HTTP biasa adalah mungkin, tetapi dokumentasi headscale sangat mengesyorkan HTTPS pada port 443 untuk pengeluaran, dan menyatakan bahawa klien Tailscale menganggap HTTPS pada port 443 dalam situasi tertentu.