VPS uzerinde Tailscale subnet router kurulumu

Tailscale subnet router ne işe yarar

Tailscale subnet router, özel IP adresi aralıklarını tailnet ağınıza duyuran bir makinedir; böylece tailnet üzerindeki tüm cihazlar, üzerinde Tailscale çalışmayan sistemlere dahi erişebilir. Tailnet, tek bir hesap veya organizasyon altında oturum açmış cihazlardan oluşan özel Tailscale ağınızdır. İnsanların sıklıkla karıştırdığı exit node özelliği ise tam tersi bir işlev görür. Exit node, cihazın tüm trafiğini VPS üzerinden geçirerek VPS'i cihazın genel internete çıkış noktası haline getirir.

Her biri tek cümlelik açıklamalar şöyledir. Subnet router, özel bir ağın tailnet üzerinden erişilebilir olmasını sağlar. Exit node ise genel ağ trafiğinizin çıkış noktasını değiştirir. Eğer ihtiyacınız olan özellik ikincisi ise, bunun yerine VPS üzerinde Tailscale exit node çalıştırma rehberini okuyun. Bunlar birbirinden farklı bayraklardır ve bir VPS aynı anda her ikisini de yapabilir; ancak farklı sorunları çözerler ve farklı şekillerde başarısız olurlar.

Bir VPS'in subnet router olarak kullanılması gerektiği durumlar

Yaygın senaryo, servis sağlayıcınızın size halihazırda sunduğu özel bir ağdır. VPS'iniz bir genel IP adresine ve özel bir segmentte ikinci bir arayüze sahiptir; bu segmentteki diğer sunucuların ise hiçbir genel adresi yoktur: 10.0.0.20 adresindeki bir veritabanı veya 10.0.0.30 adresindeki bir yedekleme hedefi gibi. Tailscale'i bir VPS üzerine kurup 10.0.0.0/24 adresini duyurduğunuzda, dizüstü bilgisayarınız bu özel adreslere doğrudan erişebilir. Segmentteki diğer hiçbir şey değişmez ve veritabanı genel bir adres almaz. Eğer o segmentten ihtiyacınız olan tek şey tek bir port üzerindeki bir web uygulamasıysa, tüm aralığı duyurmak işin gerektirdiğinden fazlasıdır ve Tailscale serve, HTTPS'i doğrudan bu tek port üzerine yerleştirir. Aynı mantık, yalnızca localhost üzerinde dinleme yapan bir daemon için de geçerlidir; örneğin systemd altında başsız (headless) çalışan dsh durumunda, VPS üzerindeki bir tailnet adresi, arayüzüne ulaşmak için açık tutmanız gereken SSH tünelinin yerini alır.

Diğer durum ise VPS'in ötesindeki bir ağdır. Kendi yönlendiricisi (router) arkasındaki bir ev veya ofis yerel ağı (LAN) ya da yönetilen bir anahtar (switch) veya kilitli yazılıma sahip eski bir NAS gibi Tailscale çalıştıramayan cihazlardan oluşan bir raf olabilir. O ağdaki bir Linux makinesi, ağdaki diğer her şey için subnet router haline gelir. Ev ortamında bu makine genellikle halihazırda çalıştırdığınız bir hipervizör üzerindeki küçük bir VM'dir ve evdeki bir Proxmox sunucusu ile kiralanan bir VPS'in maliyet hesabı, servislerinizin tünelin hangi ucunda barınması gerektiğine karar vermeden önce netleştirilmesi gereken bir konudur.

Her iki durum da tek bir gereksinimi paylaşır. Subnet router, kendi yönlendirme tablosunu ve güvenlik duvarını kullanarak duyurduğu aralığa halihazırda erişebiliyor olmalıdır. Tailscale bu bağlantıyı oluşturmaz. Sadece trafiği yönlendiriciye taşır ve iletilmesi için çekirdeğe (kernel) teslim eder.

Tailscale kurulumu ve yerel rotanın kontrol edilmesi

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

Betik, dağıtımı algılar, Tailscale paket deposunu ekler, tailscale komutunu ve tailscaled daemon'ını kurar, ardından servisi etkinleştirir. Bunu, active çıktısını vermesi gereken systemctl is-active tailscaled komutu ile doğrulayın.

Başka bir işlem yapmadan önce, VPS'in duyurmayı planladığınız ağa erişebildiğinden emin olun.

ip route show
ping -c3 10.0.0.20

ip route show, gerçek bir arayüz üzerinde 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5 gibi özel bir IP aralığını listelemelidir. Eğer ping işlemi burada, yani yönlendiricinin kendisinde başarısız olursa, hiçbir Tailscale bayrağı bunu düzeltemez. Sorun, VPS ağ yapılandırmasında veya hedef ana makinedeki bir güvenlik duvarındadır. Sonraki tüm testler buna bağlı olduğundan, öncelikle bu sorunu giderin.

IP yönlendirmeyi etkinleştirme ve yeniden başlatma sonrası kalıcı hale getirme

Bir Linux makinesi, kendisine gönderilmeyen tüm paketleri, yönlendirme etkinleştirilmediği sürece reddeder. Diğer makinelerin paketlerini yönlendirmek bir alt ağ yönlendiricisinin (subnet router) temel görevidir, bu nedenle bu adım isteğe bağlı değildir.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Durumu sysctl net.ipv4.ip_forward ile kontrol edin; bu komut net.ipv4.ip_forward = 1 çıktısını vermelidir.

Kullanıcılar genellikle bu adımı kısmen doğru yapar. sudo sysctl -w net.ipv4.ip_forward=1 anında sonuç verir ancak bir sonraki yeniden başlatmada ayarlar kaybolur; bu durumda alt ağ yönlendiricisi haftalarca çalışır ve çekirdek güncellemesi sonrası yapılan bir yeniden başlatmanın ardından sabah saatlerinde durur. Karmaşık olan kısım, hiçbir şeyin bozuk görünmemesidir. tailscale status düğümü çevrimiçi göstermeye devam eder, yönetici konsolu rotanın onaylandığını belirtir ve istemciler rotayı yüklü tutar. Paketler VPS'e ulaşır ancak çekirdek hiçbir kayıt tutmadan paketleri düşürür. Değerleri /etc/sysctl.d/99-tailscale.conf içine yazmak, yeniden başlatma sonrasında ayarların korunmasını sağlar.

Eğer yönlendirme kapalıyken rota duyurusu yaparsanız, tailscale up o anda sizi uyarır ve Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. ifadesine yakın bir satır gösterir. Bu komutun çıktısını hızlıca geçmek yerine mutlaka okuyun.

Rotaları duyurma

sudo tailscale up --advertise-routes=10.0.0.0/24

Halihazırda tailnet ağınıza bağlı olan bir VPS üzerinde, ayarı yerinde değiştirin:

sudo tailscale set --advertise-routes=10.0.0.0/24

Sonraki her değişiklik için tailscale set kullanın. tailscale up komutunu tek bir bayrakla tekrar çalıştırmak, belirtmediğiniz bayrakları sıfırlar; CLI, ayarları bu şekilde değiştirmenin varsayılan olmayan tüm bayrakların belirtilmesini gerektirdiğini belirten bir hata vererek işlemi durdurur. tailscale set ise yalnızca bir ayarı değiştirir ve diğerlerini olduğu gibi bırakır.

Birden fazla aralık, boşluk bırakılmadan virgülle ayrılmış bir liste halinde girilmelidir: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Her girdi, CIDR notasyonunda (sınıfsız etki alanları arası yönlendirme, 10.0.0.0/24 biçimi) bir ağ adresi olmalıdır. Kendi ana makine adresinizi yanlışlıkla 10.0.0.5/24 şeklinde yazmanız durumunda, önekten sonraki bitler sıfır olmadığı için işlem reddedilir ve hata mesajında muhtemelen kastettiğiniz önek belirtilir. Duyuruyu durdurmak için sudo tailscale set --advertise-routes= ile boş bir liste ayarlayın.

Yönetim konsolunda rotayı onaylayın

Bir rotayı duyurmak bir istek işlemidir, bir değişiklik değildir. Bir yönetici onaylayana kadar hiçbir istemci rotayı almaz ve aralıktaki hiçbir noktaya erişilemez. Bu durum kasıtlıdır; çünkü kendini herkesin yönlendirme tablosuna ekleyebilen bir makine, istediği aralıktaki trafiği ele geçirebilir.

Onayı yönetim konsolunun Machines sayfasından yapın. VPS, bir subnet rozeti ile listelenir. Satırını açın, subnets bölümünü bulun, rota ayarlarını düzenleyin, rotayı işaretleyin ve kaydedin.

Onay, her önek (prefix) için ayrıdır. Bugün 10.0.0.0/24 duyurusu yapıp gelecek ay 192.168.50.0/24 eklerseniz, eski rota çalışmaya devam ederken yeni önek onaysız olarak gelir. Onaylanmış bir rota ile göz ardı edilen bir rota, VPS açısından aynı görünür; bu nedenle başka bir hata ayıklama işlemine başlamadan önce konsolu kontrol edin.

Tailnet politika dosyasındaki bir autoApprovers bloğu ile manuel adımı atlayabilirsiniz:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Ardından düğümü bu etiketle, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, ayağa kaldırın; rota duyurulduğu anda onaylanmış olur. Etiketin öncelikle aynı politika dosyasının tagOwners bölümünde tanımlanmış olması gerekir. VPS'i bir betik üzerinden yeniden oluşturuyorsanız bu yapılandırmayı yapmak faydalıdır, çünkü yeniden oluşturulan bir düğüm yeni bir düğüm sayılır ve rotaları tekrar onaysız başlar.

Linux istemcileri neden --accept-routes olmadan rotayı yok sayar

Rota artık duyurulmuş ve onaylanmıştır. Telefonunuz ve Mac cihazınız 10.0.0.20 adresine erişebilir. Linux dizüstü bilgisayarınız ise erişemez ve yönetici konsolunda herhangi bir sorun görünmez.

Bir alt ağ rotasını kabul etmek, istemcinin yönlendirme tablosuna girişler yazmak anlamına gelir. Android, iOS, macOS, tvOS ve Windows üzerinde Tailscale istemcisi bunu sizin yerinize yapar. Linux üzerinde ise yapmaz; çünkü bir Linux makinesi genellikle yönlendirme tablosu özel olarak yapılandırılmış bir sunucu veya yönlendiricidir. Ağdan öğrenilen bir /24 bilgisinin sessizce eklenmesi, makinenin halihazırda yönettiği trafiği bozabilir. Bu nedenle Linux üzerinde her istemci için bu özelliği manuel olarak etkinleştirmeniz gerekir:

sudo tailscale set --accept-routes

Ardından rotanın nereye eklendiğini kontrol edin:

ip route show table 52
ip route get 10.0.0.20

Linux üzerindeki Tailscale, kabul edilen rotaları ana yönlendirme tablosuna yerleştirmez. Bunları 52 numaralı yönlendirme tablosuna ekler ve eşleşmeyen paketleri bu tabloya yönlendiren, ip rule show ile 5210 ila 5270 öncelik aralığında görülebilen ilke kuralları oluşturur. Bu nedenle, ip route show tek başına hiçbir zaman 10.0.0.0/24 bilgisini listelemez ve yalnızca bu komutu kontrol eden bir kullanıcı, --accept-routes işleminin hiçbir şey yapmadığı sonucuna varır. ip route show table 52, gerçeği gösteren komuttur ve duyurulan aralığı tailscale0 üzerinde listelemelidir.

Bilinmesi gereken bir istisna vardır. Eğer bu Linux düğümü kendi yerel ağı için ikinci bir alt ağ yönlendiricisi ise, --accept-routes kullanımı, doğrudan bağlı olduğu alt ağa ait trafiği kendi arayüzü yerine diğer yönlendirici üzerinden göndermesine neden olur. Yüksek erişilebilirlik (high availability) çiftindeki yedek bir yönlendiricide, --accept-routes seçeneğini kapalı tutun ve yalnızca duyuru yapın.

Hata modu: iki yönlendiricinin çakışan aralıkları duyurması

İki alt ağ yönlendiricisi aynı aralıkları duyurmamalıdır. Farklı önek uzunluklarına sahip çakışan aralıklara izin verilir ve Tailscale en spesifik eşleşmeyi seçer. Yönlendirici A 10.0.0.0/24 aralığını, yönlendirici B ise 10.0.0.0/16 aralığını duyurduğunda, 10.0.0.20 adresine giden trafik A'ya yönlendirilir.

İnsanları şaşırtan durum, A çevrimdışı olduğunda yaşanan davranıştır. Tailscale daha az spesifik olan rotaya geri dönmez. 10.0.0.20 adresine giden trafik durur, ancak 10.1.0.20 adresine giden trafik B üzerinden çalışmaya devam eder. Belirti, özel ağın yarısı kesilmiş gibi görünür ve bunun nedeni, çevrimdışı olan bir düğümün daha spesifik öneki elinde tutmasıdır. Yük devretme (failover) istiyorsanız, daha geniş kapsamlı yönlendiricinin de daha dar önekleri duyurmasını sağlayın; böylece her ikisi de aynı adresleri kapsar.

Diğer çakışma türü istemciye daha yakındır. 192.168.1.0/24 adresindeki bir otel ağındayken alt ağ yönlendiriciniz 192.168.1.0/24 aralığını duyuruyorsa, bu iki ağ aynı hedefler için rekabet eder ve hangisinin kazanacağı platforma bağlıdır. Linux üzerinde, yerel adreslerin ana tabloyu kullanması için Tailscale'in kendi kuralından önce bir kural yükleyin:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Bu kural kalıcı değildir ve bir sonraki önyüklemede silinir. Asıl çözüm, dış dünyada karşılaşmayacağınız bir özel aralık seçmektir. 192.168.0.0/24 ve 192.168.1.0/24 çoğu ev yönlendiricisinde varsayılan değerlerdir, bu nedenle 10.0.0.0/8 içinde bilinçli olarak seçtiğiniz bir aralığı kullanın. Aynı çakışma, elle yapılandırdığınız standart bir WireGuard VPN bağlantısını da aynı nedenle bozar: daha spesifik olan yerel rota kazandığı için trafik asla tünele girmez.

Hata modu: DNS, hiçbir rotanın kapsamadığı bir adrese çözümleniyor

Bu durumun hata ayıklaması zordur, çünkü hiçbir şey hata bildirmez. İsim çözümlenir. Bağlantı zaman aşımına uğrar.

db.internal.example.com adresinin özel isim sunucunuz üzerinden 10.0.5.20 adresine çözümlendiğini ve 10.0.0.0/24 adresini duyurduğunuzu varsayalım. DNS (domain name system) çözümlemesi ile IP yönlendirmesi birbirinden ayrı adımlar olduğundan ve hiçbiri diğerini kontrol etmediğinden, sorgulama başarılı olur. Ardından 10.0.5.20 adresine giden paket, tailnet üzerinde eşleşen bir rota bulamaz; bu nedenle istemcinin varsayılan ağ geçidi üzerinden çıkar ve kaybolur.

İki komut, bu iki aşamayı birbirinden ayırır:

nslookup db.internal.example.com
ip route get 10.0.5.20

Eğer sorgulama bir adres döndürüyor ancak ip route get komutu dev tailscale0 ile yanıt vermiyorsa, isim doğrudur ancak rota eksiktir. Adresi kapsayan bir aralığı, yani 10.0.0.0/16 adresini veya ikinci bir açık öneki duyurun, ardından konsol üzerinden yeni öneki onaylayın.

İsim sunucusunun kendisinde de benzer bir tuzak bulunur. Yönetim konsolunda 10.0.0.53 gibi özel bir adreste genel bir isim sunucusu ayarlarsanız, bu adresin onaylanmış bir rota içinde yer alması gerekir; aksi takdirde cihazlarınız çözümleyiciye hiçbir şekilde ulaşamaz. Kimsenin ulaşamadığı bir çözümleyiciyi işaret ederken yerel DNS sunucularını geçersiz kılan seçeneği açarsanız, tailnet içindeki her cihaz, bir saniye önce çalışanlar dahil olmak üzere, anında isim çözümleme yeteneğini kaybeder. Önce çözümleyiciye giden rotayı duyurun ve onaylayın, ardından DNS ayarını değiştirin. Eğer tünel içindeki DNS ile ilgili sorunlar yaşıyorsanız, DNS'in WireGuard tüneli üzerinde bozulma şekli konusu, üzerindeki koordinasyon katmanı olmaksızın aynı mekanizmayı ele almaktadır.

Source NAT ve noktadan noktaya (site-to-site) bağlantılar

Varsayılan olarak subnet router, iletilen her paketin kaynak adresini kendi özel adresine göre yeniden yazar. Bu işlem SNAT (kaynak ağ adresi çevirisi) olarak adlandırılır ve özel ağ üzerinde herhangi bir değişiklik yapmadan yanıtların doğru yere ulaşmasını sağlar: 10.0.0.20 üzerindeki veritabanı, VPS'e yanıt verir; çünkü veritabanı VPS'e nasıl ulaşacağını zaten bilmektedir. Bunun dezavantajı, veritabanının tüm tailnet bağlantılarını VPS'ten geliyormuş gibi görmesidir; bu nedenle kaynağa dayalı güvenlik duvarı kuralları ve erişim günlükleri herhangi bir anlam ifade etmez.

İstemcinin gerçek tailnet adresinin korunmasını istediğinizde Linux üzerinde bu özelliği kapatın:

sudo tailscale set --snat-subnet-routes=false

Bu durumda özel ağdaki ana bilgisayarların, Tailscale'in cihazlara atadığı 100.64.0.0/10 aralığına geri dönen ve subnet router'ı işaret eden bir rotaya ihtiyacı vardır. Bu dönüş rotası olmazsa yanıtlar varsayılan ağ geçidine gider ve asla ulaşmaz; bu nedenle bağlantılar ilk paketten sonra askıda kalır. Özel ağın ağ geçidine statik bir rota ekleyin veya SNAT'i açık bırakın.

Noktadan noktaya (site-to-site) bağlantı, iki subnet router'ın aynı anda bu işlemi yapması, her birinin kendi ağını duyurması ve diğerininkini kabul etmesiyle gerçekleşir:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Diğer yönlendiricide kendi aralığıyla eşleşen komutu çalıştırın. İki aralık birbirinden farklı olmalıdır. ssh ve ping düzgün çalışırken büyük dosya transferleri duraksıyorsa, bunun nedeni TCP paketinin taşıdığı en büyük veri parçası olan MSS (maksimum segment boyutu) değeridir. Tünelin ek yükü, iletilen paketlerin aradaki bir bağlantı için çok büyük olmasına neden olur; bu durum MSS sıkıştırması (clamping) ile düzeltilir:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Bu kuralı iptables-persistent ile kaydedin, aksi takdirde bir sonraki önyüklemede kaybolacaktır.

Sistemin çalışır durumda kalmasını sağlayan rutin işlemler

Ağustos 2026 itibarıyla, node anahtarlarının süresi varsayılan olarak 180 gün sonra dolar. Bir subnet router üzerindeki anahtarın süresi dolduğunda, node oturumu kapatır ve yapılandırmada herhangi bir değişiklik olmamasına rağmen tüm duyurulan IP aralığı erişilemez hale gelir. Yönetim konsolundaki Machines sayfasından bu makine için anahtar süresi dolma özelliğini devre dışı bırakın ve bu işlemi yaptığınızı not edin.

Tailscale, eşler arasında doğrudan bağlantıyı tercih eder; doğrudan bağlantı kurulamadığında ise relay sunucularına geri döner. Relay sunucuları çalışır ancak gecikme süresini artırır. Genel IP adresine sahip bir VPS en kolay senaryodur: gelen UDP 41641 trafiğine izin verdiğinizde çoğu eş doğrudan bağlanabilir. Eğer güvenlik duvarını ufw yönetiyorsa, bir VPS'in gerçekten ihtiyaç duyduğu ufw kuralları gerekli sözdizimini açıklar.

Erişim kuralları işin diğer yarısıdır. Varsayılan bir tailnet üzerinde tüm cihazlarınız birbirine erişebilir, bu nedenle onaylanmış bir rota doğrudan çalışır. Bir ACL politikası yazdığınızda, kuralın hedef tarafı özel IP aralığını belirtmelidir; çünkü 10.0.0.20 bir tailnet adresi değildir ve tailnet IP'lerine veya etiketlerine göre yazılan kurallar tarafından kapsanmaz.

Son olarak, yönetmediğiniz bir koordinasyon sunucusu kullanıp kullanmayacağınıza karar verin. Tailscale'in kontrol düzlemi barındırılan bir servistir. Anahtarlarınız makinelerinizde kalır ancak hesap ve politika dosyası orada barındırılır. Ele geçirilmiş bir kontrol düzlemi veya çalınmış bir kimlik bilgisi ile birinin neler yapabileceği, özel ağınıza bir rota eklemeden önce değerlendirilmesi gereken bir konudur; Tailscale'in güven modeli bu sınırın nerede olduğunu belirtir. Maliyet nadiren insanları bu sistemden uzaklaştırır, çünkü ücretsiz plan, altı kullanıcıya kadar sınırsız sayıda kişisel cihazı kapsar; ancak bir etiket altında çalıştırdığınız bir subnet router, sizin adınıza oturum açılmış bir cihazdan farklı şekilde hesaplanır. Bu noktadan sonra faturalandırma makineler yerine kişiler üzerinden ilerler, bu nedenle ücretsiz plan bittiğinde bir hanenin veya beş kişilik bir ekibin ne kadar ödeyeceği, sınırı aşmanıza neden olacak hesabı eklemeden önce hesaplanmalıdır. Kendi kendine barındırılan Tailscale kontrol sunucusu Headscale'i çalıştırmak, bu kontrolü kendi VPS'inizde tutmanızı sağlar ancak bakım yükünü beraberinde getirir. Aynı endişeye yönelik diğer bir çözüm ise Tailscale istemcilerini tamamen bırakmaktır; NetBird VPN sunucusunu kendi kendine barındırmak, koordinasyon katmanını ve kendi mesh istemcilerini kontrol ettiğiniz tek bir makineye taşır. Eğer bu model ile elle yazılmış yapılandırma arasında karar veriyorsanız, WireGuard ve Tailscale karşılaştırması, koordinasyon katmanının size ne sağladığını ve maliyetinin ne olduğunu açıklar.

FAQ

Subnet router ile exit node arasındaki fark nedir?

Subnet router, özel adres aralıklarını duyurur; böylece Tailscale çalışmayan makineler tailnet cihazları tarafından erişilebilir hale gelir. Exit node ise kendisini tüm internete açılan bir yol olarak duyurur; bu sayede cihaz, tüm trafiğini o düğümün genel IP adresi üzerinden internete çıkarır. Bir VPS aynı anda her ikisi de olabilir. Bunlar --advertise-routes ve --advertise-exit-node gibi ayrı bayraklardır ve her birinin yönetici konsolunda ayrı ayrı onaylanması gerekir.

Linux istemcim neden duyurulan subnet rotasını görmezden geliyor?

Linux istemcileri, siz talep etmediğiniz sürece subnet rotalarını kabul etmez. İstemci üzerinde sudo tailscale set --accept-routes komutunu çalıştırın. Ardından ip route show ile değil, ip route show table 52 ile kontrol edin. Tailscale, kabul edilen rotaları 52 numaralı yönlendirme tablosuna ekler ve bunlara politika kuralları üzerinden erişir; bu nedenle ana tabloda listelenmezler ve çalışan bir rota eksikmiş gibi görünebilir.

Subnet rotam yeniden başlatma sonrasında çalışmayı durdurdu. Sorun nedir?

Büyük olasılıkla IP yönlendirme (IP forwarding) devre dışı kalmıştır. sysctl -w ile yapılan ayarlar yeniden başlatma sonrasında silinir; bu nedenle ayarı /etc/sysctl.d/99-tailscale.conf dosyasına yazın ve sysctl net.ipv4.ip_forward ile doğrulayın. Yönlendirme açık olduğu halde aralığa hala ulaşılamıyorsa, yönetici konsolundan düğümü kontrol edin. Düğüm anahtarları varsayılan olarak 180 gün sonra sona erer; süresi dolmuş bir subnet router, hesap sorunu yerine ağ hatası gibi görünebilir.

İki subnet router aynı aralığı duyurabilir mi?

Aynı aralıkları duyuramazlar. Farklı önek uzunluklarına sahip çakışan aralıklar kullanılabilir ve bu durumda en spesifik olan rota öncelik kazanır. Yedeklilik (failover) için dikkatli olunmalıdır: daha spesifik öneke sahip router çevrimdışı olduğunda, Tailscale otomatik olarak daha geniş olan rotaya geçiş yapmaz; bu nedenle trafik kesilir. Gerçek bir yedekli yapı için her iki router'ın da aynı spesifik önekleri duyurması gerekir.

Hostname çözümleniyor ancak bağlantı zaman aşımına uğruyor. Neden?

DNS çözümleme ve yönlendirme birbirinden bağımsız adımlardır. Bir isim, onaylanmış hiçbir rota tarafından kapsanmayan bir adrese çözümlenebilir; bu durumda paket, istemcinin varsayılan ağ geçidi üzerinden dışarı çıkar. İstemci üzerinde ip route get <address> komutunu çalıştırın. Eğer yanıt dev tailscale0 içermiyorsa, ilgili adresi kapsayan bir aralığı duyurun ve yönetici konsolunda yeni öneki onaylayın.