VPS Uzerinde Tailscale Subnet Router Kurulumu

Tailscale subnet router ne işe yarar

Tailscale subnet router, tüm bir özel IP adresi aralığını tailnet ağınıza duyuran tek bir makinedir; böylece o aralıktaki hiçbir cihazda Tailscale çalışmasa bile tailnet üzerindeki her cihaz bu adreslere erişebilir. Tailnet, tek bir hesaba veya organizasyona bağlı cihazlar kümesinden oluşan özel Tailscale ağınızdır. İnsanların genellikle karıştırdığı exit node özelliği ise tam tersi bir işlev görür. Bir cihazın tüm trafiğini VPS üzerinden dışarı gönderir, böylece VPS o cihazın genel internete çıkış noktası haline gelir.

Her biri tek cümledir. Subnet router, bir özel ağı tailnet üzerinden erişilebilir kılar. Exit node ise genel internet trafiğinizin çıkış noktasını değiştirir. Eğer istediğiniz ikinci seçenek ise, bunun yerine VPS üzerinde Tailscale exit node çalıştırma rehberini okuyun. Bunlar farklı flag değerleridir 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 sağladığı özel 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 genel IP 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 IP adresi almaz.

Diğer durum ise VPS'in ötesindeki bir ağdır. Kendi yönlendiricisi arkasındaki bir ev veya ofis yerel ağı (LAN) ya da yönetilebilir bir switch veya kilitli yazılıma sahip eski bir NAS gibi Tailscale çalıştıramayan cihazlardan oluşan bir kabin olabilir. O ağdaki bir Linux makinesi, ağdaki diğer her şey için subnet router görevi görür.

Her iki durum da tek bir gereksinimi paylaşır. Subnet router, kendi yönlendirme tablosunu ve güvenlik duvarını kullanarak duyurduğu ağ aralığına zaten erişebiliyor olmalıdır. Tailscale bu bağlantıyı oluşturmaz. 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. Durumu systemctl is-active tailscaled ile doğrulayın; bu komut active çıktısını vermelidir.

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, özel IP aralığını gerçek bir arayüz üzerinde listelemelidir; örneğin 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5 gibi. Eğer ping işlemi burada, yani yönlendiricinin kendisinde başarısız olursa, hiçbir Tailscale bayrağı sorunu çözmeyecektir. Sorun, VPS ağ yapılandırmasında veya hedef ana makine üzerindeki bir güvenlik duvarındadır. Bunu öncelikle düzeltin, çünkü sonraki tüm testler buna bağlıdır.

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

Bir Linux makinesi, yönlendirme açık olmadığı sürece kendisine adreslenmemiş tüm paketleri düşürür. 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

Bunu 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 komutu anında sonuç verir ancak bir sonraki yeniden başlatmada ayarlar kaybolur; bu yüzden alt ağ yönlendiricisi haftalarca çalışır ve çekirdek güncellemesi sonrası yapılan bir yeniden başlatmanın ardından durur. Kafa karıştırıcı 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ı göz ardı etmek yerine mutlaka okuyun.

Rotaları duyurma

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

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

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

Daha sonraki her değişiklik için tailscale set kullanın. tailscale up komutunu tek bir bayrakla yeniden çalıştırmak, belirtmediğiniz bayrakları sıfırlar; bu durumda CLI, ayarları bu şekilde değiştirmenin varsayılan olmayan tüm bayrakların belirtilmesini gerektirdiğini belirten bir hata ile işlemi durdurur. tailscale set ise tek bir ayarı değiştirir ve diğerlerine dokunmaz.

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. Yanlışlıkla kendi ana makine adresinizi yazmak, yani 10.0.0.5/24, önekten sonraki bitler sıfır olmadığı için 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 niteliğindedir, 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 herhangi bir aralık için ağ trafiğini 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 işlemi önek (prefix) bazlı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 geçmeden ö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, yani sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router ile 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 olarak 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 değerini sessizce eklemek, makinenin halihazırda yönettiği trafiği bozabilir. Bu nedenle Linux üzerinde her istemci için ayrı ayrı onay vermeniz 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 koyar ve eşleşmeyen paketleri bu tabloya gönderen, ip rule show ile 5210 ile 5270 öncelik aralığında görülebilen ilke kuralları yükler. Bu yüzden ip route show tek başına asla 10.0.0.0/24 değerini listelemez ve sadece 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 kendi doğrudan bağlı alt ağına giden trafiği kendi arayüzü yerine diğer yönlendirici üzerinden göndermesine neden olur. Yüksek erişilebilirlik çiftindeki yedek bir yönlendiricide, --accept-routes seçeneğini kapalı tutun ve sadece 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. A yönlendiricisi 10.0.0.0/24 ve B yönlendiricisi 10.0.0.0/16 duyurusu yapıyorsa, 10.0.0.20 adresine giden trafik A'ya yönlendirilir.

Kullanıcıları şaşırtan durum, A çevrimdışı olduğunda yaşanan davranıştır. Tailscale daha az spesifik olan rotaya otomatik geçiş yapmaz. 10.0.0.20 adresine giden trafik dururken, 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 tutmasıdır. Yedeklilik (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 duyurusu yapıyorsa, bu ikisi 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 ekleyin:

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 kaybolur. 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, aynı nedenden dolayı elle yapılandırdığınız standart bir WireGuard VPN bağlantısını da 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 yerde bir hata raporlanmaz. İsim çözümlenir ancak 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 bağımsız adımlar olduğundan ve birbirlerini kontrol etmediklerinden, sorgu başarılı olur. Ardından 10.0.5.20 adresine gönderilen 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 sorgu bir adres döndürüyor ancak ip route get komutu dev tailscale0 ile yanıt vermiyorsa, isim çözünürlüğü doğrudur ancak rota eksiktir. Ya 10.0.0.0/16 adresini ya da ikinci bir açık öneki kapsayan bir aralık duyurun, ardından konsol üzerinden yeni öneki onaylayın.

İsim sunucusunun kendisinde de benzer bir tuzak mevcuttur. Yönetim konsolunda 10.0.0.53 gibi özel bir adreste küresel 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ümleyiciye işaret ederken yerel DNS sunucularını geçersiz kılan seçeneği açarsanız, bir saniye öncesine kadar çalışanlar dahil olmak üzere tailnet üzerindeki tüm cihazlar anında isim çözünürlüğünü kaybeder. Önce çözümleyiciye giden rotayı duyurup 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ı açıklamaktadır.

Source NAT ve noktadan noktaya bağlantılar

Varsayılan olarak subnet router, iletilen her paketin kaynak adresini kendi özel adresiyle değiştirir. Bu işlem SNAT (kaynak ağ adresi çevirisi) olarak adlandırılır ve özel ağ üzerinde herhangi bir değişiklik yapılmasına gerek kalmadan yanıtların doğru yere ulaşmasını sağlar: 10.0.0.20 üzerindeki veritabanı, zaten nasıl ulaşacağını bildiği VPS'e yanıt verir. 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 anlamlı veri sağlamaz.

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

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

Ö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 bunu yapması, her birinin kendi ağını duyurması ve diğerininkini kabul etmesidir:

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

Eşleşen komutu diğer router üzerinde kendi aralığıyla çalıştırın. İki aralık birbirinden farklı olmalıdır. ssh ve ping düzgün çalışırken büyük dosya aktarımları duruyorsa, bunun nedeni TCP paketinin taşıdığı en büyük veri parçası olan MSS (maximum segment size) 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 "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 silinir.

Sistemin çalışır durumda kalmasını sağlayan bakım işlemleri

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 ağ aralığı erişilemez hale gelir. Yönetim konsolundaki Machines sayfasından bu makine için anahtar süresi dolumunu 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 ve doğrudan bağlantı kurulamadığında relay sunucularına geri döner. Relay sunucuları çalışır ancak gecikmeyi artırır. Genel IP adresine sahip bir VPS en kolay durumdur: gelen UDP 41641 trafiğine izin verin; böylece çoğu eş doğrudan bağlanacaktır. 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 ağ 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 kontrol düzlemi barındırılan bir servistir. Anahtarlarınız makinelerinizde kalır ancak hesap ve politika dosyası orada tutulur. Kendi kendine barındırılan Tailscale kontrol sunucusu Headscale'i çalıştırmak, bu yapıyı kendi VPS'inizde tutmanızı sağlar ancak bakım yükünü beraberinde getirir. Aynı endişeye yönelik diğer çözüm, Tailscale istemcilerini de bırakmak ve NetBird VPN sunucusunu kendi kendine barındırmak ile koordinasyon katmanını ve kendi mesh istemcilerini kontrol ettiğiniz bir makineye taşımaktır. Eğer hala 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 bir adres aralığı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. Tek bir VPS her iki görevi de üstlenebilir. Bunlar --advertise-routes ve --advertise-exit-node gibi ayrı bayraklardır ve her birinin yönetim konsolunda ayrı ayrı onaylanması gerekir.

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

Linux istemcileri, siz özellikle 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 ilke 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 ayarlanan değer yeniden başlatma sonrasında kalıcı olmaz; bu nedenle değeri /etc/sysctl.d/99-tailscale.conf dosyasına yazın ve sysctl net.ipv4.ip_forward ile doğrulayın. Eğer yönlendirme açık olduğu halde aralığa hala ulaşılamıyorsa, yönetim konsolundan düğümü kontrol edin. Düğüm anahtarları varsayılan olarak 180 gün sonra sona erer; süresi dolmuş bir subnet router, hesap sorunundan ziyade bir 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 en spesifik olan rota öncelik kazanır. Yük devretme (failover) işlemi dikkat gerektirir: 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ını sağlayın.

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önetim konsolunda yeni öneki onaylayın.