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 nokta bu paketleri 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, oluşturduğunuz 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) çalışır ve düğümler arasında şifrelidir. Kontrol düzlemi ise Tailscale tarafından sizin için yönetilen bir servistir. Tailscale hakkındaki 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 otomatikleştirilmiş aynı tünel sistemidir.

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 arka plan süreci başlar, bir WireGuard anahtar çifti oluşturur ve durumunu /var/lib/tailscale/tailscaled.state içinde tutar. Özel anahtar makinede kalır. Tailscale'in kendi ifadesi nettir: "özel anahtar hiçbir zaman, hiçbir koşulda düğümünden ayrılmaz."
2. Düğüm, koordinasyon sunucusuna giriş yapar ve genel anahtarını, ayrıca kendisine ulaşılabileceğine inandığı 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. Her düğüm çifti daha sonra kendi aralarında doğrudan bir WireGuard tüneli kurmaya çalışır. Bu 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 arasında değişen taşıyıcı sınıfı NAT aralığı olan 100.64.0.0/10 içinden 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. Tailscale'in sudo modprobe wireguard'nin Operation not supported hatasıyla başarısız olduğu konteyner sanallaştırma ortamlarında çalışabilmesinin nedeni budur. Bu durum aynı zamanda, belirli bir makinedeki verimlilik 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 ele alınan ödünleşimlerden biri de budur.

Durumunuzu anlamanızı sağlayan iki komut vardır.

tailscale ip -4
tailscale status

tailscale status komutu her düğüm için bir satır yazdırır ve en önemli kısım 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 ifadesini bir adres ve port takip ediyorsa, iki makine birbirine giden bir yol bulmuş demektir ve trafik eşten eşe (peer to peer) ilerliyordur. relay "fra", trafiğin Frankfurt'taki bir Tailscale aktarıcısı üzerinden geçtiği anlamına gelir. - ise o düğümle şu an aktif bir oturum olmadığını gösterir 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ızı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 kendine çalıştırılan herhangi bir koordinasyon sunucusu, düğümlerinize hangi genel anahtarların tailnet'e ait olduğunu söyleme konusunda yetkilidir. Bu, aşağıda açıklanan tehdit modelinin temel noktasıdır ve kendi sunucunuzda barındırabileceğiniz açık kaynaklı bir koordinasyon sunucusu olan Headscale projesinin varlık nedenidir.

Farklı güvenlik duvarlarının arkasındaki iki sunucu doğrudan nasıl haberleşir

NAT (network address translation), birçok makinenin tek bir genel IP adresini 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 build runner veya düzenleyemediğiniz bir servis sağlayıcı güvenlik duvarının arkasındaki bir cihaz) genellikle bu özelliğe sahip değildir.

Tailscale, STUN (session traversal utilities for NAT) 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ılar 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ılar için herhangi bir port açmanız gerekmez; ancak NAT yapısının karmaşık olduğu 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ı okuyun. 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, 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 kuramayan bir düğüm, WireGuard paketlerini bu aktarıcılardan biri üzerinden gönderir.

Paketler şifreli kalmaya devam eder. 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 ifade bildirir. Bu değişim, doğrudan bir tünele yükseltme yapıldığını gösterir. Eğer bu durum hiç değişmezse, her iki uçta da tailscale netcheck komutunu çalıştırın. Aktarılan bir yol da çalışmaya devam eder. Ancak her paket üçüncü bir makine üzerinden dolaylı yoldan gittiği için gecikmeye neden olur.

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. Ardından, insanların genellikle atladığı bir adım olan, yeniden başlatma sonrasında daemon'ın tekrar çalışıp çalışmadığı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. Betik ile oluşturulan bir sunucuda etkileşimli URL kullanışlı değildir. Yönetim konsolunda bir kimlik doğrulama anahtarı (auth key) oluşturun ve bu makinenin türünü kaydeden bir etiket (tag) ile birlikte iletin.

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

Etiketli bir düğüm, komutu çalıştıran kişiden ziyade etiketin sahipliğindedir; bu sayede ilgili kişinin hesabı silinse bile çalışmaya devam eder. Etiket, öncelikle politika dosyanızda tagOwners altında tanımlanmalıdır, aksi takdirde komut reddedilir. Etiketleme, makinenin planınızdaki kota kullanımını da değiştirir; çünkü etiketli bir kaynak, kişinin kendi cihazlarından ayrı olarak ücretlendirilir ve ücretsiz planın neleri kapsadığı bu limitlerin 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 (Ağustos 2026 itibarıyla). Bir anahtarın süresi dolduğunda, birisi tekrar giriş yapana kadar "ilgili uç noktaya yapılan/gelen bağlantılar çalışmayı durdurur". Bu nedenle, gözetimsiz sunucularda yönetim konsolundaki makine satırını açın ve Disable Key Expiry seçeneğini belirleyin. 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 isimleri kullanın; çünkü yeniden oluşturulan bir düğüm yeni bir adres alır ancak ismini korur.

Kurulumun kendisi apt veya depo tarafında başarısız olursa, Ubuntu üzerinde yaygın Tailscale kurulum hataları bölümü çözümleri 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 (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 vardır. Servisi düğümün tailnet adresine bağlayın; bu, servisi genel arayüzden uzak tutar ve araya bir proxy koymanıza gerek kalmaz: 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 yöntem, istekleri http://127.0.0.1:3000 adresine proxy eder ve tailnet için HTTPS sertifikaları etkinleştirildiğinde, tailnet içinde bir ts.net ismi üzerinden HTTPS ile servis eder. Bu yapı yalnızca sizin düğümleriniz için özel kalır. Aynı mantığın genel kullanıma açık versiyonu Funnel'dır ve Tailscale serve ve funnel kullanımı başlığı hangisini tercih etmeniz gerektiğini açıklar.

Birbiriyle ilişkili iki 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 yönlendirmek için ise exit node kullanımı gereklidir.

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

Her yönetici sunucuya tailnet üzerinden erişebilecek duruma geldiğinde, herkese açık 22 numaralı portun bir işlevi kalmaz. Pratik kazanç budur: 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. Önce tailnet erişimini ekleyin, ikinci bir oturumdan bu yolla giriş yapabildiğinizi doğrulayın ve ancak o zaman herkese açık kuralı kaldırın.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Bunun ardından, herkese açık 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 haline gelir. Politikayı bu durumu göz önünde bulundurarak yazın.

Container çalıştıranlar için bir uyarı. Yayınlanan (published) bir Docker portu kendi NAT kurallarını yükler ve ufw'yi devre dışı bırakır; bu nedenle ufw deny komutu bu portu kapatmaz. Docker published ports bypassing ufw bu mekanizmayı açıklar. Yukarıda belirtildiği gibi tailnet adresine yayın yapmak, bu durumu aşmanızı sağlar.

Tailscale neleri korur, neleri korumaz

Pazarlama söylemleri bu çizgiyi bulanıklaştırdığı 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ı makineyi asla terk etmez. Düğümlerin gelen trafiğe açık bir portuna ihtiyaç duymaması sayesinde, internetin tarayabileceği 22 veya 5432 gibi portlar dış dünyaya kapalı kalır. Düğümler arası erişim, bir adresi bilip bilmemeye göre değil, bir politika dosyasına göre belirlenir.

Korunmayanlar: Koordinasyon sunucusu, cihaz ağınızı (device graph) görür. Makine adları, sahipleri, adresleri ve çevrimiçi süreleri altyapınızı tanımladığı için bu meta veriler kendi başına hassastır. Ayrıca anahtarları dağıtması, daha ciddi bir risktir. Tailscale bunu doğrudan şu şekilde ifade eder: "Eğer Tailscale kötü niyetli olsaydı ve ağınıza gizlice yeni düğümler ekleseydi, Tailscale 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 ele geçirilmiş bir düğüm, tailnet içinde bir eş (peer) konumundadır; dolayısıyla bu düğümün erişebileceği yerler, politikanızın izin verdiği alanlarla sınırlıdır. Bunun kabul edilebilir bir risk olup olmadığı, kime karşı savunma yaptığınıza bağlıdır. Tam güven modeli, çalınmış 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önetici konsolu, imzalayan düğümleriniz için tam olarak tailscale lock init satırını oluşturur ve her düğüm gördüğü şeyi 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 kendinizin çalıştırmasıdı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 sahip olduğunuz donanıma taşır. Bu durumda sunucunun çalışma süresinden (uptime) de siz sorumlu olursunuz. Eğer henüz bu çözümde karar kılmayıp kendi kendine barındırılan kontrol düzlemlerini karşılaştırıyorsanı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 ş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 yalnızca SSH'a erişmesine izin verir, 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 ulaşabileceğ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 röle (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 onu tekrar aktif hale getirir. Bu durumun tekrarlanmaması için sunucularda anahtar süresi dolumunu 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 isimleri çözümlenmiyor. 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 yüzden sorgular 100.100.100.100 adresindeki stub resolver'a asla ulaşmıyor. cat /etc/resolv.conf içinde 100.100.100.100 ifadesini kontrol edin ve cihazda bu dosyaya yazan 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ında tagOwners altında tanımlanmamış. 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, paketleri merkezi bir sunucu üzerinden göndermek yerine, iletişim kurduğu diğer her düğüme 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 tek şey, yeni düğümlerin ağa katılması ve anahtar veya politika güncellemelerinin iletilmesidir.

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 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ılarda, bir düğümün koordinasyon sunucusuna ve aktarıcılara TCP 443, ayrıca STUN için UDP 3478 portu üzerinden erişmesi gerekir. Doğrudan tüneller, varsayılan olarak 41641 kaynak portunu kullanan UDP protokolünü 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 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 olarak kullanmak 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, bunun nedeni bind adresi değil, 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 yönetmenizdir; sunucunun kesintiye uğraması yeni düğümlerin katılımı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.