SSD Nodes Learn 🎉 VPS $5.50/aydan başlayan
Rehberler Matt ConnorYazan Matt Connor · Güncellendi 2026-08-21

Tailscale güvenli mi? Güvenlik modeli ve riskler

Tailscale trafiğinizi şifreleyen anahtarları tutmaz ancak koordinasyon sunucusu ele geçirilirse ağınıza yetkisiz cihazlar eklenebilir. Güven modelini ve riskleri öğrenin.

Tailscale güvenli mi? Kısa cevap

Tailscale güvenli mi? Çoğu kullanıcının endişelendiği kısım için cevap evettir: tailnet ağınızı yöneten koordinasyon sunucusu, trafiğinizi şifreleyen özel anahtarları (private keys) asla tutmaz; bu nedenle cihazlarınızın birbirine gönderdiği verileri okuyamaz. Tailscale'in güvenlik sayfası bunu doğrudan belirtir: "Özel anahtarlar cihazdan asla ayrılmaz. Tüm trafik her zaman uçtan uca şifrelidir." Asıl sorulması gereken soru farklıdır. Ele geçirilmiş veya yasal bir emirle zorlanmış bir koordinasyon sunucusunun paketlerinizi okumasına gerek yoktur. Bu sunucu, cihazlarınızın hangi genel anahtarlara (public keys) güveneceğine karar verir; dolayısıyla onaylamadığınız bir cihazı ağa dahil edebilir.

Güven modeli tek bir cümleyle şöyledir: şifreleme veriyi korur, kontrol düzlemi ise üyeliği belirler. Aşağıdaki her bölüm, güvenmeniz gereken bir tarafı tanımlar, bu tarafın gerçekte neler yapabileceğini açıklar ve onu sınırlayan kontrolleri belirtir. Eğer ürün sizin için yeniyse, Tailscale nedir ve mesh yapısı nasıl çalışır konusundan başlayın.

Kontrol düzlemi ve veri düzlemi birbirinden ayrıdır

Tailscale, kendi kendine barındırılan bir WireGuard VPS üzerinde manuel olarak yapılandıracağınız protokolün aynısı olan WireGuard üzerine inşa edilmiş bir mesh VPN'dir (sanal özel ağ). Her cihaz, kendi WireGuard anahtar çiftini yerel olarak oluşturur. Tailscale'in nasıl çalıştığına dair yazısı, koordinasyon sunucusunu "açık anahtarlar için paylaşımlı bir posta kutusu" olarak tanımlar ve "Özel anahtar, düğümünden asla ve asla dışarı çıkmaz" ifadesini kullanır.

Veri düzlemi, cihazlarınız arasındaki şifreli trafiktir. Ağ izin verdiği sürece doğrudan, cihazdan cihaza ilerler. Kontrol düzlemi ise diğer her şeydir: hangi cihazların tailnet'e ait olduğu, hangi açık anahtarın hangi cihaza ait olduğu, erişim politikası, DNS ayarları ve röle listesi. Tailscale, kontrol düzlemini barındırılan bir servis olarak çalıştırır. Veri düzlemini ise kendi makinelerinizde çalıştırırsınız.

Bu ikisini birbirinden ayrı tuttuğunuzda, buradaki her güvenlik sorusu yanıtlanabilir hale gelir. Şifreleme, veri düzleminin bir özelliğidir. Üyelik ise kontrol düzleminin bir kararıdır. Şifreleme miktarı, size kimin eş (peer) olma iznine sahip olduğunu söylemez.

Ele geçirilmiş bir koordinasyon sunucusu ne yapabilir?

Trafiğinizin şifresini çözemez. Şifreleme işlemini gerçekleştiren anahtarlar cihazlarınızda oluşturulur ve hiçbir zaman karşıya yüklenmez; bu nedenle, tüneli açabilecek ele geçirilecek veya sızdırılacak herhangi bir veri bulunmaz. Bu durum, aşağıda daha ayrıntılı ele alınan aktarılan (relayed) trafik için de geçerlidir.

Bir düğümü sisteme dahil edebilir. Tailscale, tailnet lock özelliğini duyurduğunda, şirketin kendi ifadeleriyle riski şu şekilde tanımlamıştır: kötü niyetli bir sunucu, "mevcut düğümlerinize trafik göndermek veya onlardan trafik almak için gizlice eklenmiş bir düğüm kullanabilir" ve bu noktada "trafiğin şifreli olması bir anlam ifade etmez, çünkü eşin kendisi kötü niyetli olacaktır". Cihazınız, kontrol düzlemi (control plane) o anahtarın tailnet'e ait olduğunu söylediği için bir eşe güvenir.

Cihazlarınızın nelere erişebileceğini değiştirebilir. Erişim politikası kontrol düzleminde barındırılır ve düğümlere dağıtılır. Tailscale'in tailnet lock teknik raporu, tailnet lock özelliğinin "ele geçirilmiş bir kontrol düzleminin ağınızdaki bağlantıyı kesmesini engellemediğini; örneğin yeni düğüm anahtarlarını dağıtmayarak veya tüm düğümlere erişimi reddeden bir erişim kontrol politikası dağıtarak bunu yapabileceğini" belirtmektedir.

Her iki durumda da bağlantı meta verilerini görür. Tailscale ağ akış günlükleri, makineden makineye yapılan her bağlantı için açılış ve kapanış olaylarını kaydeder. Belgeler, bu günlüklerin "kesinlikle istemci işlemleri veya ağ trafiğinin içeriği hakkında hiçbir bilgi içermediğini" belirtir. Dolayısıyla kontrol düzlemi, hangi cihazlarınızın hangisiyle ve ne zaman konuştuğunu bilebilir. Cihazların ne konuştuğunu ise bilemez.

Bu listedeki maddelerden yalnızca biri şifreleme ile ilgilidir. Diğerleri kimin üye olduğu ve politikanın ne dediği ile ilgilidir; bu nedenle dikkatinizi vermeniz gereken kontroller, sisteme dahil etme süreçlerini yöneten kontrollerdir.

Kimlik sağlayıcınız tailnet için güvenin temelidir

Tailscale kendi bünyesinde herhangi bir parola veritabanı tutmaz. Dokümantasyonunda açıkça belirtildiği üzere Tailscale parolaları yoktur ve oturum açma işlemleri bir kimlik sağlayıcısına (IdP) devredilmiştir: Apple, Google, GitHub, Microsoft, Okta, OneLogin veya özel bir OpenID Connect sağlayıcısı.

Bunu bir güvenlik beyanı olarak değerlendirin, çünkü öyledir. Google veya Microsoft hesabınıza giriş yapabilen herkes tailnet ağınıza da giriş yapabilir. Çok faktörlü kimlik doğrulamanız (MFA), IdP tarafından uygulanan yöntemdir. İşten ayrılma süreçleriniz, bir kişi ayrıldığında IdP'nin uyguladığı prosedürlerle aynıdır. Kimlik avına uğramış bir IdP hesabı, doğrudan bir tailnet hesabıdır ve saldırganın WireGuard protokolüne saldırmasına gerek kalmaz: saldırgan bir cihaz ekler ve politikanızın o kullanıcıya tanıdığı tüm yetkileri devralır.

Çalınmış bir kimlik hesabı ile tailnet içinde çalışan bir cihaz arasında iki kontrol mekanizması bulunur: cihaz onayı ve anahtar geçerlilik süresi. Tailnet lock ise üçüncü bir mekanizmadır ve hesaptan ziyade kontrol düzlemini hedef alır.

Cihaz onayı: bir kişi onay vermeden hiçbir cihaz ağa katılamaz

Tailscale belgeleri, cihaz onayını "Tailscale ağ yöneticilerinin, yeni cihazlar Tailscale ağınıza katılmadan önce onları incelemesine ve onaylamasına olanak tanıyan" bir özellik olarak tanımlar. Onay işlemi bir Sahip (Owner), Yönetici (Admin) veya BT yöneticisi tarafından gerçekleştirilebilir. Yeni bir cihaz, birisi işlem yapana kadar Makineler (Machines) sayfasında "Onay gerekiyor" (Needs approval) rozeti ile görüntülenir.

Bu özelliği etkinleştirdiğinizde, çalınmış bir hesap senaryosunun seyri değişir. Saldırgan giriş yapar, cihaz kaydedilir ancak hiçbir yere erişemeden beklemeye geçer; bu sırada yönetici konsolunuzda, tanımadığınız bir makinenin ağa katılmak istediğini belirten bir rozet görünür. Otomasyon süreçleri çalışmaya devam eder; çünkü bir kimlik doğrulama anahtarı (auth key) oluştururken onu önceden onaylanmış (pre-approved) olarak işaretleyebilir ve cihazları API üzerinden onaylayabilirsiniz.

Kimlik doğrulama anahtarları ağa girişin diğer yoludur, bu nedenle onları birer kimlik bilgisi olarak değerlendirin. Tailscale belgeleri, riskli anahtar türleri konusunda oldukça nettir: "Tekrar kullanılabilir anahtarlar konusunda çok dikkatli olun! Bunlar çalındığında çok tehlikeli olabilir. Bu anahtarları, bu amaç için özel olarak tasarlanmış bir anahtar kasası (key vault) ürününde saklamak en iyisidir." Ağustos 2026 itibarıyla belgelenen anahtar geçerlilik süresi 1 ile 90 gün arasındadır ve belirtilmeyen bir son kullanma tarihi varsayılan olarak 90 günlük maksimum süreye ayarlanır. Tek kullanımlık anahtarları tercih edin, gelip geçici makineler için anahtarları geçici (ephemeral) olarak işaretleyin ve tekrar kullanılabilir tüm anahtarları bir shell betiği içinde tutmak yerine Ansible Vault ile şifrelenmiş şekilde veya bir gizli veri yöneticisinde (secrets manager) saklayın.

Anahtar geçerlilik süresi: diğer tüm hataları sınırlayan zamanlayıcı

Node anahtarlarının bir geçerlilik süresi vardır; bu durum, çalınan veya unutulan bir cihazın kalıcı bir güvenlik açığı yerine geçici bir sorun olmasını sağlar. Tailscale belgeleri, "Varsayılan olarak, yeni domainler 180 günlük bir geçerlilik süresi ile ayarlanır" ve "Yeniden kimlik doğrulama gerçekleşmezse, anahtarların süresi dolar ve ilgili uç noktaya/uç noktadan yapılan bağlantılar çalışmayı durdurur" ifadelerini belirtir. Bir cihazın kimlik doğrulamasını kendiniz şu şekilde yenileyebilirsiniz:

tailscale up --force-reauth

Belgeler, bu işlemin "tailnet bağlantısını kesebileceği ve bu nedenle bağlantı koparsa giriş yapmak için alternatif bir yol bulunmadan SSH veya RDP üzerinden uzaktan yapılmaması gerektiği" konusunda uyarıda bulunur. Bu komutu konsol erişimi açıkken veya makineye ikinci bir erişim yolunuz varken çalıştırın; çünkü kullanmakta olduğunuz ağı kesmek üzeresiniz.

Sunucular, bu kontrolün esnetildiği yerlerdir. Her 180 günde bir yeniden kimlik doğrulaması yapması gereken bir makine, kimsenin izlemediği bir saatte (örneğin gece 03:00'te) tailnet'ten düşecektir; bu yüzden yöneticiler sunucularda anahtar geçerlilik süresini devre dışı bırakır. Bu işlem, çalınan bir anahtarı eninde sonunda devre dışı bırakacak olan zamanlayıcıyı ortadan kaldırır. Etiketli (tagged) bir cihaz, sunucular için daha iyi bir çözümdür; çünkü etiket, bir kişiye değil makineye aittir ve bu sayede makine, o kişi şirketten ayrıldığında da çalışmaya devam eder. Kararınız ne olursa olsun, hangi makinelerde geçerlilik süresinin devre dışı bırakıldığının bir listesini tutun: bu anahtarlar siz cihazı silene kadar geçerli kalır.

Tailnet lock: Koordinasyon sunucusunu güven zincirinden çıkarmak

Tailnet lock, kayıt sorununu doğrudan hedefler. Tailscale'in tailnet lock dokümantasyonu mekanizmayı şu şekilde açıklar: "Yeni bir düğüm tailnet'e katıldığında, düğümün genel anahtarı bir Tailnet Lock anahtarından imza gerektirir. Koordinasyon sunucusu, imzalanmış genel düğüm anahtarını eş düğümlere dağıtır." Mevcut cihazlarınız bir eşi kabul etmeden önce bu imzayı doğrular; bu nedenle kontrol düzleminin kendi başına oluşturduğu bir düğüm anahtarı reddedilir.

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

tailscale lock init özelliği etkinleştirir ve bu aşamada imzalayıcı düğümlerinizi belirlersiniz. Tailscale, başlatma sırasında en az iki imzalayıcı düğüm gerektirir ve bir tailnet içinde en fazla 20 düğüme izin verir. Bundan sonra, her yeni cihazın bu düğümlerden birinden imza alması gerekir; bu da gerçek bir operasyonel maliyettir: yeni bir telefon eklemek, bir dizüstü bilgisayarda komut çalıştırmak anlamına gelir.

Sınırlar dokümante edilmiştir ve özellik açıklamasından daha önemlidir:

  • Devre dışı bırakma gizli anahtarını (disablement secret) kaybederseniz kurtarma imkanı yoktur. Dokümantasyon şunu belirtir: "Devre dışı bırakma gizli anahtarlarınızı kaybederseniz ve Tailscale desteğine bir tane sağlamadıysanız, tailnet kurtarılamaz."
  • İmzalama anahtarı sahip olduğunuz bir cihazda yaşar, bu nedenle o cihazın güvenliğini devralır. Dokümantasyon açıktır: "Cihaz ele geçirilirse anahtar elde edilebilir."
  • Her iki kontrolü aynı anda çalıştıramazsınız. Tailscale, tailnet lock ve cihaz onayının (device approval) birbirini dışladığını belirtir, bu nedenle birini etkinleştirmek diğerinden vazgeçmek anlamına gelir.
  • Bu, ilk kullanımda güven (TOFU) prensibidir. İlk kurulum hala kontrol düzlemi üzerinden geçer ve güven çıpası ancak bu ilk adımdan sonra kendi ağınıza taşınır.

Tailnet lock üyeliği korur. Erişilebilirliği korumaz ve teknik inceleme (white paper) bunu açıkça belirtir.

Aktarılan bir bağlantı trafiğimi açığa çıkarır mı?

Hayır. İki cihaz birbirine doğrudan ulaşamadığında trafik, bir DERP (Designated Encrypted Relay for Packets) sunucusuna aktarılır. Tailscale belgeleri bu durumu net bir şekilde belirtir: "Tailscale özel anahtarları (private keys) onları oluşturan yerel cihazdan asla ayrılmadığı için, bir DERP sunucusunun trafiğinizin şifresini çözmesi imkansızdır. Bir DERP sunucusu, halihazırda şifrelenmiş trafiği bir cihazdan diğerine körü körüne iletir."

Aktarma (relay) kullanımı hızınızı düşürür ve meta verileri gözlemler: iki şifreli uç nokta ile aralarında geçen trafiğin zamanlaması ve hacmi. Hangi tür bağlantıya sahip olduğunuzu şu şekilde öğrenebilirsiniz:

tailscale status
tailscale netcheck

tailscale status, her eşi (peer) ya doğrudan bağlantı olarak (direct 203.0.113.10:41641 şeklinde yazılır) ya da aktarılan bağlantı olarak (relay ve ardından aktarıcı adı ve bayt sayaçları ile yazılır) işaretler. Bir eşin sürekli aktarma üzerinden bağlı kalması, iki uç noktanın doğrudan bir yol oluşturamadığı anlamına gelir; bu durum genellikle UDP'nin bir noktada engellenmesinden veya her iki tarafın da katı bir NAT (network address translation) arkasında bulunmasından kaynaklanır. tailscale netcheck, o makinede UDP'nin çalışıp çalışmadığını, NAT'ınızın portları nasıl eşlediğini ve en yakın aktarıcılara olan gecikme süresini raporlar; bu veriler, bahsi geçen iki nedenden hangisiyle karşı karşıya olduğunuzu anlamanızı sağlar.

Bir exit node çıkış noktanızı değiştirir, ancak trafiği ortadan kaldırmaz

Bir exit node, bir cihazın tüm genel internet trafiğini tailnet üzerindeki başka bir cihaz üzerinden, 0.0.0.0/0 ve ::/0 varsayılan rotalarını kullanarak yönlendirir. Linux üzerinde bu hizmeti sunan makine söz konusu özelliği duyurur ve her istemci bunu kullanmayı tercih eder:

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=

Bir exit node, yönetici konsolunda bir Sahip, Yönetici veya Ağ yöneticisi tarafından onaylanmalıdır ve bir istemcinin onu kullanabilmesi için politikanızın autogroup:internet iznini vermesi gerekir. Her iki adım da kasıtlıdır: onaylanmamış bir makine, tüm tailnet ağınızın çıkış yolu haline sessizce gelemez.

Şimdi güven konusuna gelelim. Trafik, dizüstü bilgisayarınızdan exit node cihazına kadar şifrelenir. Ardından bu makineden, o makinenin IP adresini taşıyan sıradan internet trafiği olarak çıkar. Dolayısıyla exit node operatörü, o makinenin barındırma sağlayıcısı ve üst ağ sağlayıcısı, hedeflediğiniz adresleri görebilir. Gözlem noktasını silmek yerine yerini değiştirmiş olursunuz. Uç noktayı kontrol ettiğiniz durumlarda bu iyi bir takastır; kendi VPS'iniz üzerinde exit node çalıştırmanın temel mantığı budur. Kontrolün sizde olmadığı durumlarda ise bu zayıf bir tercihtir.

Varsayılan politika düz bir ağ yapısıdır

Yeni bir tailnet, izin verici bir yapılandırmayla gelir. Tailscale erişim kontrolü belgeleri, varsayılan politika dosyasının "tailnet içindeki tüm cihazlar arasında iletişimi etkinleştirdiğini" belirtir. Her cihaz, diğer tüm cihazlara her port üzerinden erişebilir. Bu, düz bir ağ yapısıdır. Ağı tünel içine taşımanız, dışarıdan gelen saldırılara karşı koruma sağlar ancak enfekte olmuş bir dizüstü bilgisayara karşı hiçbir şey yapmaz.

Bu durumu, yorum satırlarına izin veren bir JSON lehçesiyle yazılan erişim kontrol listelerini (ACL) veya daha yeni olan "grants" yapısını kabul eden tailnet politika dosyasında sıkılaştırın:

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

Bu politika, bir grubun üretim sunucularında SSH erişimi sağlamasına, üyelerin bir çıkış düğümü (exit node) kullanmasına izin verir ve geri kalan her şeyi varsayılan olarak reddeder. Tailscale, hangi kural hedeflerinin hangi planda mevcut olduğunu listeler; bu nedenle etiketler (tags) veya otomatik gruplar (autogroups) üzerinden tasarım yapmadan önce bunu kontrol edin ve ücretsiz planın neleri kapsadığına bakın. Kişisel bir telefon gibi hiçbir gelen bağlantıyı asla kabul etmemesi gereken bir cihaz için tailscale set --shields-up, bu bağlantıları istemci tarafında engeller.

Headscale ile kontrol düzlemini kendi sunucunuzda barındırmanın getirdiği değişiklikler

Headscale, "Tailscale kontrol sunucusunun açık kaynaklı ve kendi kendine barındırılan bir uygulamasıdır." README dosyası kapsamı dürüstçe belirtir: "Kişisel kullanım veya küçük bir açık kaynaklı organizasyon için uygun olan, tek bir Tailscale ağı (tailnet) ile sınırlı dar bir kapsam uygular." Özellik listesi; ACL'leri ve yetkilendirmeleri, alt ağ yönlendiricilerini (subnet routers), çıkış düğümlerini (exit nodes), gömülü bir DERP sunucusunu, Tailscale SSH'i ve Taildrop'u kapsar. Eğer bu dar kapsam bir engel teşkil ediyorsa, NetBird kendi kendine barındırılabilir bir kontrol düzlemi sunan diğer mesh ağıdır ve NetBird sunucusunu kendi VPS'inizde çalıştırmak, aynı kayıt kararını kendi donanımınıza taşımanızı sağlar.

Değişen şey, sisteme yetkisiz bir düğüm kaydedebilecek tarafın kimliğidir. Headscale ile anahtar dizini ve politika sizin sunucunuzda barınır. Hiçbir üçüncü taraf cihazlarınızın genel anahtar listesini tutmaz ve hiçbir üçüncü taraf bu listeyi teslim etmeye veya bir anahtarı imzalamaya zorlanamaz.

Değişmeyen şey ise veri düzlemidir. Uçtan uca şifrelemeye sahip aynı WireGuard protokolü ve doğrudan yolun mümkün olmadığı durumlarda devreye giren aynı röle yedekleme mekanizması kullanılmaya devam eder. Ayrıca Tailscale'in üstlendiği çalışma süresi, yama yönetimi, yedekleme ve sunucunun fiziksel güvenliği gibi sorumlulukları da devralırsınız. Güvenliği ihlal edilmiş bir Headscale sunucusu, bir saldırgana tam olarak güvenliği ihlal edilmiş bir koordinasyon sunucusunun vereceği yetkileri sağlar; yani bir düğümü kaydetme ve politika dağıtma gücü. Tailnet lock, Headscale özellik listesinde yer almadığından, bu özel risk için telafi edici kontrol burada mevcut değildir. Eğer sahiplik sorunu sizin için belirleyici faktörse, Headscale ile kontrol düzlemini kendi sunucunuzda barındırmak rehberi kurulum adımlarını açıklar.

Tailscale neye karşı koruma sağlar

  • İnternete açık dinleme portları. Bir tailnet adresine bağlı servis, internet üzerinden erişilebilir değildir; bu nedenle her VPS'in 22 numaralı portunu tarayan botlar bu servisi asla göremez. Bunun tek istisnası, bizzat sizin etkinleştirdiğiniz durumdur; çünkü Funnel, bir tailnet servisini kasıtlı olarak açık internete yayınlar. Bu yüzden, her iki komutu da çalıştırmadan önce serve ile funnel arasındaki farkı bilmek önemlidir. Yine de sunucu güvenlik duvarını aktif tutun; çünkü yayınlanan bir Docker portu kendi kurallarını yazar ve genel arayüzdeki ufw'yi devre dışı bırakır.
  • Açık girişlere yönelik parola tahmin saldırıları. Port yalnızca tünel içinden yanıt verdiğinde, saldırganın deneyebileceği bir hedef kalmaz. Bu, açık bir portu hız sınırlaması (rate limiting) ile korumaktan daha güçlü bir yöntemdir; ancak yine de halka açık kalması gereken her şeyde Ubuntu 24.04 üzerinde fail2ban çalıştırmak faydalıdır.
  • Yol üzerindeki güvenilmeyen ağlar. Makineleriniz arasındaki trafik, bir kafe ağı veya paylaşımlı bir sağlayıcı LAN'ı üzerinden uçtan uca şifrelenir ve aktarım sırasında da şifreli kalmaya devam eder.
  • Elle yönetilen anahtar dağıtımı. WireGuard yapılandırmasına elle eklenen her eş, bir adresin yeniden kullanılması veya yanlış anahtarın yapıştırılması riskini taşır. Mesh yapısı bu kayıt tutma işlemini sizin yerinize yapar; WireGuard ve Tailscale karşılaştırması arasındaki pratik farkın büyük kısmı da budur.

Tailscale'in koruma sağlamadığı durumlar

  • Ele geçirilmiş bir uç nokta. Tailnet, cihazlara güven duyar. Onaylı bir dizüstü bilgisayardaki kötü amaçlı yazılım, tünele, tailnet adreslerine ve politikanızın o kullanıcıya tanıdığı tüm yetkilere erişim sağlar. Bu en büyük güvenlik açığıdır ve hiçbir VPN bunu kapatamaz.
  • Kötü niyetli veya dikkatsiz bir yönetici. Politika dosyasını düzenleyebilen herkes kendisine her şeye erişim izni verebilir; bir Owner hesabının kimliğini ele geçiren herkes de aynı şeyi yapabilir. Politika değişikliklerini, kod değişikliklerini incelediğiniz gibi inceleyin.
  • Trafik analizi. ISP'niz (internet servis sağlayıcınız), bir uç noktaya akan şifreli UDP trafiğini, ayrıca zamanlamayı ve veri hacmini görür. Tailscale akış günlükleri, hangi eşlerin ne zaman iletişim kurduğunu kaydeder. İkisi de içeriği göremez ancak bağlantının varlığı gizli değildir; bu nedenle bu tür bir iş için araç seçmeden önce Tor ve VPN arasındaki farklar konusunu okuyun.
  • Zaten kaybetmiş olduğunuz bir cihaz. Anahtar geçerlilik süresi, varsayılan olarak 180 günde bir gerçekleşen yavaş bir güvenlik önlemidir. Yönetici konsolundan cihazı kaldırmak ise hızlı çözümdür; bu yüzden ihtiyaç duymadan önce o düğmenin nerede olduğunu öğrenin.

Kendi tailnet ağınızı denetleyin

  1. Bir cihaz üzerinde tailscale status komutunu çalıştırın ve eş listesini okuyun. İsimlendiremediğiniz bir makine, cihaz onaylama özelliğinin önlemeyi amaçladığı durumun ta kendisidir.
  2. Tailnet kilidinin etkin olup olmadığını görmek için tailscale lock status komutunu çalıştırın, ardından her yeni cihazı imzalamanın getirdiği operasyonel yükün tailnet ağınız için buna değip değmeyeceğine karar verin.
  3. Yönetim konsolunu açın ve anahtar süresi dolumu devre dışı bırakılmış tüm makineleri, ayrıca hala geçerli olan tüm yeniden kullanılabilir kimlik doğrulama anahtarlarını not edin. Her ikisi de zamanlayıcısı olmayan kimlik bilgileridir.
  4. Politika dosyanızı okuyun. Eğer hala varsayılan ayarlardaysa, her cihaz diğer tüm cihazlara her port üzerinden erişebilir; bu da enfekte olmuş tek bir dizüstü bilgisayarın hepsine ulaşabileceği anlamına gelir.

Tailscale, tasarım gereği operatörün trafiğinizi okumasına imkan tanımayan veri düzlemi mimarisiyle itibar kazanmıştır. Bu iddiayı satıcının belgelediği şekilde kabul edin ve ardından size ait olan kısımları denetleyin: kimlik hesapları, onay ayarı, süre dolum listesi ve politika dosyası. Tailscale'in güvenlik sayfası, SOC 2 Type II sertifikasını ve Latacora ile yürütülen sürekli güvenlik çalışmalarını raporlar; bu, sizin yapılandırmanız hakkında bir beyandan ziyade, firmanın kendi süreçleri hakkında bir kanıttır.

FAQ

Tailscale trafiğimi okuyabilir mi?

Hayır. Trafik, cihazlarınızda oluşturulan WireGuard anahtarlarıyla şifrelenir ve Tailscale'in güvenlik sayfasında "Özel anahtarlar cihazdan asla ayrılmaz. Tüm trafik her zaman uçtan uca şifrelidir" ifadesi yer alır. Bu durum, bir DERP aktarıcısına (relay) düşen bağlantılar için de geçerlidir; çünkü aktarıcı, "zaten şifrelenmiş trafiği bir cihazdan diğerine körü körüne iletir" ve şifre çözmeyi sağlayacak hiçbir anahtarı elinde tutmaz. Tailscale altyapısının gördüğü tek şey meta verilerdir: hangi cihazların var olduğu ve bunların hangisinin hangisiyle ne zaman bağlantı kurduğu.

Ele geçirilmiş bir Tailscale koordinasyon sunucusu gerçekte ne yapabilir?

Bir düğümü (node) sisteme dahil edebilir. Tailscale'in kendi tailnet lock duyurusu, "mevcut düğümlerinize trafik gönderebilecek veya onlardan trafik alabilecek" gizlice eklenmiş bir düğüm riskini tanımlar; bu durumda şifreleme yardımcı olmaz, "çünkü eşin kendisi kötü niyetli olacaktır". Ele geçirilmiş bir kontrol düzlemi, cihazlarınızın erişebileceği yerleri değiştiren bir politika dağıtabilir ve tailnet lock teknik raporu, yeni düğüm anahtarlarını dağıtmayarak bağlantıyı kesebileceğini belirtir. Yapamayacağı şey ise mevcut cihazlarınız arasındaki trafiğin şifresini çözmektir, çünkü cihazlarınızın özel anahtarlarına hiçbir zaman sahip olmamıştır.

Bir çıkış düğümü (exit node), tarama geçmişimi ISS'imden gizler mi?

Cihazınızdan çıkan her şey çıkış düğümüne yönelik şifreli trafik olarak gittiği için, evinizdeki veya bir kafedeki ISS dahil olmak üzere bulunduğunuz ağdan hedefleri gizler. Bu sizi anonim yapmaz. Bunun yerine hedefleri çıkış düğümü, onun barındırma sağlayıcısı ve üst ağları görür; ziyaret ettiğiniz siteler ise çıkış düğümünün IP adresini görür. Farklı bir gözlemci seçmiş olursunuz, bu yüzden gerçekten güvendiğiniz birini seçin.

Headscale, Tailscale'in koordinasyon sunucusundan daha mı güvenlidir?

Bu kesinlikle daha güvenli olmaktan ziyade farklı bir güven kararıdır. Headscale ile anahtar dizini ve politikayı siz tutarsınız, böylece hiçbir dış taraf tailnet'inize zorla cihaz ekleyemez. Ayrıca o sunucuyu çalıştırma sorumluluğunu da üstlenirsiniz: yamalar, çalışma süresi, yedeklemeler ve ana bilgisayarın kendi güvenliği. Ele geçirilmiş bir Headscale ana bilgisayarı, bir saldırgana ele geçirilmiş bir koordinasyon sunucusunun sahip olacağı aynı ekleme yetkisini sunar ve tailnet lock, Headscale'in özellik listesinde yer almaz; bu nedenle o ana bilgisayarı buna göre koruyun.

Tailnet'imdeki bir VPS üzerinde hala güvenlik duvarına ihtiyacım var mı?

Evet. Genel ağ arayüzü hala mevcuttur ve 0.0.0.0 adresine bağlı herhangi bir servis, Tailscale çalışsa da çalışmasa da internetten erişilebilir kalır. Servisleri tailnet adresine bağlayın, genel arayüzde varsayılan olarak reddetme (default deny) politikası uygulayın ve yayınlanan container portlarınızı kontrol edin; çünkü Docker kendi kurallarını ekler ve kapalı olduğunu düşündüğünüz bir portu dışarıya açabilir.