Apa itu Tailscale dan bagaimana ia berfungsi?

Apakah itu Tailscale?

Tailscale ialah VPN yang menyambungkan mesin anda terus antara satu sama lain, bukannya menghalakan semua trafik melalui satu gateway yang anda kendalikan. Setiap nod menjalankan WireGuard, jadi paket dihantar secara disulitkan dari satu pelayan ke pelayan yang lain dan tiada apa-apa dalam laluan tersebut boleh membacanya. Pelayan koordinasi yang dihoskan mengendalikan proses pengenalan. Ia menyimpan dan mengedarkan kunci awam serta memberitahu setiap nod di mana nod lain berada. Ia juga menolak turun peraturan akses yang anda tulis.

Pembahagian tersebut merupakan keseluruhan reka bentuknya. Data plane adalah peer-to-peer dan disulitkan antara nod. Control plane pula ialah perkhidmatan yang dijalankan oleh Tailscale untuk anda. Setiap soalan penting mengenai Tailscale, termasuk soalan yang sukar tentang kepercayaan, berpunca daripada dua fakta tersebut. Jika anda pernah membina VPN WireGuard secara manual pada VPS, Tailscale adalah terowong yang sama dengan pengagihan kunci dan traversal firewall yang dilakukan untuk anda.

Bagaimanakah Tailscale berfungsi?

Rangkaian nod peribadi anda dipanggil tailnet. Empat perkara berlaku apabila sesebuah mesin menyertai rangkaian tersebut.

1. Daemon tailscaled bermula, menjana pasangan kunci WireGuard, dan menyimpan statusnya dalam /var/lib/tailscale/tailscaled.state. Kunci peribadi kekal pada mesin tersebut. Kenyataan Tailscale sendiri adalah jelas: "kunci peribadi tidak akan sekali-kali meninggalkan nodnya."
2. Nod log masuk ke pelayan koordinasi dan memuat naik kunci awamnya, berserta alamat yang dipercayai boleh dihubungi. Tailscale menyifatkan pelayan tersebut sebagai "kotak simpanan kongsi untuk kunci awam."
3. Pelayan koordinasi menghantar semula peta rangkaian: kunci awam, alamat tailnet, nama mesin dan titik akhir calon bagi setiap nod yang dibenarkan untuk dihubungi oleh nod ini.
4. Setiap pasangan nod kemudian cuba membina terowong WireGuard terus antara satu sama lain. Apabila ia gagal, mereka menghantar paket melalui geganti (relay) sebagai ganti.

Setiap nod mendapat alamat stabil daripada 100.64.0.0/10, julat NAT gred pembawa yang bermula dari 100.64.0.0 hingga 100.127.255.255. Tailscale menggunakan julat tersebut kerana ia dikhaskan untuk infrastruktur pembekal, jadi ia jarang bertembung dengan alamat peribadi yang sudah digunakan oleh pelayan anda. Pada Linux, terowong tersebut muncul sebagai antara muka bernama tailscale0.

Pelaksanaan WireGuard berada di dalam tailscaled dalam ruang pengguna (userspace), bukan dalam modul kernel. Itulah sebabnya Tailscale bermula pada virtualisasi kontena di mana sudo modprobe wireguard gagal dengan Operation not supported. Ini juga bermakna had daya pemprosesan (throughput) pada sesebuah kotak adalah lebih rendah berbanding WireGuard kernel, yang merupakan salah satu pertukaran yang dibincangkan dalam Tailscale berbanding WireGuard biasa.

Dua arahan memberitahu anda kedudukan semasa anda.

tailscale ip -4
tailscale status

tailscale status mencetak satu baris bagi setiap nod, dan lajur terakhir adalah yang paling penting.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct diikuti dengan alamat dan port bermakna kedua-dua mesin telah menemui laluan antara satu sama lain dan trafik adalah peer-to-peer. relay "fra" bermakna ia melalui geganti Tailscale di Frankfurt. - bermakna tiada sesi aktif dengan nod tersebut pada masa ini, yang merupakan perkara biasa.

Perkara yang boleh dan tidak boleh dilihat oleh pelayan koordinasi

Pelayan koordinasi menyimpan kunci awam dan metadata. Ia mengetahui nama mesin anda, pengguna atau tag yang memiliki setiap nod, alamat tailnet setiap nod, alamat awam yang boleh dihubungi oleh nod anda, masa terakhir setiap nod dalam talian, serta fail polisi yang anda tulis. Ini merupakan peta lengkap bagi keseluruhan armada anda.

Ia tidak menyimpan sebarang kunci peribadi, oleh itu ia tidak boleh menyahsulit trafik antara dua nod. Penyulitan adalah dari hujung ke hujung (end-to-end) antara peer WireGuard, dan pelayan koordinasi bukanlah salah satu peer tersebut.

Perkara yang boleh dilakukan oleh pelayan koordinasi adalah memberikan kunci. Mana-mana pelayan koordinasi, sama ada yang dihoskan atau dikendalikan sendiri, dipercayai untuk memberitahu nod anda kunci awam mana yang tergolong dalam tailnet. Ini merupakan teras kepada model ancaman yang dibincangkan di bawah, dan sebab mengapa Headscale, pelayan koordinasi sumber terbuka yang anda hoskan sendiri wujud.

Cara dua pelayan di sebalik firewall berbeza berhubung secara terus

NAT (network address translation) ialah mekanisme yang membolehkan banyak mesin berkongsi satu alamat awam. VPS anda biasanya mempunyai alamat awam sendiri, tetapi mesin lain yang anda mahukan dalam tailnet sering kali tidak mempunyainya: pelayan rumah, build runner dalam rangkaian pejabat, atau kotak di sebalik firewall penyedia yang tidak boleh anda ubah.

Tailscale mencari laluan menggunakan teknik yang dibina berdasarkan standard STUN (session traversal utilities for NAT) dan ICE. Setiap nod menghantar paket UDP kecil ke pelayan STUN dan mengetahui alamat awam serta port yang diberikan oleh penghala (router) kepada soket tersebut. Kedua-dua nod melaporkan calon tersebut kepada pelayan koordinasi, yang kemudian menyampaikannya ke pihak satu lagi. Seterusnya, kedua-dua nod mula menghantar paket kepada satu sama lain pada masa yang sama. Setiap penghala melihat paket keluar terlebih dahulu, jadi ia mencipta pemetaan dan menerima balasan yang tiba daripada alamat yang sama. Tiada pihak yang memerlukan peraturan firewall masuk. Itulah sebabnya NAS atau Pi di rumah boleh kekal boleh dicapai tanpa sebarang port yang diforward pada penghala anda, dan menggunakan Tailscale sebagai ganti port forwarding membincangkan persediaan tersebut, termasuk perkara yang tidak boleh dilakukannya.

Port yang digunakan adalah khusus. Terowong WireGuard terus menggunakan UDP dengan port sumber yang ditetapkan secara lalai kepada 41641. STUN berjalan melalui UDP 3478 ke pelayan geganti (relay) Tailscale. Sambungan kawalan lebih mengutamakan HTTP biasa pada TCP 80, yang dibalut dalam pengangkutan tersulit Tailscale sendiri, dan akan menggunakan HTTPS pada TCP 443 sebagai sandaran apabila port 80 tidak memberi respons. Data yang disalurkan melalui pelayan DERP Tailscale menggunakan HTTPS pada TCP 443, manakala geganti rakan setara (peer relay) yang anda jalankan di dalam tailnet anda sendiri membawanya melalui UDP. Kebanyakan masa anda tidak perlu membuka sebarang trafik masuk, walaupun pada rangkaian dengan NAT yang sukar, membenarkan UDP 41641 masuk menjadikan sambungan terus lebih berkemungkinan berlaku.

tailscale netcheck

Baca dua baris laporan tersebut. UDP: true bermaksud mesin ini boleh menghantar UDP ke internet, dan UDP: false bermaksud ia tidak boleh, jadi setiap sambungan daripada nod ini akan disalurkan melalui geganti. MappingVariesByDestIP: true bermaksud penghala memberikan port awam yang berbeza bagi setiap destinasi, jadi ramalan alamat di atas tidak dapat berfungsi dan nod tersebut biasanya kekal dalam keadaan disalurkan melalui geganti.

Apabila Tailscale menggunakan relay DERP sebagai ganti

DERP (designated encrypted relay for packets) ialah mekanisme sandaran. Tailscale menjalankan relay di banyak wilayah yang boleh dicapai melalui TCP 443, dan nod yang tidak mendapat laluan terus akan menghantar paket WireGuard melaluinya. Pengecualiannya ialah tailnet yang mempunyai relay rakan setara (peer relay) yang ditetapkan, iaitu peranti anda sendiri yang memajukan trafik melalui UDP. Tailscale akan mencuba laluan tersebut terlebih dahulu dan hanya menggunakan DERP apabila tiada laluan lain tersedia, dan tailscale status kemudian akan memaparkan sambungan tersebut sebagai peer-relay.

Paket kekal disulitkan. Tailscale menyatakan perkara ini dengan jelas: "tiada cara untuk pelayan DERP menyahsulit trafik anda. Ia hanya memajukan trafik yang telah disulitkan dari satu nod ke nod yang lain secara membuta tuli." Relay hanya melihat teks sifer (ciphertext) dan melihat nod mana yang berhubung dengan nod mana.

Relay juga membawa paket pertama bagi kebanyakan sambungan. Mencari laluan terus mengambil sedikit masa, jadi sesi sering bermula melalui relay dan dinaik taraf secara automatik sebaik sahaja kedua-dua nod menemui satu sama lain. Anda boleh memerhatikan proses ini berlaku.

tailscale ping db-1

Balasan pertama akan kembali sebagai via DERP(fra), kemudian baris seterusnya akan melaporkan sesuatu seperti via 198.51.100.24:41641. Perubahan itu menandakan peningkatan kepada terowong terus. Jika ia tidak berubah, jalankan tailscale netcheck pada kedua-dua hujung. Laluan yang melalui relay masih berfungsi. Ia melibatkan latensi kerana setiap paket perlu melalui lencongan ke mesin ketiga. Jika apa yang anda perhatikan ialah pemindahan data yang perlahan dan bukannya sambungan yang terputus, mengapa sambungan Tailscale melalui relay jauh lebih perlahan daripada sambungan terus mengukur jurang tersebut dan menunjukkan cara untuk mendapatkan VPS ke laluan terus.

Menyertai VPS ke tailnet anda

Skrip pemasangan merangkumi Ubuntu dan Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up mencetak URL. Buka URL tersebut, lakukan pengesahan, dan nod akan muncul dalam konsol pentadbir anda. Kemudian, pastikan daemon kembali berjalan selepas but semula, kerana ini adalah langkah yang sering dilupakan orang.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled sepatutnya mencetak enabled, dan tailscale status sepatutnya menyenaraikan nod baharu tersebut dengan alamat 100.x miliknya. Bagi pelayan yang dibina daripada skrip, URL interaktif tidak berguna. Jana kunci pengesahan (auth key) dalam konsol pentadbir dan hantarkannya, berserta tag yang merekodkan jenis mesin ini.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Nod yang ditag dimiliki oleh tag tersebut dan bukannya oleh individu yang menjalankan perintah, jadi ia akan terus berfungsi walaupun akaun individu tersebut telah tiada. Tag mesti diisytiharkan dalam fail polisi anda di bawah tagOwners terlebih dahulu, atau perintah tersebut akan ditolak. Penaggan juga mengubah cara mesin dikira dalam pelan anda, kerana sumber yang ditag diletakkan harga secara berasingan daripada peranti peribadi seseorang, dan apa yang sebenarnya dilindungi oleh pelan percuma menjelaskan di mana had tersebut diletakkan.

Dua tetapan penting untuk pengurusan kumpulan pelayan. Kunci nod tamat tempoh selepas 180 hari secara lalai (sehingga Oktober 2026), dan apabila kunci tamat tempoh "sambungan ke/daripada titik akhir tersebut akan berhenti berfungsi" sehingga peranti melakukan pengesahan semula. Seorang pentadbir boleh memilih Temporarily extend key pada mesin yang telah tamat tempoh dalam konsol pentadbir, yang memberikan masa 30 minit untuk log masuk semula atau melumpuhkan tamat tempoh. Nod yang disahkan dengan tag, seperti yang di atas, mempunyai ciri tamat tempoh kunci yang dilumpuhkan secara lalai. Bagi mana-mana pelayan tanpa pengawasan yang lain, buka baris mesin tersebut dalam konsol pentadbir dan pilih Disable Key Expiry. MagicDNS, yang diaktifkan secara lalai untuk tailnet yang dicipta pada atau selepas 20 Oktober 2022, memberikan setiap nod nama seperti db-1.yak-bebop.ts.net, yang diselesaikan oleh stub resolver pada 100.100.100.100. Gunakan nama tersebut dan bukannya alamat, kerana nod yang dibina semula akan mendapat alamat baharu tetapi mengekalkan namanya.

Jika pemasangan itu sendiri gagal pada apt atau pada repositori, ralat pemasangan Tailscale yang biasa pada Ubuntu merangkumi cara penyelesaiannya.

Mencapai servis yang terikat pada localhost

Di sinilah tailnet menjadi berguna, dan di sinilah ramai pengguna tersangkut. Menyertai tailnet tidak menjadikan servis loopback boleh dicapai.

ss -tlnp | grep 3000

Jika arahan tersebut mencetak 127.0.0.1:3000, soket hanya menerima paket yang destinasi alamatnya ialah 127.0.0.1. Permintaan daripada nod lain tiba dengan alamat destinasi 100.x nod ini, jadi kernel tidak mempunyai pendengar untuknya dan membalas dengan TCP reset. Pelanggan melaporkan Connection refused. Terowong berfungsi dengan baik. Masalahnya terletak pada pendengar (listener).

Terdapat dua penyelesaian yang wajar. Ikat servis tersebut pada alamat tailnet nod, yang memastikan ia tidak terdedah pada antaramuka awam tanpa proksi: gunakan --bind 100.101.102.104 atau pilihan yang setara dalam konfigurasi anda, dan bagi kontena, terbitkan port sebagai -p 100.101.102.104:3000:3000. Atau, biarkan servis pada loopback dan letakkan Tailscale di hadapannya.

tailscale serve 3000

Tindakan itu memproksi permintaan ke http://127.0.0.1:3000 dan menyediakannya di dalam tailnet anda pada nama ts.net melalui HTTPS, sebaik sahaja sijil HTTPS diaktifkan untuk tailnet tersebut. Ia kekal peribadi untuk nod anda. Versi awam bagi idea yang sama ialah Funnel, dan Tailscale serve melawan funnel merangkumi pilihan yang anda perlukan.

Dua tugasan berkaitan mempunyai halaman tersendiri. Mencapai keseluruhan rangkaian peribadi yang tidak mempunyai Tailscale dipasang memerlukan subnet router pada VPS, dan menghantar trafik internet keluar bagi sesuatu nod melalui nod lain memerlukan exit node.

Menutup port yang tidak lagi diperlukan

Apabila pentadbir sudah boleh mencapai pelayan melalui tailnet, port 22 awam tidak lagi diperlukan. Inilah manfaat praktikalnya: port yang ditutup tidak boleh diserang melalui brute force, dan log anda tidak lagi dipenuhi dengan percubaan pencerobohan.

Urutan langkah adalah penting. Tambah akses tailnet, pastikan anda boleh log masuk melaluinya daripada sesi kedua, dan hanya selepas itu buang peraturan awam.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Selepas itu, padamkan peraturan SSH awam dan sambung semula menggunakan nama MagicDNS. Ambil perhatian tentang fungsi sebenar ufw allow in on tailscale0: ia mempercayai semua trafik yang tiba melalui terowong, jadi fail polisi Tailscale anda menjadi kawalan akses dan bukannya ufw. Tulis polisi dengan mengambil kira perkara ini.

Satu amaran untuk sesiapa yang menjalankan kontena. Port Docker yang diterbitkan memasang peraturan NAT sendiri dan memintas ufw, jadi ufw deny tidak akan menutupnya. Port Docker yang diterbitkan memintas ufw menjelaskan mekanismenya. Menerbitkan ke alamat tailnet, seperti di atas, dapat mengelakkan perkara ini. Jika aplikasi dijalankan di bawah Docker Compose, sidecar Tailscale dalam stack Compose melangkah lebih jauh dengan membuang port yang diterbitkan sepenuhnya, menjadikan kontena hanya boleh dicapai melalui nama tailnetnya.

Perkara yang dilindungi oleh Tailscale, dan perkara yang tidak dilindunginya

Perkara ini perlu dinyatakan dengan jelas, kerana versi pemasaran sering mengaburkan batasnya.

Dilindungi: trafik antara dua nod disulitkan dari hujung ke hujung menggunakan WireGuard, dan tiada geganti di tengah yang boleh membacanya. Kunci peribadi tidak pernah meninggalkan mesin yang menjananya. Nod tidak memerlukan port awam masuk, jadi tiada apa-apa pada port 22 atau 5432 untuk diimbas oleh internet. Akses antara nod ditentukan oleh fail polisi dan bukannya oleh sesiapa yang mengetahui alamat.

Tidak dilindungi: pelayan koordinasi dapat melihat graf peranti anda. Metadata tersebut sensitif dengan sendirinya, kerana nama mesin, pemilik, alamat, dan waktu dalam talian menggambarkan infrastruktur anda. Ia juga mengedarkan kunci, yang merupakan risiko lebih besar. Tailscale menyatakannya secara terus: "Jika Tailscale berniat jahat, dan secara rahsia memasukkan nod baharu ke dalam rangkaian anda, maka Tailscale boleh menghantar atau menerima trafik ke nod sedia ada anda dalam teks biasa." Penyedia daftar masuk tunggal (SSO) anda berada dalam laluan kepercayaan yang sama, kerana sesiapa yang boleh mencipta identiti di sana boleh menambah nod. Selain itu, nod yang terjejas adalah rakan setara di dalam tailnet, jadi apa sahaja yang dicapainya seterusnya adalah tertakluk kepada apa yang dibenarkan oleh polisi anda. Sama ada ini merupakan risiko yang boleh diterima bergantung kepada siapa yang anda pertahankan, dan model kepercayaan penuh membincangkan setiap kes tersebut, termasuk perkara yang boleh dilakukan oleh akaun identiti yang dicuri.

Terdapat dua jawapan bagi risiko pengedaran kunci. Pertama ialah tailnet lock, yang memerlukan nod dipercayai sedia ada untuk menandatangani nod baharu secara kriptografi sebelum nod anda yang lain menerimanya. Control plane yang menambah nod tanpa tandatangan yang sah akan diabaikan. Konsol pentadbir menjana baris tailscale lock init yang tepat untuk nod penandatangan anda, dan setiap nod boleh mengesahkan apa yang dilihatnya.

tailscale lock status

Semua nod harus melaporkan set kunci penandatangan dipercayai yang sama. Jawapan kedua ialah menjalankan control plane anda sendiri. Pelayan koordinasi Headscale yang dihoskan sendiri menggunakan protokol yang sama kepada klien yang sama, yang memindahkan graf peranti dan pengedaran kunci ke perkakasan milik anda. Anda kemudiannya bertanggungjawab ke atas masa aktif pelayan tersebut. Jika anda masih membandingkan control plane yang dihoskan sendiri dan belum membuat keputusan, NetBird ialah VPN mesh berasingan yang pelayannya anda jalankan dari hujung ke hujung pada satu VPS.

Satu tetapan lalai yang perlu diperbaiki pada hari pertama. Tailnet baharu dihantar dengan sifat permisif: "fail polisi tailnet lalai membolehkan komunikasi antara semua peranti di dalam tailnet." Sebaik sahaja anda menambah bahagian acls, model tersebut bertukar kepada menafikan secara lalai dan hanya peraturan anda yang dibenarkan.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Polisi tersebut membolehkan ahli tailnet mencapai SSH pada pelayan yang ditag dan tiada yang lain. Tambah peraturan bagi setiap servis dan bukannya membiarkan wildcard di tempatnya, kerana wildcard bermaksud satu kunci komputer riba yang dicuri boleh mencapai pangkalan data anda.

Mod kegagalan dan rentetan yang akan anda lihat

tailscale status sentiasa menyatakan relay. Kedua-dua nod tidak pernah membina laluan terus. Jalankan tailscale netcheck pada kedua-dua hujung. UDP: false bermaksud UDP disekat pada bahagian keluar, jadi hanya relay yang boleh berfungsi. MappingVariesByDestIP: true bermaksud terdapat NAT keras yang menghalang, dan membenarkan UDP 41641 masuk pada bahagian yang anda kawal sering kali menyelesaikan masalah ini.

Nod yang berfungsi selama berbulan-bulan hilang. Punca biasa ialah kunci nod yang tamat tempoh pada tetapan lalai 180 hari, jadi periksa mesin tersebut dalam konsol pentadbir terlebih dahulu. Jika ia menunjukkan status tamat tempoh, sudo tailscale up pada mesin tersebut akan memulihkannya, dan melumpuhkan tamat tempoh kunci pada pelayan akan menghalangnya daripada berulang. Jika ia tidak tamat tempoh, periksa fail polisi, kerana nasihat Tailscale sendiri untuk peranti yang hilang daripada tailscale status adalah dengan mencari peraturan akses yang menghalang sambungan tersebut.

Peer disenaraikan tetapi sambungan tamat masa (timeout). Jika tailscale ping mendapat balasan, ketersambungan berfungsi dan punca yang mungkin ialah polisi yang menafikan trafik tersebut. Periksa bahagian acls untuk peraturan yang meliputi sumber, destinasi dan port ini. Paket yang dinafikan akan digugurkan dan bukannya dijawab, itulah sebabnya anda mendapat tamat masa dan bukannya Connection refused.

Nama MagicDNS tidak dapat diselesaikan (resolve). ping db-1 gagal manakala ping 100.101.102.104 berfungsi. Pertama, sahkan klien menerima tetapan DNS Tailscale: nod yang dimulakan dengan --accept-dns=false tidak akan menghantar pertanyaan ke stub resolver di 100.100.100.100. Kemudian lihat cat /etc/resolv.conf dan apa sahaja yang menulis fail tersebut pada mesin itu. Pada sistem yang menggunakan systemd-resolved, fail tersebut biasanya merupakan symlink ke /run/systemd/resolve/stub-resolv.conf dan tidak menyenaraikan 100.100.100.100 di situ adalah perkara biasa. Di mana tailscaled menulis fail tersebut secara terus, klien DHCP atau alat lain yang menulis ganti fail tersebut akan merosakkan MagicDNS. Jika tiada satu pun daripada ini menjelaskan masalah tersebut, kerosakan juga boleh berpunca daripada konfigurasi DNS tempatan atau rangkaian. Ia adalah kelas masalah yang sama seperti DNS terputus di dalam terowong WireGuard.

tailscale up menolak tag anda. Tag tersebut tidak diisytiharkan di bawah tagOwners dalam fail polisi. Tambahkannya di sana, kemudian jalankan arahan tersebut sekali lagi.

FAQ

Adakah Tailscale sebuah VPN atau rangkaian mesh?

Kedua-dua istilah adalah tepat dan ia menerangkan lapisan yang berbeza. Terowong yang digunakan adalah WireGuard, yang menjadikannya sebuah VPN. Topologinya pula adalah mesh, kerana setiap nod membina terowong terus ke nod lain yang dihubungi, bukannya menghantar setiap paket melalui satu pelayan pusat. Pelayan koordinasi berada dalam laluan kawalan, bukan laluan data, jadi jika ia tidak dapat dicapai, terowong sedia ada anda akan terus membawa trafik. Perkara yang terhenti semasa gangguan adalah penyertaan nod baharu serta perubahan pada kunci atau dasar. Walau bagaimanapun, ia bukan VPN privasi secara lalai: laman web masih melihat alamat awam anda sendiri sehingga anda menghantar trafik melalui exit node, dan apa yang disembunyikan oleh Tailscale daripada laman web dan ISP anda bergantung pada setiap tetapan.

Bolehkah Tailscale membaca trafik saya?

Tidak untuk kandungannya. Trafik disulitkan secara hujung-ke-hujung antara nod menggunakan WireGuard, kunci peribadi tidak pernah meninggalkan nod, dan geganti DERP menghantar paket yang tidak dapat dinyahsulit olehnya. Tailscale memang melihat metadata: nama mesin, pemilik, kunci awam, alamat titik akhir dan status dalam talian setiap nod. Ia juga mengedarkan kunci, jadi pelayan koordinasi yang terjejas boleh cuba memasukkan nod yang kemudiannya akan dipercayai oleh armada anda. Tailnet lock menghalang perkara tersebut dengan memerlukan tandatangan daripada nod anda sendiri yang dipercayai, dan Headscale membuang pelan kawalan yang dihoskan daripada gambaran keseluruhan.

Adakah saya perlu membuka port firewall untuk Tailscale?

Hampir tidak perlu untuk trafik masuk. Panduan Tailscale sendiri menyatakan bahawa "kebanyakan masa, anda tidak perlu membuka sebarang port firewall." Untuk trafik keluar, nod memerlukan TCP 443 ke pelayan koordinasi dan geganti, serta UDP 3478 untuk STUN. Terowong terus menggunakan UDP dengan port sumber yang ditetapkan secara lalai kepada 41641. Membenarkan UDP 41641 masuk adalah pilihan, dan ia hanya membantu sambungan terus berjaya pada rangkaian yang sukar.

Mengapa nod lain tidak dapat mencapai servis saya pada port 3000?

Semak alamat bind terlebih dahulu dengan ss -tlnp. Pendengar pada 127.0.0.1:3000 akan menolak sambungan yang tiba dengan alamat 100.x tailnet nod tersebut, kerana soket itu hanya menerima destinasi loopback, dan klien akan melihat Connection refused. Bind servis tersebut ke alamat tailnet, atau jalankan tailscale serve 3000 untuk menjadikannya proksi. Jika pendengar sudah berada pada 0.0.0.0 dan sambungan tamat masa (timeout) dan bukannya ditolak, masalahnya bukan pada alamat bind. Periksa peraturan dasar dan firewall hos terlebih dahulu, kemudian periksa firewall rangkaian dan sama ada pengesahan mana-mana peranti telah tamat tempoh.

Patutkah saya menjalankan Headscale dan bukannya pelayan koordinasi Tailscale?

Jalankan Headscale apabila graf peranti atau pengedaran kunci perlu kekal pada infrastruktur yang anda kawal, atau apabila tailnet perlu berfungsi tanpa bergantung pada servis luar. Klien dan protokolnya adalah sama. Kosnya ialah anda kini perlu mengendalikan pelayan koordinasi, dan gangguannya akan menghentikan penyertaan nod baharu serta menghalang perubahan dasar daripada diaplikasikan. Untuk armada yang kecil, pelan kawalan yang dihoskan dengan tailnet lock diaktifkan biasanya merupakan pilihan yang lebih baik.