Secure ba ang Tailscale? Ipinaliwanag ang trust model

Secure ba ang Tailscale? Ang maikling sagot

Secure ba ang Tailscale? Para sa pangunahing ikinababahala ng karamihan, oo: hindi kailanman hinahawakan ng coordination server na nagpapatakbo ng iyong tailnet ang private keys na nag-e-encrypt ng iyong traffic, kaya hindi nito mababasa ang ipinapadala ng iyong mga device sa isa't isa. Tahasang sinasabi ito sa security page ng Tailscale: "Hindi kailanman umaalis sa device ang private keys. Laging end-to-end encrypted ang lahat ng traffic." Iba ang mas kapaki-pakinabang na tanong. Ang isang coordination server na na-breach, o napasailalim sa legal na utos, ay hindi kailangang basahin ang iyong mga packet. Tinutukoy nito kung aling public keys ang pinagkakatiwalaan ng iyong mga device, kaya maaari itong mag-enrol ng device na hindi mo inaprubahan.

Ganito ang trust model sa isang pangungusap: pinoprotektahan ng encryption ang data, at tinutukoy ng control plane kung sino ang kabilang. Tinutukoy ng bawat seksyon sa ibaba ang isang party na kailangan mong pagkatiwalaan, ipinapaliwanag kung ano ang aktuwal nitong magagawa, at inilalahad ang control na naglilimita rito. Kung bago sa iyo ang mismong product, magsimula sa kung ano ang Tailscale at kung paano gumagana ang mesh nito.

Magkahiwalay ang control plane at data plane

Ang Tailscale ay isang mesh VPN (virtual private network) na nakabatay sa WireGuard, ang parehong protocol na mano-mano mong iko-configure sa isang self-hosted WireGuard VPS. Bawat device ay lokal na gumagawa ng sarili nitong WireGuard key pair. Sa post ng Tailscale na how it works, tinatawag ng coordination server ang “isang shared drop box para sa mga public key” at sinasabing “Ang private key ay hindi kailanman umaalis sa node nito.”

Ang data plane ay ang naka-encrypt na traffic sa pagitan ng iyong mga device. Dumadaan ito mula device papunta sa device, at direktang ipinapadala kapag pinapayagan ito ng network. Ang control plane ay ang lahat ng iba pa: kung aling mga device ang kabilang sa tailnet, kung aling public key ang pagmamay-ari ng bawat device, ang access policy, ang DNS settings, at ang relay list. Pinapatakbo ng Tailscale ang control plane bilang hosted service. Ikaw ang nagpapatakbo ng data plane sa sarili mong mga machine.

Panatilihing magkahiwalay ang dalawang ito upang masagot ang bawat security question dito. Katangian ng data plane ang encryption. Desisyon ng control plane ang membership. Walang antas ng encryption ang makapagsasabi kung sino ang pinapayagang maging peer.

Ano ang maaaring gawin ng isang na-kompromisong coordination server?

Hindi nito made-decrypt ang iyong traffic. Ang mga key na ginagamit sa encryption ay ginagawa sa iyong mga device at hindi kailanman ina-upload. Kaya walang maaaring kunin o ma-leak na magbubukas sa tunnel. Nalalapat din ito sa relayed traffic, na tatalakayin sa ibaba.

Maaari itong mag-enrol ng isang node. Nang ianunsyo ng Tailscale ang tailnet lock, inilarawan ng kumpanya ang panganib sa sarili nitong mga salita: maaaring "gumamit ng node na lihim na idinagdag upang magpadala o tumanggap ng traffic papunta sa iyong mga kasalukuyang node", at sa puntong iyon, "hindi na mahalaga na encrypted ang traffic dahil maaaring malicious ang peer mismo". Pinagkakatiwalaan ng iyong device ang isang peer dahil sinabi ng control plane na kabilang sa tailnet ang key nito.

Maaari nitong baguhin kung aling mga resource ang maaaring maabot ng iyong mga device. Nasa control plane ang access policy at ipinapamahagi ito sa mga node. Sinasabi ng tailnet lock white paper ng Tailscale na ang tailnet lock ay "hindi pumipigil sa isang na-kompromisong control plane na sirain ang connectivity sa iyong network, halimbawa sa hindi pamamahagi ng mga bagong node key o sa pamamahagi ng access control policy na nagkakait ng access sa lahat ng node."

Nakikita nito ang connection metadata sa alinmang paraan. Nagtatala ang network flow logs ng Tailscale ng mga event ng pagbubukas at pagsasara para sa bawat machine-to-machine connection. Nakasaad sa documentation na ang mga log na iyon ay "mahigpit na walang anumang impormasyon tungkol sa mga operasyon ng client o sa laman ng network traffic". Kaya maaaring malaman ng control plane kung alin sa iyong mga device ang nag-usap sa isa't isa, at kung kailan. Hindi nito alam kung ano ang sinabi ng mga ito.

Isa lamang sa mga item sa listahang iyon ang tungkol sa encryption. Ang iba ay tungkol sa kung sino ang kabilang at kung ano ang sinasabi ng policy. Kaya ang dapat mong pagtuunan ng pansin ay ang mga control na namamahala sa enrolment.

Ang iyong identity provider ang root of trust ng tailnet

Walang sariling password database ang Tailscale. Malinaw na sinasabi sa documentation nito na walang Tailscale passwords, at ipinagkakatiwala ang sign-in sa isang identity provider (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin, o custom na OpenID Connect provider.

Ituring itong security statement, dahil ganoon nga ito. Ang sinumang makapag-sign in sa iyong Google o Microsoft account ay makapag-sign in din sa iyong tailnet. Ang multi-factor authentication (MFA) mo ay nakabatay sa ipinapatupad ng IdP. Ang offboarding mo ay nakabatay sa ginagawa ng IdP kapag umalis ang isang tao. Ang na-phish na IdP account ay tailnet account na rin, at hindi na kailangang atakehin ng attacker ang WireGuard: magdadagdag lang siya ng device at mamanahin ang anumang policy na ipinagkakaloob sa user na iyon.

Dalawang control ang nasa pagitan ng ninakaw na identity account at gumaganang device sa loob ng iyong tailnet: device approval at key expiry. Pangatlo ang tailnet lock, at nakatuon ito sa control plane sa halip na sa account.

Pag-apruba ng device: walang makakasali hangga't walang taong sumasang-ayon

Inilalarawan ng dokumentasyon ng Tailscale ang pag-apruba ng device bilang feature na “nagbibigay-daan sa mga administrator ng Tailscale network na suriin at aprubahan ang mga bagong device bago sila makasali sa iyong Tailscale network.” Maaaring mag-apruba ang isang Owner, Admin, o IT admin. May badge na “Needs approval” ang bagong device sa page na Machines hanggang sa may gumawa ng aksyon dito.

I-on ito at magbabago ang sitwasyon kapag ninakaw ang account. Nagsa-sign in ang attacker, nagre-register ang device, at pagkatapos ay naghihintay ito nang walang access sa kahit ano. Kasabay nito, may badge sa admin console na nagsasabing may machine na hindi mo nakikilala ang humihiling na makasali. Gumagana pa rin ang automation dahil maaaring itakda ang auth key bilang pre-approved kapag ginagawa ito, at maaaring aprubahan ang mga device sa pamamagitan ng API.

Ang auth keys ang isa pang paraan ng pagpasok, kaya ituring ang mga ito bilang credentials. Direktang nagbababala ang dokumentasyon ng Tailscale tungkol sa mapanganib na uri: “Maging lubhang maingat sa reusable keys! Maaari itong maging lubhang mapanganib kapag nanakaw. Pinakamainam na itago ang mga ito sa isang key vault product na sadyang ginawa para sa layuning ito.” Noong August 2026, ang dokumentadong saklaw ng key expiry ay 1 hanggang 90 araw, at kapag hindi tinukoy ang expiry, awtomatikong ginagamit ang maximum na 90 araw. Mas piliin ang one-off keys, markahan ang mga ito bilang ephemeral para sa mga machine na panandaliang kumokonekta, at panatilihing naka-encrypt gamit ang Ansible Vault ang anumang reusable key o ilagay ito sa isang secrets manager sa halip na sa isang shell script.

Pag-expire ng key: ang timer na naglilimita sa lahat ng iba pang pagkakamali

Nag-e-expire ang mga Node key. Dahil dito, nagiging pansamantalang problema lamang ang nanakaw o nakalimutang device. Ayon sa documentation ng Tailscale, “By default, new domains are set with an expiry period of 180 days,” at “If reauthentication does not occur, keys expire and connections to/from the given endpoint will stop working.” Maaari mong ikaw mismo ang mag-reauthenticate ng isang device:

tailscale up --force-reauth

Nagbabala ang documentation na maaari nitong “might bring down the tailnet connection and thus should not be done remotely over SSH or RDP without an alternate means to log in if the connection is lost.” Isagawa ito habang bukas ang console access, o gamit ang pangalawang path papunta sa machine, dahil maaantala mo ang network na ginagamit mo.

Dito nagiging problema ang control na ito sa mga server. Ang machine na kailangang mag-reauthenticate bawat 180 days ay maaaring mawala sa tailnet nang 3am kapag walang nagbabantay, kaya dini-disable ng mga administrator ang key expiry dito. Inaalis nito ang timer na kalauna’y puputol sa access ng nanakaw na key. Mas magandang solusyon para sa server ang tagged device, dahil tag ang nagmamay-ari sa machine sa halip na isang tao. Kaya mananatiling gumagana ang machine kahit umalis sa kumpanya ang taong iyon. Anuman ang iyong mapagpasyahan, magpanatili ng listahan ng mga machine na naka-disable ang expiry. Mananatiling valid ang mga key na iyon hanggang sa i-delete mo ang device.

Tailnet lock: inaalis ang coordination server sa trust chain

Direktang tinutugunan ng Tailnet lock ang problema sa enrolment. Ipinaliliwanag ng tailnet lock documentation ng Tailscale ang mekanismo: “Kapag may bagong node na sumali sa tailnet, kailangan ng public node key nito ng signature mula sa Tailnet Lock key. Ipinapamahagi ng coordination server ang signed public node key sa mga peer node.” Bine-verify ng mga dati mo nang device ang signature na iyon bago sila tumanggap ng peer, kaya tinatanggihan ang node key na sariling inimbento ng control plane.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

Ina-enable ng tailscale lock init ang feature, at itinatakda mo sa sandaling iyon ang mga signing node. Nangangailangan ang Tailscale ng hindi bababa sa dalawang signing node sa initialisation at nagpapahintulot ng hanggang 20 sa isang tailnet. Pagkatapos nito, kailangan ng bawat bagong device ng signature mula sa isa sa mga ito. May tunay na operational cost ito: ang pagdagdag ng phone ay nangangailangan ng pagpapatakbo ng command sa isang laptop.

Nakadokumento ang mga limitasyon, at mas mahalaga ang mga ito kaysa sa paglalarawan ng feature:

• Kapag nawala ang disablement secret, walang recovery. Sinasabi ng documentation: “Kung mawala ang iyong disablement secrets at wala kang ibinigay na isa sa Tailscale support, hindi mare-recover ang tailnet.”
• Nasa isang device na pagmamay-ari mo ang signing key, kaya minamana nito ang seguridad ng device na iyon. Malinaw ang documentation: “Kung ma-compromise ang device, maaaring makuha ang key.”
• Hindi maaaring gamitin nang sabay ang dalawang control. Sinasabi ng Tailscale na mutually exclusive ang tailnet lock at device approval, kaya kapag in-enable ang isa, isinusuko ang isa pa.
• Trust on first use (TOFU) ito. Dumadaan pa rin sa control plane ang initial setup, at lumilipat lamang sa sarili mong network ang anchor of trust pagkatapos ng unang hakbang.

Pinoprotektahan ng Tailnet lock ang membership. Hindi nito pinoprotektahan ang availability, at malinaw itong sinasabi sa white paper.

Inilalantad ba ng relayed connection ang traffic ko?

Hindi. Kapag hindi direktang maabot ng dalawang device ang isa't isa, dumadaan ang traffic sa isang DERP server (Designated Encrypted Relay for Packets). Malinaw itong ipinapahayag sa dokumentasyon ng Tailscale: “Dahil hindi kailanman umaalis sa lokal na device na gumawa sa mga ito ang Tailscale private keys, imposibleng ma-decrypt ng DERP server ang traffic mo. Blind na ipinapasa ng DERP server ang naka-encrypt na traffic mula sa isang device papunta sa isa pa.”

May kapalit pa ring bilis ang paggamit ng relay, at nakikita nito ang metadata: dalawang naka-encrypt na endpoint, pati ang timing at dami ng traffic na dumadaan sa pagitan ng mga ito. Alamin kung anong uri ng connection ang aktuwal mong ginagamit:

tailscale status
tailscale netcheck

Tinutukoy ng tailscale status ang bawat peer bilang direct, na ipinapakita bilang direct 203.0.113.10:41641, o relayed, na ipinapakita bilang relay na sinusundan ng pangalan ng relay at mga byte counter. Kapag nananatili sa relay ang isang peer, hindi nakabuo ng direct path ang dalawang dulo. Karaniwan itong nangyayari dahil naka-block ang UDP sa isang bahagi ng network o dahil parehong nasa likod ng strict NAT (network address translation) ang dalawang panig. Iniuulat ng tailscale netcheck kung gumagana ang UDP mula sa machine na iyon, kung paano nagma-map ang NAT ng mga port, at kung ano ang latency papunta sa pinakamalapit na relay. Ipinapakita nito kung alin sa dalawang sanhi ang nararanasan mo. Kung direct na ang peer pero mababa pa rin ang throughput, hindi relay ang problema mo, at karaniwang path MTU mismatch ang sanhi ng mabagal na WireGuard.

Inililipat ng exit node ang egress mo; hindi nito inaalis

Niruruta ng exit node ang lahat ng public internet traffic ng isang device sa pamamagitan ng isa pang device sa tailnet, gamit ang default routes na 0.0.0.0/0 at ::/0. Sa Linux, ina-advertise ng machine na nag-aalok ng serbisyo ang exit node, at bawat client ay kusang nag-o-opt in:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Kailangang aprubahan ng isang Owner, Admin, o Network admin sa admin console ang exit node, at dapat payagan ng policy mo ang autogroup:internet bago ito magamit ng client. Sinasadya ang dalawang hakbang na ito: hindi maaaring palihim na maging daanan palabas ng buong tailnet ang isang hindi aprubadong machine. Saklaw din ng parehong approval gate ang subnet routes. Kaya mananatiling hindi aktibo ang machine na nag-a-advertise ng private range hanggang sa tanggapin ito ng admin. Ito ang unang requirement sa pag-advertise ng private network sa iyong tailnet mula sa isang VPS.

Ngayon, tungkol sa trust. Naka-encrypt ang traffic mula sa laptop mo papunta sa exit node. Pagkatapos, umaalis ito sa machine bilang ordinaryong internet traffic at ginagamit ang IP address ng machine na iyon. Kaya nakikita ng operator ng exit node ang mga destination mo. Nakikita rin ito ng hosting provider ng machine at ng upstream network nito. Inilipat mo ang observation point sa halip na alisin ito. Magandang trade-off ito kapag kontrolado mo ang kabilang dulo. Ito ang dahilan para sa pagpapatakbo ng sarili mong exit node sa isang VPS. Hindi ito magandang trade-off kapag hindi mo kontrolado ang kabilang dulo.

Ang default policy ay isang flat network

Ang bagong tailnet ay may permissive na default. Ayon sa access control documentation ng Tailscale, ang default policy file ay “nagpapahintulot ng communication sa pagitan ng lahat ng device sa loob ng tailnet.” Maaaring maabot ng bawat device ang lahat ng iba pang device sa bawat port. Flat network ito. Inilipat mo man ito sa loob ng tunnel, nakatutulong iyon laban sa mga outsider ngunit walang proteksiyon laban sa laptop na ma-infect.

Higpitan ito sa tailnet policy file. Tumatanggap ito ng access control lists (ACLs) o ng mas bagong grants. Pareho itong isinusulat sa isang JSON dialect na nagpapahintulot ng comments:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Pinapayagan ng policy na ito ang isang group na gumamit ng SSH sa mga production server. Pinapayagan din nito ang mga miyembro na gumamit ng exit node. Lahat ng iba pa ay dini-deny dahil walang kaukulang rule. Inililista ng Tailscale kung aling mga rule target ang available sa bawat plan. Suriin muna iyon bago magdisenyo gamit ang tags o autogroups, at tingnan kung ano talaga ang kasama sa free plan. Para sa device na hindi dapat tumanggap kailanman ng mga incoming connection, gaya ng personal phone, bina-block ng tailscale set --shields-up ang mga ito sa client.

Ano ang nagbabago kapag ikaw ang nagho-host ng control plane gamit ang Headscale

Ang Headscale ay “isang open source, self-hosted na implementasyon ng Tailscale control server.” Malinaw na inilalarawan ng README nito ang saklaw: “May makitid itong saklaw, isang single na Tailscale network (tailnet), na angkop para sa personal na paggamit o sa maliit na open-source na organisasyon.” Kasama sa feature list nito ang ACLs at grants, subnet routers, exit nodes, naka-embed na DERP server, Tailscale SSH, at Taildrop. Kung ang makitid na saklaw na ito ang hadlang, ang NetBird ang isa pang mesh na may self-hostable control plane, at ang pagpapatakbo ng NetBird server sa sarili mong VPS ay naglilipat ng parehong desisyon sa enrollment sa hardware na pagmamay-ari mo.

Ang nagbabago ay kung sino ang maaaring mag-enroll ng rogue node. Sa Headscale, nasa server mo ang key directory at policy. Walang third party na humahawak sa listahan ng public key ng mga device mo, at walang third party na maaaring utusang magbigay ng isa o pumirma para rito.

Ang hindi nagbabago ay ang data plane. Ito pa rin ang WireGuard na may parehong end-to-end encryption, pati ang parehong relay fallback kapag imposibleng makabuo ng direct path. Ikaw rin ang sasagot sa mga gawaing dating pinangangasiwaan ng Tailscale: uptime, patching, backups, at physical security ng server. Kung rented VPS ang server na iyon, pangako iyon ng ibang partido sa halip na kontrol mo, dahil maaaring basahin ng hypervisor ang guest memory at pati ang key directory dito, maliban kung may hardware na sumusuporta sa encrypted memory na maaari mong i-attest. Kapag breached ang Headscale host, eksaktong makukuha ng attacker ang mga kakayahang makukuha niya mula sa breached coordination server: ang mag-enrol ng node at mamahagi ng policy. Wala sa feature list ng Headscale ang Tailnet lock, kaya hindi available doon ang compensating control para sa partikular na risk na iyon. Nakaaapekto rin ang gastos sa pagpili ng ilang tailnet, dahil naniningil ang Tailscale batay sa user at hindi sa device at nagbabago ang kalkulasyong iyon kapag lumampas ang maliit na team sa free plan. Kung ang tanong kung sino ang may kontrol ang magpapasya para sa iyo, ipinapaliwanag ng self-hosting ng control plane gamit ang Headscale ang proseso ng setup.

Mga pinoprotektahan ng Tailscale

• Mga public listening port. Ang service na naka-bind sa isang tailnet address ay hindi maaabot mula sa internet, kaya hindi ito makikita ng mga scanner na tumatama sa bawat VPS sa port 22. Ang exception ay iyong kusa mong ina-enable, dahil sadyang inilalathala ng Funnel ang isang tailnet service sa open internet. Kaya mahalagang malaman kung saan nagtatapos ang serve at nagsisimula ang funnel bago mo patakbuhin ang alinmang command. Panatilihin pa rin ang host firewall, dahil gumagawa ng sariling rules ang isang published Docker port at nilalampasan ang ufw sa public interface.
• Paghula ng password laban sa mga exposed login. Walang masi-spray na login kapag sa loob lamang ng tunnel sumasagot ang port. Mas matibay itong posisyon kaysa sa pag-rate limit ng isang open port, bagama't sulit pa ring patakbuhin ang fail2ban sa Ubuntu 24.04 sa anumang kailangang manatiling public.
• Mga hindi pinagkakatiwalaang network sa pagitan. End-to-end na naka-encrypt ang traffic sa pagitan ng iyong mga machine habang dumadaan sa café network o shared provider LAN, at nananatiling encrypted kapag nire-relay ito.
• Manwal na pamamahagi ng key. Ang bawat peer na mano-manong idinadagdag sa WireGuard config ay maaaring pagmulan ng pag-uulit ng address o pag-paste ng maling key. Ang mesh ang gumagawa ng bookkeeping na ito para sa iyo. Ito ang pinakamalaking praktikal na kaibahan sa WireGuard kumpara sa Tailscale.

Mga hindi pinoprotektahan ng Tailscale

• Na-breach na endpoint. Pinagkakatiwalaan ng tailnet ang mga device. Kapag may malware sa aprubadong laptop, makukuha nito ang tunnel, mga address ng tailnet, at anumang access na ibinibigay ng policy sa user na iyon. Ito ang pinakamalaking puwang sa seguridad, at walang VPN ang makapagsasara nito.
• Malisyoso o pabaya na administrator. Ang sinumang maaaring mag-edit ng policy file ay maaaring magbigay sa sarili ng access sa anumang resource. Gayundin ang sinumang makakakuha ng kontrol sa identity account ng isang Owner. Suriin ang mga pagbabago sa policy gaya ng pagsusuri sa code.
• Pagsusuri sa traffic. Nakikita ng iyong ISP (internet service provider) ang naka-encrypt na UDP traffic patungo sa isang endpoint, pati ang timing at volume nito. Nakikita ng flow logs ng Tailscale kung aling mga peer ang nag-usap at kung kailan. Hindi nakikita ng alinman sa mga ito ang laman ng traffic, ngunit hindi nakatago ang mismong koneksyon. Basahin ang pagkakaiba ng Tor at VPN bago pumili ng tool para sa layuning iyon.
• Device na nawala na sa iyo. Mabagal na backup protection ang key expiry, na may default na 180 araw. Mas mabilis ang pag-remove ng device sa admin console. Alamin kung nasaan ang button na iyon bago mo ito kailanganin.

Suriin ang sarili mong tailnet

1. Patakbuhin ang tailscale status sa isang device at basahin ang peer list. Ang machine na hindi mo matukoy ay eksaktong sitwasyong nilalayong pigilan ng device approval.
2. Patakbuhin ang tailscale lock status upang makita kung naka-enable ang tailnet lock, pagkatapos ay magpasya kung sulit para sa iyong tailnet ang gastos ng pag-sign sa bawat bagong device.
3. Buksan ang admin console at itala ang bawat machine na naka-disable ang key expiry, pati ang bawat reusable auth key na umiiral pa. Pareho silang credential na walang timer.
4. Basahin ang policy file. Kung default pa rin ito, maa-access ng bawat device ang lahat ng iba pang device sa bawat port, at maaabot ng isang infected laptop ang lahat ng ito.

Nakukuha ng Tailscale ang reputasyon nito sa data plane, kung saan walang paraan ang disenyo para mabasa ng operator ang iyong traffic. Tanggapin ang claim na iyon ayon sa dokumentasyon ng vendor, pagkatapos ay i-audit ang mga bahaging nasa iyo: ang identity accounts, approval setting, expiry list, at policy file. Iniulat sa security page ng Tailscale ang SOC 2 Type II certification at patuloy na security work kasama ang Latacora. Ebidensiya ito tungkol sa proseso nila, hindi pahayag tungkol sa configuration mo.

FAQ

Mababasa ba ng Tailscale ang traffic ko?

Hindi. Naka-encrypt ang traffic gamit ang mga WireGuard key na ginagawa sa iyong mga device, at sinasabi sa security page ng Tailscale na “Hindi kailanman umaalis sa device ang mga private key. End-to-end encrypted ang lahat ng traffic, palagi.” Saklaw din nito ang mga koneksiyong nagfa-fallback sa DERP relay, dahil ang relay ay “bulag na nagpapasa ng naka-encrypt nang traffic mula sa isang device papunta sa isa pa” at walang hawak na key na magagamit para i-decrypt ito. Ang nakikita ng infrastructure ng Tailscale ay metadata: kung aling mga device ang umiiral, at kung alin sa mga ito ang kumonekta sa iba at kung kailan.

Ano talaga ang maaaring gawin ng isang na-breach na Tailscale coordination server?

Maaari itong mag-enrol ng isang node. Inilalarawan ng sariling tailnet lock announcement ng Tailscale ang panganib ng isang node na lihim na idinagdag at maaaring “magpadala o tumanggap ng traffic papunta sa iyong mga kasalukuyang node,” kung saan hindi nakatutulong ang encryption “dahil maaaring malicious mismo ang peer.” Maaari ring mamahagi ang isang na-breach na control plane ng policy na magbabago sa mga maaabot ng iyong mga device. Binabanggit din sa tailnet lock white paper na maaari nitong sirain ang connectivity sa pamamagitan ng hindi pamamahagi ng mga bagong node key. Ang hindi nito magagawa ay i-decrypt ang traffic sa pagitan ng iyong mga kasalukuyang device, dahil hindi nito kailanman hinawakan ang kanilang mga private key.

Itinatago ba ng exit node ang browsing ko sa ISP ko?

Itinatago nito ang mga destination mula sa network na ginagamit mo, kabilang ang ISP sa bahay o café, dahil umaalis sa iyong device ang lahat bilang naka-encrypt na traffic na nakalaan sa exit node. Hindi ka nito ginagawang anonymous. Sa halip, nakikita ng exit node ang mga destination na iyon. Nakikita rin ang mga ito ng hosting provider at upstream network nito, habang nakikita ng mga site na binibisita mo ang IP address ng exit node. Pinili mo lamang ang ibang observer, kaya pumili ng observer na talagang pinagkakatiwalaan mo.

Mas secure ba ang Headscale kaysa sa coordination server ng Tailscale?

Ibang trust decision ito, hindi awtomatikong mas ligtas na opsyon. Sa Headscale, ikaw ang may hawak ng key directory at policy, kaya walang external party na maaaring piliting mag-enrol ng device sa iyong tailnet. Ikaw rin ang responsable sa pagpapatakbo ng server na iyon: patching, uptime, backups, at seguridad ng host mismo. Kapag na-breach ang Headscale host, magkakaroon ang attacker ng kaparehong kapangyarihang mag-enrol gaya ng isang na-breach na coordination server. Hindi rin kasama ang tailnet lock sa feature list ng Headscale, kaya dapat mong protektahan ang host na iyon nang naaayon.

Kailangan ko pa rin ba ng firewall sa VPS na nasa tailnet ko?

Oo. Umiiral pa rin ang public network interface, at anumang service na naka-bind sa 0.0.0.0 ay mananatiling reachable mula sa internet, tumatakbo man o hindi ang Tailscale. I-bind ang mga service sa tailnet address, panatilihin ang default deny policy sa public interface, at suriin ang mga published container port. Naglalagay ang Docker ng sarili nitong rules at maaari nitong i-expose ang port na inaakala mong sarado.