Tailscale nedir ve 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ının arkasındaki iki sunucu doğrudan nasıl haberleşir?

NAT (ağ adresi çevirisi), birçok makinenin tek bir genel adresi paylaşmasını sağlayan teknolojidir. 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ının 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 bir güvenlik duvarı kuralı oluşturmasına gerek kalmaz.

Portlar belirli bir yapıdadır. Doğrudan WireGuard tünelleri, varsayılan olarak 41641 kaynak portunu kullanan UDP protokolünü kullanır. STUN, Tailscale'in aktarma sunucularına UDP 3478 üzerinden erişir. Kontrol bağlantısı ve aktarılan tüm veriler TCP 443 üzerinden HTTPS kullanır. Çoğu durumda gelen bağlantı için herhangi bir port açmanız gerekmez; ancak zorlu bir NAT yapısına sahip ağlarda, UDP 41641 portuna gelen trafiğe izin vermek doğrudan bağlantı kurulma olasılığını artırır.

tailscale netcheck

Bu raporun iki satırını inceleyin. UDP: true, UDP trafiğinin makineden çıkış yapabildiği anlamına gelir; UDP: false ise bu düğümden yapılan her bağlantının aktarılacağı (relayed) anlamına gelir. MappingVariesByDestIP: true ise yönlendiricinin her hedef için farklı bir genel port atadığı anlamına gelir; bu durumda yukarıda belirtilen adres tahmini çalışmaz ve bu düğümler genellikle aktarılmış (relayed) durumda kalır.

Tailscale bir DERP aktarıcısı kullandığında

DERP (designated encrypted relay for packets), yedek bağlantı yöntemidir. Tailscale, TCP 443 üzerinden erişilebilen birçok bölgede aktarıcılar çalıştırır; doğrudan yol bulamayan bir düğüm, WireGuard paketlerini bu aktarıcılardan biri üzerinden gönderir.

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

Aktarıcılar ayrıca çoğu bağlantının ilk paketlerini de taşır. Doğrudan bir yol bulmak zaman aldığından, bir oturum genellikle aktarılan bir bağlantıyla 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 döner, ardından sonraki bir satır via 198.51.100.24:41641 gibi bir durum bildirir. Bu değişim, doğrudan bir tünele yükseltmedir. Eğer bu durum hiç değişmiyorsa, her iki uçta tailscale netcheck komutunu çalıştırın. Aktarılan 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, aktarılan bir Tailscale bağlantısının doğrudan bağlantıdan neden çok daha yavaş olduğu konusu aradaki farkı ölçer ve bir VPS'i doğrudan yola nasıl sokacağınızı 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önetici konsolunuzda görünür. Ardından, daemon'ın yeniden başlatma sonrasında tekrar çalışıp çalışmadığını doğrulayın; zira bu, kullanıcıların genellikle atladığı bir adımdır.

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. Betik ile oluşturulan bir sunucuda etkileşimli URL kullanımı pratik değildir. Yönetici 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

Etiketlenmiş 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; çünkü etiketli bir kaynak, kullanıcının kendi cihazlarından ayrı olarak ücretlendirilir. ücretsiz katmanın neleri kapsadığı bölümünde bu limitlerin detayları yer almaktadır.

Bir filo yönetimi için iki ayar önemlidir. Düğüm anahtarları varsayılan olarak 180 gün sonra sona erer (Ağustos 2026 itibarıyla). Bir anahtarın süresi dolduğunda, birisi tekrar giriş yapana kadar "ilgili uç noktaya yapılan bağlantılar çalışmayı durdurur". Bu nedenle, yönetici konsolunda makinenin satırını açın ve katılımsız sunucular için Disable Key Expiry seçeneğini işaretleyin. 20 Ekim 2022 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.

Kurulum sırasında apt veya depo kaynaklı bir hata oluşursa, Ubuntu üzerinde sık karşılaşılan Tailscale kurulum hataları bölümünde çözüm yolları yer almaktadır.

Localhost üzerinde dinleyen bir servise erişim

Tailnet kullanımının faydalı olduğu ve kullanıcıların genellikle takıldığı nokta burasıdır. Bir tailnet'e katılmak, loopback üzerinde çalışan bir servisi doğrudan 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önlendirildiğinde çekirdek (kernel) bu istek için dinleme yapan bir süreç bulamaz ve TCP reset ile yanıt verir. İstemci Connection refused hatası döndürür. Tünel düzgün çalışmaktadır; sorun dinleyici yapılandırmasındadır.

Bu durum için iki geçerli çözüm mevcuttur. Servisi düğümün tailnet adresine bağlayın; bu, servisi genel ağ arayüzünden uzak tutar ve arada bir proxy gerektirmez: yapılandırmanızda --bind 100.101.102.104 veya eşdeğer bir seçenek 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ıp önüne Tailscale yerleştirin.

tailscale serve 3000

Bu yapı, 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. Servis, düğümleriniz için özel kalmaya devam eder. Aynı mantığın genel ağa açık versiyonu Funnel'dır ve Tailscale serve ve funnel kullanımı başlığı, hangisine ihtiyacınız olduğunu belirlemenize yardımcı olur.

İki ilgili görev için ayrı sayfalar mevcuttur. Üzerinde Tailscale yüklü olmayan bir özel 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 etiketli sunucularda SSH'a erişmesine izin verir ve başka hiçbir şeye izin vermez. Joker karakteri (wildcard) olduğu gibi bırakmak yerine her servis için ayrı bir kural ekleyin; çünkü joker karakter, çalınan bir dizüstü bilgisayar anahtarının veritabanınıza erişebileceği anlamına gelir.

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

tailscale status her zaman relay çıktısını verir. İ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. Düğüm anahtarı, 180 günlük varsayılan sürede sona erdi. Makine, yönetim konsolunda süresi dolmuş olarak görünür ve cihaz üzerinde sudo tailscale up komutunu çalıştırmak düğümü tekrar aktif eder. Bu durumun tekrarlanmaması için sunucularda anahtar süresi dolma özelliğini devre dışı bırakın.

Eşler listeleniyor ancak bağlantılar zaman aşımına uğruyor. Bağlantı çalışıyor ancak politika trafiği reddediyor. Bu kaynak, hedef ve portu kapsayan bir kural olup olmadığını kontrol etmek için acls bölümüne bakın. Reddedilen paketler yanıtlanmak yerine düşürülür; bu nedenle Connection refused yerine zaman aşımı hatası alırsınız.

MagicDNS adları çözümlenemiyor. ping db-1 başarısız olurken ping 100.101.102.104 çalışıyor. Bir şey /etc/resolv.conf dosyasının üzerine yazdı, bu nedenle sorgular 100.100.100.100 adresindeki stub resolver'a asla ulaşmıyor. cat /etc/resolv.conf dosyasında 100.100.100.100 olup olmadığını kontrol edin ve cihazda bu dosyayı değiştiren diğer süreçleri inceleyin. Bu, WireGuard tüneli içinde DNS'in bozulması ile aynı sınıftaki bir sorundur.

tailscale up etiketinizi reddediyor. Etiket, politika dosyasındaki tagOwners altında tanımlanmamış. Etiketi oraya ekleyin ve 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 düğümlerle doğrudan bir tünel oluşturur. Koordinasyon sunucusu veri yolunda değil, kontrol yolunda yer alır; bu nedenle sunucuya erişilemediğinde mevcut tünelleriniz trafiği taşımaya devam eder. Bir kesinti sırasında duran tek şey, yeni düğümlerin ağa katılması ve anahtar veya politika güncellemelerinin sisteme işlenmesidir.

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 çözemeyeceği paketleri yalnızca 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 gerektirerek bunu engeller; Headscale ise barındırılan kontrol düzlemini tamamen devreden çıkarır.

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

Gelen trafik için neredeyse hiçbir zaman gerekmez. Tailscale'in kendi kılavuzu, "çoğu zaman herhangi bir güvenlik duvarı portu açmanıza gerek yoktur" der. Giden trafik 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 kaynak portunu kullanan UDP protokolünü kullanır. UDP 41641 portuna gelen trafiğe 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 kontrol edin. 127.0.0.1:3000 üzerinde çalışan bir dinleyici, 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 üzerindeyse ve bağlantı reddedilmek yerine zaman aşımına uğruyorsa, sorun dinleme adresinden ziyade bir politika kuralı veya ana makine güvenlik duvarıdır.

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.