Tailscale Exit Node Kurarken IP Forwarding ve NAT Neden Gereklidir?

Exit node olarak ilan edilen bir sunucunun yönetim panelinde yeşil görünmesi yanıltıcı bir başarı ölçütüdür. Bu durum sunucunun Tailscale kontrol düzlemine kayıtlı ve rotayı duyurmuş olduğunu gösterebilir; istemciden gelen paketi çekirdek içinde bir arayüzden diğerine aktarabildiğini veya dış ağın yanıtı geri döndürebildiğini göstermez. Veri düzlemindeki her halka ayrıca doğrulanmalıdır.

17 Temmuz 2026 tarihinde bir Ubuntu sunucuda tam olarak bu ayrımı yaşadık. İstemci exit node’u seçiyor, overlay üzerinden sunucuya erişiyor fakat internet trafiği ilerlemiyordu. Sorunu tek bir NAT komutuyla kapatmak yerine IP forwarding, nftables forward zinciri, kaynak adres çevirisi, varsayılan rota, ters yol filtresi ve Tailscale’in kendi netfilter yönetimini beraber inceledik. Kalıcı çözüm, hangi katmanın kime ait olduğunu belgelemekten geçti.

Sorunun ortaya çıkışı

Ubuntu cihaz exit node olarak duyurulmuş ve yönetici tarafından onaylanmıştı. İstemci bu düğümü seçtiğinde sunucunun Tailscale adresine erişebiliyor, fakat dış web ve DNS bağlantıları zaman aşımına uğruyordu. Exit node seçimi kaldırıldığında istemci kendi internet bağlantısını sorunsuz kullanıyordu. Bu karşılaştırma istemci uygulamasından çok, exit node üzerindeki ileri yönlendirme yolunu işaret etti.

Sunucunun kendisi internete çıkabiliyordu; bu da başka bir yanlış güven oluşturdu. Yerel süreçten çıkan paket OUTPUT yolunu, istemciden gelip aktarılacak paket ise FORWARD yolunu kullanır. İkincisi kernel yönlendirme izni, iki arayüz arasında firewall geçişi ve çoğu ağda kaynak NAT gerektirir. Sunucunun kendi bağlantısı bu koşulların hiçbirini tek başına sınamaz.

İlk belirtiler ve yanlış varsayımlar

İlk varsayım Tailscale’in her Linux dağıtımında tüm forwarding ve NAT ayrıntılarını otomatik yöneteceğiydi. Ürünün sürümü, netfilter modu, mevcut firewall yöneticisi ve kurumun elle yazılmış kuralları davranışı değiştirebilir. İkinci varsayım `net.ipv4.ip_forward=1` değerinin yeterli olduğuydu. Kernel aktarımı kabul etse bile forward zinciri paketi düşürebilir veya dönüş ağı overlay adresini tanımayabilir.

Sorunu çözmek için firewall’ı tamamen temizlemek önerildi; bu yöntem hem uzaktan erişimi kesebilir hem de sunucuyu korumasız bırakır. rp_filter değerini global olarak kapatmak da hızlı ama ölçüsüz bir müdahaledir. Önce paket sayacı, route kararı ve günlüklerle hangi aşamada kayıp olduğunu belirledik. Yalnızca ilgili arayüz ve akış için gerekçe oluşursa ayar değiştirilmeliydi.

Teknik analiz

sysctl üzerinden IPv4 ve gerekiyorsa IPv6 forwarding çalışma zamanı değerleri okundu. ip route get ile exit node’un dış hedefe hangi fiziksel arayüz ve kaynak adresle çıkacağı doğrulandı. nft list ruleset çıktısında Tailscale tarafından yönetilen zincirler ile kurum kuralları ayrıştırıldı; forward kabulü ve postrouting masquerade sayaçları test sırasında gözlendi. Gerçek kullanıcı trafiği yerine kontrollü dokümantasyon hedefi kullanıldı.

Paket yakalama gerektiğinde yalnızca bakım penceresinde, dar host ve protokol filtresiyle iki arayüzde başlık seviyesinde gözlem yapıldı; içerik toplanmadı. Tailscale arayüzüne gelen fakat fiziksel arayüzden çıkmayan paket forward politikasını, çıkıp yanıtsız kalan paket NAT veya üst ağ yolunu düşündürür. Yanıt fiziksel arayüze geliyor ama overlay’e dönemiyorsa conntrack, rp_filter ve dönüş kuralları incelenir.

# Salt okunur exit node tanısı
sysctl net.ipv4.ip_forward
ip route get 203.0.113.30
sudo nft list ruleset
tailscale status
tailscale netcheck

Uygulanan çözüm veya önerilen mimari

Forwarding kalıcı sysctl yapılandırmasında etkinleştirildi ve yeniden yükleme sonrası doğrulandı. nftables içinde yalnızca Tailscale arayüzünden gelen, yerleşik bağlantı durumunu izleyen ve onaylı dış arayüze giden trafik için forward politikası tanımlandı. Overlay kaynakları fiziksel ağda yönlendirilmediğinden çıkışta masquerade uygulandı. Tailscale’in yönettiği zincirlerle çakışmamak için kural sahipliği açıkça belgelendi.

İstemci exit node seçimi ACL ve yönetim onayına bağlandı; herkesin keyfi çıkış düğümü kullanmasına izin verilmedi. DNS davranışı ayrıca test edildi çünkü çıkış çalışırken split DNS politikası farklı sonuç üretebilir. Sunucu yeniden başlatıldıktan sonra forwarding, NAT sayaçları ve istemci dış adres doğrulaması tekrarlandı. İzleme sistemine servis durumu yanında veri düzlemi sentetik testi eklendi.

Alternatifler ve karar gerekçesi

Üst yönlendiriciye Tailscale adres aralığı için dönüş rotası eklemek, NAT ihtiyacını kaldırabilir ve kaynak görünürlüğünü korur. Ancak mevcut ağda bu rota tüm dönüş yoluna güvenli biçimde dağıtılamıyordu; sınırlı exit node kapsamı için masquerade daha uygulanabilirdi. Kaynak izlenebilirliğinin kritik olduğu büyük yapılarda yönlendirilmiş model yeniden değerlendirilmelidir.

Sunucuyu tam bir ağ geçidi dağıtımıyla değiştirmek daha güçlü yüksek erişilebilirlik ve politika özellikleri sağlayabilir. Bu vakada az sayıda yetkili kullanıcı ve kontrollü kullanım için mevcut Ubuntu düğümü yeterliydi. iptables ile kural yazmak mümkün olsa da platform standardı nftables idi. İki araç katmanını karıştırmak yerine tek yönetim kaynağı seçerek yeniden başlatma sonrası öngörülebilirliği artırdık.

Güvenlik ve operasyonel riskler

Exit node kullanıcının tüm internet trafiği için güven sınırı haline gelir. Düğüm yöneticisi, DNS ve bağlantı metadatası bakımından hassas bir konumdadır; günlük saklama, yetkili erişim ve gizlilik beklentileri yazılı olmalıdır. Geniş forward kuralı sunucuyu iki ağ arasında istenmeyen router’a çevirebilir. Yönetim servisleri ile transit trafik aynı politika içinde bırakılmamalıdır.

Tek exit node bakım veya bağlantı kesintisinde kullanıcıları internetsiz bırakabilir. Kapasite, CPU, bağlantı tablosu ve uplink kullanımı izlenmeli; otomatik seçim varsa beklenen coğrafi ve yasal çıkış noktası doğrulanmalıdır. Firewall aracı güncellendiğinde Tailscale kurallarıyla sıra değişebilir. Her sürüm ve kural değişikliğinden sonra hem izinli akış hem de engellenmesi gereken erişim test edilmelidir.

Çıkarılan Dersler

Kontrol Listesi