TR / EN

Tailscale ile Güvenli Uzak Masaüstü: İnternete RDP Açmadan Erişim

Bir bilgisayara uzaktan erişme ihtiyacı çoğu zaman “modemde port açalım” önerisiyle başlar. Sabit genel IP yoksa dinamik DNS eklenir, ardından RDP servisi doğrudan internetin taramasına ve parola denemelerine maruz kalır. Çalışan bir bağlantı elde edilir ama kimlerin, hangi cihazdan ve hangi koşulla bağlanabileceği yeterince yönetilmez. Erişim kolaylığı güvenlik borcuna dönüşür.

21 Temmuz 2026 tarihinde değerlendirdiğimiz vakada hedef, uzaktaki Windows iş istasyonuna iki yetkili cihazdan erişmekti. Tailscale ile cihazları kimlik tabanlı şifreli bir overlay ağa aldık; yönlendiricide inbound port açmadık. Yine de ürünü kurup “güvenli” etiketi vermekle yetinmedik. Tailnet üyeliği, ACL, Windows Firewall, RDP kullanıcı hakkı, MFA ve cihaz kaybı süreçlerini tek mimarinin parçaları olarak ele aldık.

Sorunun ortaya çıkışı

Uzak lokasyondaki iş istasyonu taşıyıcı NAT arkasındaydı ve sabit genel IP hizmeti yoktu. Kullanıcının seyahat sırasında kurumsal dizüstünden masaüstüne bağlanması gerekiyordu. Geleneksel port yönlendirme teknik olarak her bağlantıda mümkün değildi; mümkün olsa bile RDP’yi doğrudan yayınlamak kurumun güvenlik standardına aykırıydı. Tam ağ VPN’i ise tek cihazlık ihtiyaç için gereğinden geniş erişim sağlıyordu.

Tasarım hedeflerini baştan yazdık: internetten dinleyen RDP olmamalı, yalnızca tanımlı kullanıcı ve cihazlar bağlanabilmeli, erişim geri alınabilmeli, istemci ile hedef arasındaki trafik şifrelenmeli ve olay kaydı tutulmalıydı. Ayrıca merkezi servis kesintisi, cihaz kaybı ve kullanıcının kurumdan ayrılması halinde bağlantının nasıl sonlandırılacağı tanımlanmalıydı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, Tailscale kurulu iki cihazın otomatik olarak yalnızca birbirine güvenli erişeceğiydi. Varsayılan paylaşım davranışı ve ACL modeli incelenmeden tailnet üyeliği geniş bir iç erişim alanı yaratabilir. Şifreli tünel trafiğin gizliliğini sağlar; hedef Windows hesabının gereğinden fazla yetkili olmasını veya RDP servisindeki kötü yapılandırmayı düzeltmez.

İkinci varsayım, Windows Firewall kuralını tamamen açmanın gerekli olduğuydu. Tailscale arayüzü için uygun profil ve kaynak kapsamı tanımlanabilir; tüm fiziksel ağlardan RDP kabul etmek gerekmez. Tailscale IP’sini internete yönlendirilebilir genel adres sanmak da hatalıdır. Bu adres overlay içinde anlamlıdır ve istemcinin tailnet kimliği olmadan doğrudan erişilemez.

Teknik analiz

Önce her iki cihazın yönetim panelinde beklenen kullanıcıya, işletim sistemine ve cihaz kimliğine bağlı olduğunu doğruladık. Tailscale durumunda doğrudan eş bağlantı mı yoksa relay mi kullanıldığı gözlendi; relay performans farkı yaratabilir ancak uçtan uca şifrelemeyi kaldırmaz. Hedefin Tailscale adı ve overlay adresiyle erişimi, normal LAN adresinden ayrı test edildi.

Windows tarafında RDP servisinin etkinliği, NLA, izinli kullanıcı grubu ve firewall kural kapsamı incelendi. ACL değerlendirmesi kaynak kullanıcı/cihaz etiketi, hedef cihaz etiketi ve yalnızca gerekli RDP servisi üzerinden yapıldı. DNS adı kullanılıyorsa MagicDNS kolaylık sağladı, fakat isim çözümleme başarısı erişim yetkisiyle karıştırılmadı. Kayıtlarda gerçek cihaz adları yayın içeriğine alınmadı.

# Durum ve bağlantı tanısı; örnek adres dokümantasyon içindir
tailscale status
tailscale ping hedef-cihaz
Test-NetConnection -ComputerName 192.0.2.25 -Port 3389

Uygulanan çözüm veya önerilen mimari

Kimlik sağlayıcıda MFA zorunlu tutuldu ve iki cihaz onaylı tailnet’e kaydedildi. Hedef iş istasyonu ile yönetim dizüstüne rol etiketleri verildi; ACL yalnızca yönetim rolünden hedef RDP servisine erişime izin verdi. Windows Firewall kuralı Tailscale arayüzü ve gerekli kaynak kapsamıyla sınırlandı. RDP kullanıcısı yerel yönetici yapılmadan ilgili gruba eklendi ve NLA açık bırakıldı.

Yönlendiricide port yönlendirme bulunmadığı dışarıdan doğrulandı. Cihaz onay süresi, anahtar yenileme politikası ve kullanılmayan cihazların otomatik kaldırılması işletim prosedürüne eklendi. Kullanıcı ayrılışı halinde kimlik sağlayıcı oturumu, tailnet üyeliği ve Windows hesabı aynı kapanış kaydında ele alındı. Böylece erişim yalnızca teknik tünel değil, yönetilen bir yaşam döngüsü haline geldi.

Alternatifler ve karar gerekçesi

Kurumsal VPN, çok sayıda servis ve kullanıcı için merkezi politika avantajı sağlayabilirdi; tek hedefli bu vakada daha geniş ağ erişimi ve ek altyapı gerektiriyordu. RD Gateway, RDP’ye özel güçlü bir aracı katmandır ve büyük Windows ortamlarında iyi seçenektir. Mevcut ölçekte kimlik tabanlı overlay, daha küçük değişiklikle gereksinimi karşıladı.

Port yönlendirme ve IP allowlist seçeneği sabit kaynak adresi olmayan kullanıcıda sürdürülebilir değildi; ayrıca internet üzerinde servis bırakıyordu. Uzaktan destek ürünleri kullanıcı onaylı kısa oturumlar için değerlidir, fakat sürekli çalışma ortamına erişim ihtiyacı farklıydı. Tailscale seçimi koşulsuz ürün tercihi değil; kapsam, yönetim kapasitesi ve mevcut kimlik sağlayıcıyla uyum sonucuydu.

Güvenlik ve operasyonel riskler

Kimlik sağlayıcı hesabı ele geçirilirse tailnet erişimi de risk altına girer; MFA ve cihaz onayı bu nedenle zorunludur. ACL’de geniş yıldız kuralları şifreli ama aşırı yetkili bir ağ oluşturabilir. Kişisel cihazların kaydı, disk şifreleme ve ekran kilidi standardı yoksa veri sızıntısı doğurur. Cihaz etiketlerini kimin değiştirebildiği ayrı yönetici rolüyle sınırlandırılmalıdır.

Hedef cihaz uykuya geçerse veya Tailscale servisi başlamazsa erişim kesilebilir; bu durum güvenlik ihlaliyle karıştırılmamalıdır. Relay kullanımı gecikmeyi artırabilir. Acil durumda erişim için onaylı alternatif kanal ve yerel destek süreci belgelenmelidir. Tailscale güncellemeleri, Windows yamaları, RDP günlükları ve yönetim panelindeki cihaz envanteri periyodik olarak gözden geçirilmelidir.

Çıkarılan Dersler

Kontrol Listesi

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