Tailscale nedir ve mesh VPN yapısı nasıl çalışır?

Tailscale nedir?

Tailscale, tüm trafiği çalıştırdığınız tek bir ağ geçidi üzerinden yönlendirmek yerine, makinelerinizi doğrudan birbirine bağlayan bir VPN çözümüdür. Her düğüm WireGuard çalıştırır; bu sayede paketler bir sunucudan diğerine şifrelenmiş olarak iletilir ve yol üzerindeki hiçbir yapı bunları okuyamaz. Barındırılan bir koordinasyon sunucusu, düğümler arasındaki bağlantıyı yönetir. Bu sunucu, genel anahtarları depolar, dağıtır ve her düğüme diğerlerinin nerede olduğunu bildirir. Ayrıca, tanımladığınız erişim kurallarını düğümlere iletir.

Tüm tasarım bu ayrım üzerine kuruludur. Veri düzlemi uçtan uca (peer to peer) ve düğümler arasında şifrelidir. Kontrol düzlemi ise Tailscale tarafından sizin için çalıştırılan bir servistir. Tailscale ile ilgili güvene dair hassas konular da dahil olmak üzere tüm önemli sorular, bu iki temel gerçeğe dayanır. Eğer daha önce bir VPS üzerinde manuel olarak WireGuard VPN kurduysanız, Tailscale'in sunduğu yapı; anahtar dağıtımı ve güvenlik duvarı geçişi süreçlerinin sizin yerinize otomatikleştirildiği aynı tünel mantığıdır.

Tailscale nasıl çalışır?

Düğümlerden oluşan özel ağınıza tailnet adı verilir. Bir makine bu ağa katıldığında dört temel işlem gerçekleşir.

1. tailscaled daemon'ı başlar, bir WireGuard anahtar çifti oluşturur ve durumunu /var/lib/tailscale/tailscaled.state içinde tutar. Özel anahtar (private key) makinede kalır. Tailscale'in kendi ifadesi nettir: "özel anahtar hiçbir zaman, hiçbir koşulda düğümünden dışarı çıkmaz."
2. Düğüm, koordinasyon sunucusuna giriş yapar ve kendi genel anahtarını (public key) ve erişilebilir olduğunu düşündüğü adresleri yükler. Tailscale bu sunucuyu "genel anahtarlar için paylaşımlı bir posta kutusu" olarak tanımlar.
3. Koordinasyon sunucusu bir ağ haritası gönderir: bu düğümün erişmesine izin verilen her düğümün genel anahtarı, tailnet adresi, makine adı ve aday uç noktaları.
4. Ardından her düğüm çifti, kendi aralarında doğrudan bir WireGuard tüneli kurmaya çalışır. Bu işlem başarısız olduğunda, paketleri bir aktarıcı (relay) üzerinden iletirler.

Her düğüm, 100.64.0.0 ile 100.127.255.255 aralığında yer alan ve taşıyıcı sınıfı NAT (carrier-grade NAT) olarak bilinen 100.64.0.0/10 bloğundan sabit bir adres alır. Tailscale bu aralığı kullanır çünkü bu aralık servis sağlayıcı altyapısı için ayrılmıştır; dolayısıyla sunucularınızın halihazırda kullandığı özel adreslerle çakışma olasılığı düşüktür. Linux üzerinde tünel, tailscale0 adında bir arayüz olarak görünür.

WireGuard uygulaması çekirdek modülünde değil, kullanıcı alanında (userspace) tailscaled içinde çalışır. Bu nedenle Tailscale, sudo modprobe wireguard'nin Operation not supported hatasıyla başarısız olduğu konteyner sanallaştırma ortamlarında çalışabilir. Bu durum aynı zamanda, belirli bir makinedeki verim sınırının çekirdek tabanlı WireGuard'dan daha düşük olduğu anlamına gelir; Tailscale ile standart WireGuard karşılaştırması bölümünde bu ödünleşimlerden bahsedilmektedir.

Durumunuzu anlamanızı sağlayan iki komut mevcuttur.

tailscale ip -4
tailscale status

tailscale status komutu her düğüm için bir satır çıktı verir; burada önemli olan son sütundur.

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 komutunu bir adres ve port ile kullanmak, iki makinenin birbirine giden bir yol bulduğunu ve trafiğin eşten eşe (peer to peer) olduğunu gösterir. relay "fra" ifadesi, trafiğin Frankfurt'taki bir Tailscale aktarıcısı üzerinden geçtiği anlamına gelir. - ifadesi ise o düğümle şu an aktif bir oturum olmadığını belirtir ki bu normal bir durumdur.

Koordinasyon sunucusunun görebildikleri ve göremedikleri

Koordinasyon sunucusu, genel anahtarları ve meta verileri tutar. Makine adlarınızı, her düğümün hangi kullanıcıya veya etikete ait olduğunu, her düğümün tailnet adresini, düğümlerinize ulaşılabilecek genel adresleri, her birinin en son ne zaman çevrimiçi olduğunu ve yazdığınız politika dosyasını bilir. Bu, ağınızdaki tüm cihazların tam bir haritasıdır.

Sunucu hiçbir özel anahtarı tutmaz, bu nedenle iki düğüm arasındaki trafiğin şifresini çözemez. Şifreleme, WireGuard eşleri arasında uçtan uca yapılır ve koordinasyon sunucusu bir eş değildir.

Sunucunun yapabildiği şey anahtar dağıtmaktır. Barındırılan veya kendi kurduğunuz herhangi bir koordinasyon sunucusu, düğümlerinize hangi genel anahtarların tailnet'e ait olduğunu söyleme konusunda yetkilidir. Bu durum, aşağıda açıklanan tehdit modelinin temelini oluşturur ve kendi sunucunuzda barındırabileceğiniz açık kaynaklı bir koordinasyon sunucusu olan Headscale projesinin var olma nedenidir.

Farklı güvenlik duvarları arkasındaki iki sunucunun doğrudan haberleşmesi

NAT (ağ adresi çevirisi), birçok makinenin tek bir genel IP adresini paylaşmasını sağlar. VPS sunucunuz genellikle kendine ait bir genel adrese sahiptir, ancak tailnet ağına dahil etmek istediğiniz diğer makineler (ev sunucusu, ofis ağındaki bir derleme sunucusu veya düzenleyemediğiniz bir servis sağlayıcı güvenlik duvarı arkasındaki cihaz) genellikle bu özelliğe sahip değildir.

Tailscale, STUN (NAT için oturum geçiş yardımcı programları) ve ICE standartları üzerine kurulu teknikleri kullanarak bir yol bulur. Her düğüm, bir STUN sunucusuna küçük bir UDP paketi gönderir ve yönlendiricisinin bu sokete atadığı genel adresi ve portu öğrenir. Her iki düğüm de bu adayları koordinasyon sunucusuna bildirir; sunucu da bu bilgileri karşı tarafa iletir. Ardından her iki düğüm aynı anda birbirine paket göndermeye başlar. Her yönlendirici önce giden bir paket görür, bu sayede bir eşleme oluşturur ve aynı adresten gelen yanıtı kabul eder. Hiçbir tarafın gelen bağlantı için güvenlik duvarı kuralı oluşturmasına gerek kalmaz. Evdeki bir NAS cihazının veya Raspberry Pi'nin yönlendiricinizde port yönlendirme yapmadan erişilebilir kalmasının nedeni budur; port yönlendirme yerine Tailscale kullanmak başlıklı rehber, bu kurulumun nasıl yapılacağını ve neleri yapamayacağını açıklamaktadır.

Portlar belirli bir yapıya sahiptir. Doğrudan WireGuard tünelleri, varsayılan olarak 41641 kaynak portunu kullanan UDP protokolünü kullanır. STUN, Tailscale'in röle sunucularına UDP 3478 üzerinden erişir. Kontrol bağlantısı, Tailscale'in kendi şifreli taşıma katmanı ile sarmalanmış TCP 80 üzerindeki düz HTTP protokolünü tercih eder; 80 numaralı port yanıt vermediğinde TCP 443 üzerinden HTTPS'e geri döner. Tailscale'in DERP sunucuları üzerinden aktarılan veriler TCP 443 üzerinde HTTPS kullanırken, kendi tailnet ağınız içinde çalıştırdığınız bir eş röle (peer relay) veriyi UDP üzerinden taşır. Çoğu durumda gelen bağlantı için herhangi bir port açmanız gerekmez; ancak kısıtlayıcı bir NAT yapısına sahip ağlarda, UDP 41641 portuna gelen trafiğe izin vermek doğrudan bağlantı olasılığını artırır.

tailscale netcheck

Bu raporun iki satırını inceleyin. UDP: true, bu makinenin internete UDP paketi gönderebildiği anlamına gelir; UDP: false ise gönderemediği anlamına gelir, bu durumda bu düğümden yapılan her bağlantı röle üzerinden aktarılır. MappingVariesByDestIP: true, yönlendiricinin her hedef için farklı bir genel port atadığı anlamına gelir; bu durumda yukarıda bahsedilen adres tahmini çalışmaz ve bu düğümler genellikle röle üzerinden haberleşmeye devam eder.

Tailscale bir DERP rölesi kullandığında

DERP (designated encrypted relay for packets), yedekleme mekanizmasıdır. Tailscale, TCP 443 üzerinden erişilebilen birçok bölgede röleler çalıştırır; doğrudan yol bulamayan bir düğüm, WireGuard paketlerini bu rölelerden biri üzerinden gönderir. İstisna durum, trafiği UDP üzerinden ileten kendi cihazlarınız olan özel eş rölelerine sahip olduğunuz bir tailnet ağıdır. Tailscale önce bunları dener ve yalnızca hiçbiri uygun olmadığında DERP'e geri döner; bu durumda tailscale status bağlantıyı peer-relay olarak gösterir.

Paketler şifreli kalır. Tailscale bunu açıkça belirtir: "Bir DERP sunucusunun trafiğinizin şifresini çözmesinin hiçbir yolu yoktur. Sadece halihazırda şifrelenmiş trafiği bir düğümden diğerine körü körüne iletir." Bir röle yalnızca şifreli metni ve hangi düğümün hangisiyle konuştuğunu görür.

Röleler ayrıca çoğu bağlantının ilk paketlerini de taşır. Doğrudan bir yol bulmak zaman aldığından, bir oturum genellikle röle üzerinden başlar ve iki düğüm birbirini bulduğunda doğrudan bağlantıya yükseltilir. Bu süreci izleyebilirsiniz.

tailscale ping db-1

İlk yanıtlar via DERP(fra) olarak gelir, ardından sonraki bir satır via 198.51.100.24:41641 gibi bir rapor sunar. Bu değişim, doğrudan tünele yükseltmedir. Eğer bu değişim hiç gerçekleşmiyorsa, her iki uçta da tailscale netcheck komutunu çalıştırın. Röleli bir yol yine de çalışır. Ancak her paket üçüncü bir makine üzerinden dolambaçlı bir yol izlediği için gecikmeye neden olur. Eğer fark ettiğiniz şey kopuk bir bağlantıdan ziyade yavaş aktarımlarsa, Tailscale bağlantısının doğrudan bağlantıya göre neden çok daha yavaş olduğu başlıklı yazı aradaki farkı ölçer ve bir VPS'i doğrudan yola nasıl dahil edeceğinizi gösterir.

Bir VPS'i tailnet'inize dahil etme

Kurulum betiği Ubuntu ve Debian dağıtımlarını destekler.

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

sudo tailscale up bir URL çıktısı verir. Bu URL'yi açıp kimlik doğrulaması yaptığınızda düğüm, yönetim konsolunuzda görünür hale gelir. Ardından, kullanıcıların sıklıkla atladığı bir adım olan daemon'ın yeniden başlatma sonrasında otomatik olarak ayağa kalktığını doğrulayın.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled komutu enabled çıktısını vermeli ve tailscale status komutu yeni düğümü 100.x adresiyle listelemelidir. Bir betik üzerinden oluşturulan sunucularda etkileşimli URL kullanımı pratik değildir. Yönetim konsolundan bir kimlik doğrulama anahtarı (auth key) oluşturun ve bu makinenin türünü belirten bir etiket (tag) ile birlikte kullanın.

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

Etiketli bir düğüm, komutu çalıştıran kişiye değil etikete aittir; bu sayede ilgili kişinin hesabı silinse bile düğüm çalışmaya devam eder. Etiket, komutun reddedilmemesi için öncelikle politika dosyanızda tagOwners altında tanımlanmalıdır. Etiketleme, makinenin planınızdaki kota kullanımını da değiştirir; etiketli kaynaklar kişisel cihazlardan ayrı olarak fiyatlandırılır ve ücretsiz katmanın neleri kapsadığı bu sınırların nerede olduğunu açıklar.

Bir filo yönetimi için iki ayar önemlidir. Düğüm anahtarları varsayılan olarak 180 gün sonra sona erer (Ekim 2026 itibarıyla) ve anahtar süresi dolduğunda, cihaz yeniden kimlik doğrulaması yapana kadar "ilgili uç noktaya/uç noktadan yapılan bağlantılar çalışmayı durdurur". Bir yönetici, yönetim konsolu üzerinden süresi dolmuş bir makinede "Temporarily extend key" seçeneğini kullanarak yeniden giriş yapmak veya süreyi devre dışı bırakmak için 30 dakika kazanabilir. Yukarıdaki gibi bir etiketle kimlik doğrulaması yapılmış düğümlerde anahtar süresi varsayılan olarak devre dışıdır. Diğer tüm katılımsız sunucular için yönetim konsolunda makinenin satırını açın ve "Disable Key Expiry" seçeneğini seçin. 20 Ekim 2022 tarihinde veya sonrasında oluşturulan tailnet'lerde varsayılan olarak etkin gelen MagicDNS, her düğüme db-1.yak-bebop.ts.net gibi bir isim verir ve bu isim 100.100.100.100 adresindeki bir stub resolver tarafından çözümlenir. Adresler yerine bu isimleri kullanın; çünkü yeniden oluşturulan bir düğüm yeni bir adres alsa da ismini korur.

Kurulumun kendisi apt veya depo kaynaklı bir hata verirse, Ubuntu üzerinde sık karşılaşılan Tailscale kurulum hataları bölümü çözüm yollarını içerir.

Localhost adresine bağlı bir servise erişim

Tailnet'in kullanışlı olduğu ve insanların takıldığı nokta burasıdır. Bir tailnet'e katılmak, loopback adresine bağlı bir servisi erişilebilir kılmaz.

ss -tlnp | grep 3000

Eğer bu komut 127.0.0.1:3000 çıktısını veriyorsa, soket yalnızca hedefi 127.0.0.1 olan paketleri kabul ediyor demektir. Başka bir düğümden gelen istek, bu düğümün 100.x adresine yönlendirilir; bu nedenle çekirdek, istek için dinleme yapan bir süreç bulamaz ve TCP reset ile yanıt verir. İstemci Connection refused hatasını bildirir. Tünel düzgündür. Sorun, dinleyici yapılandırmasındadır. Aynı karışıklık ev medya sunucularında da sık görülür: Jellyfin'e evdeki diğer cihazlardan ve dışarıdan erişim rehberi, localhost adresinin neden yalnızca aynı bilgisayarı kapsadığını açıklar ve sunucuyu önce ev ağına, ardından CGNAT arkasından internete güvenli biçimde nasıl açacağınızı adım adım gösterir.

İki geçerli çözüm yolu mevcuttur. Servisi düğümün tailnet adresine bağlayın; bu, servisi herhangi bir proxy olmadan genel arayüzden uzak tutar: --bind 100.101.102.104 parametresini veya yapılandırmanızdaki eşdeğer seçeneği kullanın, container için ise portu -p 100.101.102.104:3000:3000 olarak yayınlayın. Alternatif olarak, servisi loopback üzerinde bırakın ve önüne Tailscale yerleştirin.

tailscale serve 3000

Bu yöntem, istekleri http://127.0.0.1:3000 adresine proxy eder ve tailnet içerisinde, HTTPS sertifikaları etkinleştirildiğinde ts.net ismi üzerinden HTTPS ile sunar. Bu yapı yalnızca sizin düğümlerinize özel kalır. Aynı mantığın genel ağa açık versiyonu Funnel'dır ve Tailscale serve ve funnel kullanımı rehberi, hangisine ihtiyacınız olduğunu açıklar.

İki ilgili görev için ayrı sayfalar mevcuttur. Üzerinde Tailscale kurulu olmayan özel bir ağın tamamına erişmek için VPS üzerinde subnet router kurulumu, bir düğümün giden internet trafiğini başka bir düğüm üzerinden geçirmek için ise exit node kullanımı gereklidir.

Artık ihtiyaç duymadığınız portları kapatma

Her yönetici sunucuya tailnet üzerinden erişebildiğinde, 22 numaralı genel portun bir işlevi kalmaz. Pratik kazanç şudur: kapalı bir porta kaba kuvvet (brute force) saldırısı yapılamaz ve loglarınız artık başarısız giriş denemeleriyle dolmaz.

Sıralama önemlidir. Tailnet erişimini ekleyin, ikinci bir oturumdan bu yolla giriş yapabildiğinizi doğrulayın ve ancak o zaman genel kuralı kaldırın.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Bundan sonra, genel SSH kuralını silin ve MagicDNS adını kullanarak yeniden bağlanın. ufw allow in on tailscale0 komutunun gerçekte ne yaptığına dikkat edin: tünelden gelen her şeye güvenir, bu nedenle erişim denetimi ufw yerine Tailscale politika dosyanız olur. Politikayı bu durumu göz önünde bulundurarak yazın.

Container çalıştıranlar için bir uyarı. Yayınlanan bir Docker portu kendi NAT kurallarını yükler ve ufw'yi devre dışı bırakır, bu nedenle bir ufw deny komutu bu portu kapatmaz. Docker yayınlanan portlarının ufw'yi devre dışı bırakması bu mekanizmayı açıklar. Yukarıda belirtildiği gibi tailnet adresine yayın yapmak bu durumu aşar. Uygulama Docker Compose altında çalışıyorsa, Compose yığınında bir Tailscale sidecar bir adım daha ileri gider ve yayınlanan portu tamamen kaldırarak container'a yalnızca tailnet adı üzerinden erişilebilir olmasını sağlar.

Tailscale neleri korur, neleri korumaz

Pazarlama söylemleri bu sınırı belirsizleştirdiği için durumu net bir şekilde ifade etmek gerekir.

Korunanlar: İki düğüm arasındaki trafik, WireGuard ile uçtan uca şifrelenir ve aradaki hiçbir aktarıcı (relay) bu trafiği okuyamaz. Özel anahtarlar (private keys), oluşturuldukları makineden asla dışarı çıkmaz. Düğümlerin gelen bağlantılar için açık bir genel porta ihtiyacı yoktur; bu nedenle internetin tarayabileceği 22 veya 5432 gibi portlar dış dünyaya kapalı kalır. Düğümler arasındaki erişim, adresi bilen kişiye göre değil, bir politika dosyasına göre belirlenir.

Korunmayanlar: Koordinasyon sunucusu, cihaz ağınızın yapısını (device graph) görür. Makine adları, sahipleri, adresler ve çevrimiçi olma süreleri altyapınızı tanımladığı için bu meta veriler kendi başına hassastır. Sunucu ayrıca anahtarları dağıtır; bu da daha ciddi bir risktir. Tailscale bunu doğrudan belirtir: "Eğer Tailscale kötü niyetli olsaydı ve ağınıza gizlice yeni düğümler ekleseydi, mevcut düğümlerinize düz metin olarak trafik gönderebilir veya alabilirdi." Tek oturum açma (SSO) sağlayıcınız da aynı güven yolunda yer alır; çünkü orada kimlik oluşturabilen herkes ağınıza bir düğüm ekleyebilir. Ayrıca, güvenliği ihlal edilmiş bir düğüm, tailnet içinde bir eş (peer) konumundadır; dolayısıyla bu düğümün erişebileceği yerler, politika dosyanızın izin verdiği kadardır. Bunun kabul edilebilir bir risk olup olmadığı, kime karşı savunma yaptığınıza bağlıdır. Tam güven modeli (the full trust model), çalınan bir kimlik hesabının neler yapabileceği de dahil olmak üzere bu durumların her birini detaylandırır.

Anahtar dağıtım riskine karşı iki çözüm mevcuttur. Birincisi, mevcut güvenilir düğümlerin yeni bir düğümü kabul etmeden önce kriptografik olarak imzalamasını gerektiren tailnet lock özelliğidir. Geçerli bir imza olmadan düğüm ekleyen bir kontrol düzlemi (control plane) yok sayılır. Yönetim konsolu, imzalayan düğümleriniz için tam olarak gerekli olan tailscale lock init satırını oluşturur ve her düğüm gördüğü veriyi doğrulayabilir.

tailscale lock status

Tüm düğümler aynı güvenilir imzalama anahtarlarını raporlamalıdır. İkinci çözüm ise kontrol düzlemini kendi sunucunuzda çalıştırmaktır. Kendi kendine barındırılan bir Headscale koordinasyon sunucusu, aynı istemcilerle aynı protokolü konuşur; bu da cihaz ağını ve anahtar dağıtımını kendi donanımınıza taşır. Bu durumda sunucunun çalışma süresinin (uptime) sorumluluğu da size geçer. Eğer hala kendi kendine barındırılan kontrol düzlemlerini karşılaştırıyorsanız ve bu çözümde karar kılmadıysanız, NetBird, sunucusunu tek bir VPS üzerinde uçtan uca çalıştırabileceğiniz ayrı bir mesh VPN çözümüdür.

İlk gün düzeltilmesi gereken bir varsayılan ayar vardır. Yeni bir tailnet varsayılan olarak izin verici (permissive) şekilde gelir: "varsayılan tailnet politika dosyası, tailnet içindeki tüm cihazlar arasında iletişimi etkinleştirir." Bir acls bölümü eklediğiniz anda, model varsayılan olarak reddetme (deny by default) durumuna geçer ve yalnızca sizin kurallarınız geçerli olur.

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

Bu politika, tailnet üyelerinin etiketlenmiş sunuculardaki SSH hizmetine erişmesine izin verir; bunun dışında hiçbir erişim sağlamaz. Joker karakteri olduğu gibi bırakmak yerine her hizmet için ayrı bir kural eklenmelidir. Joker karakter, ele geçirilmiş tek bir dizüstü bilgisayar anahtarının veritabanınıza erişebilmesi anlamına gelir. Hâlâ bir mesh VPN seçiyorsanız bu tür kuralları nasıl yazdığınız, seçeneklerin gerçekten farklılaştığı alanlardan biridir. NetBird ile Tailscale karşılaştırması, kontrol düzlemini kimin çalıştırdığıyla birlikte bu iki politika modelini karşılaştırır.

Hata modları ve karşılaşacağınız dizgeler

tailscale status her zaman relay döndürür. İki düğüm hiçbir zaman doğrudan bir yol oluşturamadı. Her iki uçta da tailscale netcheck komutunu çalıştırın. UDP: false, UDP trafiğinin dışa doğru engellendiği anlamına gelir; bu durumda yalnızca bir aktarıcı (relay) çalışabilir. MappingVariesByDestIP: true, arada katı bir NAT olduğunu gösterir; kontrolünüz altındaki tarafta 41641 numaralı UDP portuna gelen trafiğe izin vermek genellikle bu sorunu çözer.

Aylardır çalışan bir düğüm kayboldu. Yaygın bir neden, düğüm anahtarının 180 günlük varsayılan süresinin dolmasıdır; bu nedenle önce yönetici konsolundan makineyi kontrol edin. Eğer süresi dolmuş görünüyorsa, makine üzerinde sudo tailscale up komutunu çalıştırmak düğümü geri getirir; sunucularda anahtar süresi dolumunu devre dışı bırakmak ise bu durumun tekrarlanmasını önler. Eğer süresi dolmamışsa, politika dosyasını kontrol edin; çünkü Tailscale'in tailscale status üzerinde görünmeyen bir cihaz için önerisi, bağlantıyı engelleyen erişim kurallarının olup olmadığına bakmaktır.

Eşler listeleniyor ancak bağlantılar zaman aşımına uğruyor. Eğer tailscale ping yanıt alıyorsa, bağlantı çalışıyor demektir ve muhtemel neden trafiği reddeden politikadır. Bu kaynak, hedef ve portu kapsayan bir kural için acls bölümünü kontrol edin. Reddedilen paketler yanıtlanmak yerine düşürülür; bu yüzden Connection refused yerine zaman aşımı alırsınız.

MagicDNS isimleri çözümlenemiyor. ping db-1 başarısız olurken ping 100.101.102.104 çalışıyor. Öncelikle istemcinin Tailscale DNS ayarlarını kabul ettiğini doğrulayın: --accept-dns=false ile başlatılan bir düğüm, sorgularını asla 100.100.100.100 adresindeki stub resolver'a göndermez. Ardından cat /etc/resolv.conf dosyasına ve makinede bu dosyayı yazan diğer araçlara bakın. systemd-resolved kullanan bir sistemde, bu dosya normalde /run/systemd/resolve/stub-resolv.conf konumuna giden bir sembolik bağdır ve orada 100.100.100.100 listelenmemesi beklenen bir durumdur. tailscaled'in dosyayı doğrudan yazdığı durumlarda, dosyayı üzerine yazan bir DHCP istemcisi veya başka bir araç MagicDNS'i bozar. Eğer sorun bunlardan kaynaklanmıyorsa, hata yerel veya ağ DNS yapılandırmasında olabilir. Bu, WireGuard tüneli içinde DNS'in bozulması ile aynı sınıftaki bir sorundur.

tailscale up etiketinizi reddediyor. Etiket, politika dosyasında tagOwners altında tanımlanmamıştır. Etiketi oraya ekleyin ve ardından komutu tekrar çalıştırın.

FAQ

Tailscale bir VPN mi yoksa mesh ağı mı?

Her iki terim de doğrudur ve farklı katmanları tanımlarlar. Tüneller WireGuard tabanlıdır, bu da onu bir VPN yapar. Topoloji ise bir mesh yapısıdır; çünkü her düğüm, her paketi merkezi bir sunucu üzerinden göndermek yerine, iletişim kurduğu diğer her düğümle doğrudan bir tünel oluşturur. Koordinasyon sunucusu veri yolunda değil, kontrol yolunda yer alır; bu nedenle sunucuya erişilemediği durumlarda mevcut tünelleriniz trafiği taşımaya devam eder. Kesinti sırasında duran şey, yeni düğümlerin ağa katılması ve anahtar veya politika güncellemelerinin sisteme işlenmesidir. Ancak varsayılan olarak bir gizlilik VPN'i değildir: trafiğinizi bir çıkış düğümü (exit node) üzerinden göndermediğiniz sürece web siteleri kendi genel IP adresinizi görmeye devam eder ve Tailscale'in web sitelerinden ve ISS'nizden neleri gizlediği her kurulumda farklılık gösterir.

Tailscale trafiğimi okuyabilir mi?

İçeriği okuyamaz. Trafik, düğümler arasında WireGuard ile uçtan uca şifrelenir, özel anahtarlar düğümleri asla terk etmez ve bir DERP aktarıcısı, şifresini çözme imkanı olmayan paketleri iletir. Tailscale yalnızca meta verileri görür: makine adları, sahipler, genel anahtarlar, uç nokta adresleri ve her düğümün çevrimiçi olma durumu. Ayrıca anahtarları dağıttığı için, ele geçirilmiş bir koordinasyon sunucusu, ağınızın güveneceği sahte bir düğüm eklemeye çalışabilir. Tailnet lock, kendi güvenilir düğümlerinizden imza talep ederek bunu engeller; Headscale ise barındırılan kontrol düzlemini tamamen devre dışı bırakır.

Tailscale için güvenlik duvarı portlarını açmam gerekiyor mu?

Gelen bağlantılar için neredeyse hiç gerekmez. Tailscale'in kendi kılavuzu "çoğu zaman herhangi bir güvenlik duvarı portu açmanıza gerek yoktur" der. Giden bağlantılar için bir düğümün koordinasyon sunucusuna ve aktarıcılara TCP 443, ayrıca STUN için UDP 3478 portuna ihtiyacı vardır. Doğrudan tüneller, varsayılan olarak 41641 olan bir kaynak portu ile UDP kullanır. UDP 41641 portuna gelen bağlantılara izin vermek isteğe bağlıdır ve bu yalnızca zorlu ağlarda doğrudan bağlantıların başarılı olmasına yardımcı olur.

Diğer düğümler neden 3000 numaralı porttaki servisime ulaşamıyor?

Öncelikle ss -tlnp ile dinleme adresini (bind address) kontrol edin. 127.0.0.1:3000 üzerinde dinleme yapan bir servis, düğümün 100.x tailnet adresine gelen bağlantıları reddeder; çünkü bu soket yalnızca loopback hedefini kabul eder ve istemci Connection refused hatası alır. Servisi tailnet adresine bağlayın veya proxy yapmak için tailscale serve 3000 çalıştırın. Eğer dinleyici zaten 0.0.0.0 üzerinde çalışıyorsa ve bağlantı reddedilmek yerine zaman aşımına uğruyorsa, sorun dinleme adresi değildir. Öncelikle politika kurallarına ve ana bilgisayar güvenlik duvarlarına, ardından ağ güvenlik duvarlarına ve cihazlardan birinin kimlik doğrulamasının süresinin dolup dolmadığına bakın.

Tailscale'in koordinasyon sunucusu yerine Headscale mi çalıştırmalıyım?

Cihaz grafiğinin veya anahtar dağıtımının kontrolünüz altındaki altyapıda kalması gerektiğinde ya da tailnet'in dış bir servise bağımlılık olmadan çalışması zorunlu olduğunda Headscale çalıştırın. İstemciler ve protokol aynıdır. Bunun maliyeti, koordinasyon sunucusunu artık sizin işletmenizdir; sunucunun kesintiye uğraması yeni düğümlerin katılmasını ve politika değişikliklerinin uygulanmasını durdurur. Küçük bir filo için, tailnet lock etkinleştirilmiş barındırılan kontrol düzlemi genellikle daha iyi bir tercihtir.