Web Konsolunda Açılan Windows Oturumu RDP ile Neden Açılmaz?

Aynı kullanıcı adı ve parola bir ekranda çalışıp diğerinde reddedildiğinde insan doğal olarak parolanın doğru olduğunu düşünür. Bu çıkarım kısmen doğrudur fakat yeterli değildir. Sanallaştırma platformunun web konsolu fiziksel klavye ve ekranın uzaktan karşılığı gibi davranırken RDP, ağ üzerinden gelen ayrı bir protokol, oturum türü, kimlik sağlayıcı ve kullanıcı hakkı zincirinden geçer. Başarı ölçtüğümüz yollar aynı değildir.

Çok lokasyonlu bir kurumda 20 Temmuz 2026 tarihinde yaşanan olayda Windows sunucu konsoldan yönetilebiliyor, doğrudan RDP denemesi ise daha oturum açılmadan kesiliyordu. Rastgele politika gevşetmek yerine bağlantıyı ağ erişimi, RDP dinleyicisi, NLA ön kimlik doğrulaması, hesap çözümleme ve oturum açma hakkı katmanlarına böldük. Bu ayrım, hem kök nedeni bulmayı hem de güvenlik seviyesini düşürmeden müdahale etmeyi sağladı.

Sorunun ortaya çıkışı

Bakım ekibi web tabanlı hipervizör konsolundan sunucuya yerel bir hesapla girebiliyordu. Aynı görünen bilgiler RDP istemcisinde kullanıldığında genel bir kimlik doğrulama hatası alınıyordu. Sunucu yeniden başlatılmış, RDP daha önce kullanılmış ve ağ adresi değişmemişti. İş kritik olduğu için hızlı erişim gerekiyordu; ancak NLA kapatmak veya herkesi yönetici yapmak kabul edilebilir bir kısayol değildi.

Önce RDP istemcisinin gerçekten doğru sunucuya ulaştığını doğruladık. İsim çözümleme yerine onaylı yönetim kaydı, sertifika bilgisi ve hedef sistem kimliği karşılaştırıldı. TCP bağlantısının kurulabilmesi yalnızca dinleyiciye ulaşmayı kanıtladı; kimliğin kabul edildiğini göstermedi. Konsol açık olduğu için sunucu içinden servis, politika ve olay günlüklerini güvenli biçimde inceleme avantajımız vardı.

İlk belirtiler ve yanlış varsayımlar

“Parola konsolda çalışıyor, RDP de kabul etmeli” varsayımı hesap adının nasıl çözümlendiğini atlıyordu. Kısa kullanıcı adı istemci tarafında kayıtlı etki alanı, hedef bilgisayar veya Microsoft hesabı bağlamında yorumlanabilir. Yerel hesap için HEDEFkullanici biçimi ile domain hesabı için DOMAINkullanici aynı kimliği göstermez. Görünen profil klasörü de hesabın kesin oturum açma adı değildir.

İkinci yanlış yaklaşım güvenlik duvarını tamamen kapatıp denemekti. Bağlantı NLA aşamasına geliyorsa port yolu büyük ölçüde çalışıyordur; hata kaydı daha değerli kanıt sunar. Benzer şekilde NLA’yı devre dışı bırakmak eski istemci uyumsuzluğunu ayırabilir ama kalıcı çözüm değildir. Önce istemci saati, kayıtlı kimlik bilgisi ve kullanıcı adı bağlamı gibi düşük riskli olasılıkları eledik.

Teknik analiz

Sunucuda Remote Desktop Services durumu, RDP-Tcp dinleyicisi ve ilgili Windows Firewall profil kuralları kontrol edildi. Ardından Security ve TerminalServices günlüklarında deneme anına karşılık gelen kayıtlar incelendi. Başarısız oturum türü, hesap adı, durum ve alt durum kodları; yanlış parola, bilinmeyen kullanıcı, izin verilmeyen oturum veya NLA uyuşmazlığını birbirinden ayırdı. Günlük verisi dışarı paylaşılmadan olay kaydında maskelendi.

Yerel Güvenlik İlkesi veya uygulanan GPO içinde “Allow log on through Remote Desktop Services” ve “Deny log on through Remote Desktop Services” haklarını birlikte değerlendirdik. Remote Desktop Users grubu üyeliği tek başına yeterli olmayabilir; deny hakkı önceliklidir. Domain güveni, saat farkı ve kullanıcı kilitlenmesi de kontrol edildi. Ağ tarafında yalnızca izinli yönetim segmentinden hedef porta erişim ölçüldü.

# Yerel konsolda, salt okunur PowerShell kontrolleri
Get-Service -Name TermService
Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq 3389
Get-LocalGroupMember -Group 'Remote Desktop Users'

Uygulanan çözüm veya önerilen mimari

Vakadaki hesap yereldi ancak istemci eski domain bağlamını kullanıyordu. Kimlik bilgisi kasasındaki hedefe bağlı eski kayıt kaldırıldı ve kullanıcı adı açıkça hedef bilgisayar bağlamıyla girildi. Hesap, ayrıcalıklı yönetici grubuna eklenmeden Remote Desktop Users grubuna dahil edildi; GPO ile gelen deny hakkı olmadığı doğrulandı. Başarılı oturumdan sonra başarısız denemelerin kilitlenme sayacı ve olay kaydı gözden geçirildi.

Kalıcı mimaride RDP yalnızca yönetim ağı veya kimlik tabanlı özel ağ üzerinden erişilebilir tutuldu. Yönetici ve standart uzaktan erişim rolleri ayrıldı, NLA açık bırakıldı ve MFA sağlayan yönetim geçidi değerlendirildi. Hesap açma süreci grup tabanlı hale getirildi; kişiye özel firewall istisnası veya yerel yönetici üyeliği yerine merkezi, süreli ve denetlenebilir yetkilendirme kullanıldı.

Alternatifler ve karar gerekçesi

NLA’yı kapatmak bağlantıyı geçici olarak mümkün kılabilirdi, fakat kimlik doğrulama öncesi daha fazla oturum kaynağı tüketir ve saldırı yüzeyini büyütürdü. Sorun eski istemciden kaynaklanmıyorsa hiçbir kök nedeni de çözmezdi. Hesabı Administrators grubuna almak yetki sorununu maskeleyebilirdi; görev için gereksiz ayrıcalık oluşturacağı için bu seçenek reddedildi.

Web konsolunu sürekli yönetim kanalı olarak kullanmak ağdaki RDP sorununu atlatır, ancak konsol platformundaki güçlü ayrıcalıkları günlük operasyona taşır. RD Gateway, VPN veya overlay ağ seçenekleri kurum ölçeğine göre değerlendirildi. Mevcut kontrollü yönetim ağı ve az sayıdaki yetkili kullanıcı için grup tabanlı RDP yeterliydi; internetten doğrudan yayın ise hiçbir senaryoda seçilmedi.

Güvenlik ve operasyonel riskler

Tekrarlanan denemeler hesabı kilitleyebilir ve hizmet hesabıyla ortak kimlik kullanılıyorsa uygulamayı da etkileyebilir. Bu yüzden deneme sayısı sınırlandı, her değişiklikten sonra tek kontrollü giriş yapıldı. Güvenlik günlükları kullanıcı adı, kaynak adresi ve domain bilgisi içerebildiği için destek kaydına ham halde konmadı. Konsol erişimi de acil durum yetkisi olarak denetlendi.

RDP’nin tüm ağ profillerinde açılması veya geniş kaynak aralığına izin verilmesi operasyonu kolaylaştırırken kalıcı risk üretir. Erişim kaynağı sınırlandırılmalı, hesap yaşam döngüsü izlenmeli, güçlü parola ve MFA politikaları uygulanmalıdır. Sertifika uyarısını görmezden gelmek yanlış hedefe kimlik bilgisi gönderme riski taşır. İzleme, başarısız giriş artışı ile beklenmeyen grup üyeliği değişikliklerini birlikte takip etmelidir.

Çıkarılan Dersler

Kontrol Listesi

Windows masaüstünde görülen ad, profil klasörü ve whoami çıktısı aynı kullanıcıyı anlatıyor gibi görünse de farklı ad alanlarından gelir. Özellikle yerel hesap sonradan Microsoft hesabına bağlandığında bu fark RDP istemcisinde belirginleşir. Kullanıcı cihazın başında PIN ile rahatça oturum açarken uzaktan bağlantıda aynı PIN reddedilir; kısa profil adıyla yapılan deneme de başka bir yerel hesaba yönlenebilir.

21 Temmuz 2026 tarihli bir destek çalışmasında çözüm, parolayı tekrar tekrar sıfırlamak değil kimliğin hangi sağlayıcı tarafından doğrulandığını belirlemekti. RDP için kullanıcı adını `MicrosoftAccounthesap` bağlamında vermek, çevrim içi hesabın gerçek parolasını kullanmak ve istemcideki eski kayıtları temizlemek gerekiyordu. Bu basit görünen ayrıntının arkasında Windows Hello, yerel kimlik bilgisi ve ağ kimlik doğrulamasının farklı güven sınırları bulunuyor.

Sorunun ortaya çıkışı

Uzak çalışan bir kullanıcı Windows 11 bilgisayarına kimlik tabanlı özel ağ üzerinden erişebiliyor, RDP oturumu açarken kimlik bilgisi hatası alıyordu. Fiziksel cihazda PIN kabul ediliyor, hesap ayarlarında Microsoft hesabına bağlı bir e-posta görünüyordu. whoami ise kısa ve daha eski bir yerel ad döndürüyordu. Üç farklı gösterim destek ekibinin hangi değeri kullanacağı konusunda belirsizlik yarattı.

Ağ yolu ve RDP servisi sağlıklıydı; hata NLA kimlik doğrulama aşamasındaydı. Kullanıcı gizli bilgisini destek görevlisine iletmeden, ekranda gördüğü hesap türünü tarif etti. Amaç yeni bir yönetici hesabı açmak veya mevcut hesabı dönüştürmek değildi. Önce var olan kimliğin doğru sözdizimi ve geçerli parola türüyle kullanılabilir olup olmadığını kontrollü biçimde sınadık.

İlk belirtiler ve yanlış varsayımlar

En belirgin yanlış varsayım PIN’in parola olduğuydu. Windows Hello PIN’i cihazdaki güvenli donanım ve kullanıcı profiliyle ilişkilidir; uzaktaki RDP kimlik doğrulamasında hesaba ait ağ parolası yerine geçmez. PIN’in kısa olması zayıf bir ağ parolası olduğu anlamına da gelmez, çünkü cihaz dışına taşınan ortak bir sır değildir. RDP istemcisinin beklediği bilgi farklıdır.

Profil klasörü adını kullanıcı adı kabul etmek de yanıltıcıydı. Windows ilk kurulum sırasında klasörü kısaltabilir ve hesap sonradan değişse bile klasör adı aynı kalabilir. whoami çıktısı güvenlik sorumlusunun yerel temsilini gösterir; Microsoft hesabına giriş biçimini tek başına açıklamaz. Ayrıca istemci, daha önce kaydettiği `PCADIkullanici` bilgisini yeni girişin üzerine sessizce uygulayabilir.

Teknik analiz

Hesaplar bölümünde oturumun yerel mi, Microsoft hesabı mı olduğu doğrulandı. `whoami /user` ile SID kaydedildi; yalnızca görünen ad değişikliklerinin ayrı hesap oluşturup oluşturmadığı bu sabit kimlik üzerinden değerlendirildi. Yerel Users ve Remote Desktop Users üyelikleri kontrol edildi. Olay günlüğünde gelen hesap adının hangi paket tarafından nasıl çözümlendiği, gerçek adres veya kişisel hesap bilgisi dışarı aktarılmadan incelendi.

RDP istemcisinde üç bağlamın karıştırılmaması gerekir: yerel hesap için `BILGISAYARkullanici` veya `.kullanici`, domain için `DOMAINkullanici`, Microsoft hesabı için `MicrosoftAccounthesap_adresi`. Buradaki hesap adresi gerçek yayında gösterilmemeli ve ekran görüntüsünde maskelenmelidir. Entra katılımlı kurumsal cihazların sözdizimi ve politikası farklı olabileceğinden Microsoft kişisel hesabı ile aynı vaka sayılmamalıdır.

:: Kimlik türünü anlamaya yardımcı, değişiklik yapmayan komutlar
whoami
whoami /user
whoami /groups
net localgroup "Remote Desktop Users"

Uygulanan çözüm veya önerilen mimari

İstemcide hedef bilgisayara bağlı eski kimlik kaydı Windows Credential Manager üzerinden kaldırıldı. Kullanıcı adı alanına açıkça `[email protected]` biçiminde dokümantasyon hesabı model alınarak gerçek hesap kullanıcı tarafından girildi; PIN yerine Microsoft hesabı parolası kullanıldı. Kullanıcı parolayı destek ekibiyle paylaşmadı. Bağlantı başarılı olduktan sonra sunucudaki SID ile açılan oturumun beklenen profile ait olduğu doğrulandı.

Kurumsal kullanım için kişisel Microsoft hesaplarıyla sürekli yönetim erişimi önermiyoruz. Yönetilen cihazlarda merkezi kimlik, MFA, koşullu erişim ve hesap yaşam döngüsü sağlayan kurumsal model tercih edilmeli. Ev veya sınırlı senaryoda kişisel hesap kullanılacaksa ayrı bir standart erişim hesabı, kısıtlı RDP grubu ve özel ağ yolu düşünülebilir. Her durumda internetten doğrudan RDP yayını yapılmamalıdır.

Alternatifler ve karar gerekçesi

Yeni yerel hesap açmak sorunu hızlıca aşabilirdi. Ancak fazladan hesabın parolası, üyelikleri ve kapanış süreci yönetilmediğinde uzun vadeli risk doğurur. Mevcut Microsoft hesabının doğru biçimle çalıştığını doğrulamak en küçük değişiklikti. Hesabı yerel hesaba çevirmek de profil ve uygulama davranışını etkileyebileceğinden yalnızca RDP problemi için uygun görülmedi.

Kaydedilmiş kimlik bilgilerini tamamen kapatmak bazı yüksek güvenlikli ortamlarda doğru politika olabilir; bu vakada yalnızca hatalı hedef kaydı temizlendi. Remote Desktop yerine uzaktan yardım aracı kullanmak kullanıcı destek senaryosunda avantaj sağlayabilir, ancak sürekli yönetim oturumunun yerini her zaman tutmaz. Karar, erişim amacı, denetlenebilirlik ve kurumun kimlik standardına göre verilmelidir.

Güvenlik ve operasyonel riskler

Kişisel e-posta adresi bir kimlik verisidir; destek kaydı, ekran görüntüsü ve komut çıktısında açık bırakılmamalıdır. Parola hiçbir zaman sohbet veya uzak destek notuna yazılmamalı, kullanıcı tarafından güvenilir istemciye girilmelidir. Tekrarlı yanlış denemeler hesap kilidi ve şüpheli giriş uyarıları üretebilir. Hedef sertifikası doğrulanmadan kimlik bilgisi gönderilmemelidir.

Microsoft hesabı parolasının yakın zamanda değişmesi, cihazın çevrim dışı önbelleği ile ağ doğrulaması arasında geçici fark yaratabilir. Kurtarma yöntemleri güncel tutulmalı, yerel acil durum hesabı varsa kasada ve denetimli olmalıdır. RDP erişimi yalnızca izinli cihaz ve ağlarla sınırlandırılmalı; kullanıcı Remote Desktop Users grubundan ayrıldığında erişimin gerçekten kalktığı periyodik olarak test edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

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

“Bütün ağı bulalım” cümlesi iyi bir envanter hedefi gibi duyulur, ancak kapsam tek bir çok geniş CIDR ile ifade edildiğinde teknik anlamı değişir. Milyonlarca olası adresin çoğu kullanılmıyor olabilir; uzak lokasyonlar düşük bant genişlikli tünellerle bağlıdır ve bazı endüstriyel cihazlar yoğun sorguya dayanacak şekilde tasarlanmamıştır. Daha fazla adres taramak her zaman daha fazla doğru bilgi üretmez.

20 Temmuz 2026 tarihinde çok lokasyonlu bir kurum için otomatik keşif konuşurken, tek seferlik geniş tarama yerine bilinen subnet envanterinden başlayan bir program tasarladık. Amaç tarama aracı çalıştırmak değil, sahibi belli ve güncel bir varlık görünümü oluşturmaktı. Bunun için adres uzayını lokasyon, güven bölgesi ve cihaz hassasiyetine göre böldük; pasif kaynaklarla doğruladık ve aktif kontrolleri değişiklik yönetimine bağladık.

Sorunun ortaya çıkışı

Merkez, uzak ofisler, üretim ve saha ağlarında hangi cihazların bulunduğu tek ekranda bilinmiyordu. Öneri, özel adres uzayının büyük bir bölümünü merkezi izleme sunucusundan taratıp otomatik envanter çıkarmaktı. Bu yaklaşım kolay başlıyor görünse de hedef sayısı, tünel kapasitesi, tekrar sıklığı ve cihaz tipleri hesaplanmamıştı. Yetkili kapsam ile teknik olarak yönlendirilebilir kapsam da birbirine karıştırılmıştı.

Envanter eksikliğinin nedeni yalnızca keşif yapılmaması değildi. IP adres yönetimi, DHCP kiraları, switch komşulukları ve saha teslim kayıtları farklı ekiplerdeydi. Geniş tarama bu yönetişim açığını kapatmayacak, yalnızca çok sayıda geçici yanıt üretecekti. Önce hangi soruya cevap aradığımızı belirledik: canlı host sayısı mı, yönetilebilir cihazlar mı, servis görünürlüğü mü, yoksa sahiplik bilgisi mi?

İlk belirtiler ve yanlış varsayımlar

İlk varsayım yanıt vermeyen adresin boş olduğuydu. Host firewall, ICMP politikası, uyku modu veya tek yönlü rota nedeniyle aktif cihaz sessiz kalabilir. Tersi de mümkündür: NAT, proxy ya da geçici istemci yanıt verir ancak kalıcı envanter varlığı değildir. Tek protokol ve tek zaman dilimi ile yapılan keşif bu nedenle hem eksik hem de gürültülüdür.

İkinci varsayım düşük hız ayarının tüm operasyonel riski kaldıracağıydı. Çok geniş hedef kümesi düşük hızda bile günler sürebilir, güvenlik cihazlarında oturum tablosu ve alarm yükü oluşturabilir. WAN optimizasyonu, uydu bağlantısı veya endüstriyel ağ geçidi beklenmeyen davranış gösterebilir. Tarama izni de “kurum ağı” gibi belirsiz bir ifadeyle değil subnet, protokol, zaman ve kaynak sistemiyle tanımlanmalıdır.

Teknik analiz

CIDR büyüklüğünü önce adres sayısına, sonra gerçek paket ve süre bütçesine çevirdik. Her hedefe yalnızca bir sorgu gitmeyeceği; tekrar, port, zaman aşımı ve servis tanıma adımlarının yükü katlayacağı görüldü. Merkezi kaynaktan yapılan taramanın her lokasyon tünelini iki yönlü kullanacağını ve gecikmenin toplam işi uzatacağını hesapladık. Üretim ağı için aktif test toleransı ayrıca sorgulandı.

Pasif kaynaklar daha düşük riskle güçlü başlangıç sağladı: IPAM kayıtları, DHCP kiraları, yönlendirici ARP/ND tabloları, switch MAC tabloları, DNS ve mevcut NMS verisi eşleştirildi. Sonuçlar lokasyon ve VLAN bazında normalize edildi. Aktif keşif yalnızca bu bilinen subnetleri doğrulamak, boşlukları ölçmek ve yönetim protokollerini tanımak için kullanıldı; rastgele servis denemesi veya yetkisiz zafiyet taraması yapılmadı.

Uygulanan çözüm veya önerilen mimari

Her lokasyon için sahibi, amacı, kritikliği ve bakım penceresi yazılı subnet listesi oluşturuldu. Keşif işleri küçük bloklara bölündü; uzak sahalarda merkezi tarama yerine yerel poller kullanılarak tünel trafiği azaltıldı. Önce ICMP veya güvenli yönetim protokolü gibi düşük etkili sinyaller, sonra yalnızca tanımlı cihaz sınıfları için servis doğrulaması planlandı. Endüstriyel segmentler üretici ve OT sorumlusu onayı olmadan aktif kapsama alınmadı.

Sonuçlar otomatik olarak üretim envanterine kesin kayıt olarak yazılmadı. Yeni bulunan varlıklar sahiplik, seri bilgi kaynağı ve lokasyon verisiyle doğrulama kuyruğuna alındı. Tarama zamanı, kaynak düğüm, kapsam ve sürüm olay kaydında tutuldu. Günlük küçük delta keşfi ile daha seyrek kapsamlı doğrulama ayrıldı; böylece hem güncellik hem de öngörülebilir trafik sağlandı.

Alternatifler ve karar gerekçesi

Yalnızca agent tabanlı envanter ayrıntılı işletim sistemi verisi sağlayabilir, fakat agent yüklenemeyen ağ cihazlarını ve sahipsiz varlıkları göremez. Sadece pasif keşif operasyonu etkilemez; trafiği sensöre ulaşmayan veya uzun süre sessiz kalan cihazları kaçırır. Bu nedenle pasif veriyle kapsam oluşturup düşük etkili aktif doğrulamayla tamamlayan hibrit model seçildi.

Tek merkezi tarayıcı yönetimi kolaylaştırır ancak uzak bağlantıları gereksiz kullanır ve kaynak adresi tüm sahalarda aynı görünür. Dağıtık poller modeli ek bakım getirir; buna karşılık lokasyon içi gecikme ve trafik kontrolü sağlar. Kurumun çok lokasyonlu yapısında bu maliyet kabul edildi. En geniş olası tarama yerine en küçük anlamlı subnet listesi, ölçülebilir ve denetlenebilir olduğu için tercih edildi.

Güvenlik ve operasyonel riskler

Ağ taraması savunma sistemlerinde keşif faaliyeti olarak alarm üretebilir. Kaynak adresi, pencere ve kapsam SOC ile önceden paylaşılmalı; alarmlar tamamen susturulmak yerine beklenen etkinlikle eşleştirilmelidir. Tarama hesabı varsa yalnızca gerekli protokollerde, salt okunur ve kasada yönetilen kimlik kullanılmalıdır. SNMP topluluk bilgisi veya benzeri sırlar komut satırı geçmişine ve rapora yazılmamalıdır.

Eski yazıcılar, çevresel kontrol cihazları ve OT bileşenleri yoğun veya beklenmeyen sorguda kilitlenebilir. Hız sınırı tek koruma değildir; dışlama listesi, lokal pencere, durdurma eşiği ve saha iletişim kişisi gereklidir. Keşif çıktısı ağ topolojisi ve varlık bilgisi içerdiği için hassas kabul edilmeli, rol tabanlı erişim ve saklama süresiyle korunmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Bir NMS ekranında bütün lokasyonları çizmek kolaydır; zor olan çizginin gerçek ve güncel bir ilişkiyi temsil etmesidir. Elle hazırlanan harita birkaç değişiklik sonra eskiyebilir, kontrolsüz otomatik keşif ise binlerce anlamsız düğüm oluşturabilir. İyi görünürlük, araçtan önce veri modeli gerektirir: lokasyon nedir, cihaz sahibi kimdir, hangi bağlantı tüneldir ve hangi alarm gerçekten aksiyon doğurur?

20 Temmuz 2026 tarihli çalışmada merkez, tesis, uzak ofis ve saha ağlarını NetXMS üzerinde ortak görünümde birleştirdik. Discovery zone ve yerel poller yaklaşımıyla çakışan adres alanlarını ayırdık; güvenilir seed node’lardan başladık. SNMP, ICMP ve agent verisini aynı değerde kabul etmedik. Otomatik topolojiyi lokasyon etiketleri ve elle onaylanan WAN ilişkileriyle zenginleştirerek operasyon ekibinin kullanabileceği bir haritaya dönüştürdük.

Sorunun ortaya çıkışı

Kurumun farklı sahalarında ayrı izleme araçları ve güncelliği belirsiz çizimler bulunuyordu. Bir tünel kesildiğinde hangi servislerin etkilendiği kişilerin hafızasından anlaşılabiliyordu. Merkezi ekibin hedefi tüm cihazları tek konsolda görmek, lokasyon bazında alarm üretmek ve WAN ilişkilerini haritada izlemekti. Ancak bazı sahalarda benzer özel adres blokları, düşük bant genişliği ve farklı yönetim standartları vardı.

İlk gereksinim listesi “otomatik keşif ve harita” kadar kısaydı. Bunu operasyonel sorulara çevirdik: hangi node yönetilecek, hangisi yalnızca erişilebilirlik göstergesi olacak, bağlantı hangi veriyle çıkarılacak, cihaz lokasyonu nereden gelecek ve alarm kime atanacak? Bu sorular cevaplanmadan yapılan keşif, teknik veri üretse de işletilebilir hizmet oluşturmayacaktı.

İlk belirtiler ve yanlış varsayımlar

En büyük yanlış varsayım, seed node eklenince NetXMS’in fiziksel ve mantıksal topolojiyi eksiksiz anlayacağıydı. SNMP komşuluk protokolleri kapalıysa, sanal tüneller standart tabloda görünmüyorsa veya kimlik bilgisi yetmiyorsa ilişki çıkarılamaz. ICMP yanıtı yalnızca erişilebilirliği gösterir; cihaz tipi, port bağı veya hizmet sahibi hakkında güvenilir bilgi vermez.

İkinci varsayım her lokasyonu merkezi sunucudan taramanın daha sade olduğuydu. Aynı adres blokları zone olmadan yanlış node eşleşmesi yaratabilir, WAN kesintisi bütün sahayı “down” gösterebilir ve merkezi poller tüneli gereksiz yorar. Otomatik haritada görülen her çizgiyi fiziksel kablo kabul etmek de hatalıdır; L2, L3, VPN ve manuel iş bağı farklı ilişki türleridir.

Teknik analiz

Mevcut IP planı lokasyon ve güven bölgesine göre ayrıştırıldı. Çakışan veya bağımsız adres alanları için zone tasarlandı; her zone’da güvenilir router, switch veya poller seed olarak belirlendi. SNMPv3 desteği olan cihazlarda kimlik doğrulamalı ve şifreli salt okunur profil kullanıldı. Eski cihaz istisnaları ayrı kapsam ve risk kaydıyla yönetildi. Agent, sunucu ölçümleri için; ICMP ise temel erişilebilirlik için konumlandırıldı.

Topoloji kaynakları önceliklendirildi: LLDP/CDP benzeri komşuluk, bridge ve forwarding tabloları, routing bilgisi, VPN arayüzü ve manuel doğrulanmış WAN bağlantıları. Her kaynağın güncellik ve güven seviyesi farklıydı. Otomatik bulunan node’ların adlandırma, lokasyon, cihaz sınıfı ve sahiplik alanları doldurulmadan alarm üretmesine izin verilmedi. Bağımlılık modeli, bir WAN kesintisinde alt cihaz alarm fırtınasını bastıracak şekilde sınandı.

Uygulanan çözüm veya önerilen mimari

Merkezi NetXMS sunucusu yönetim ve raporlama katmanı olarak kaldı; uzak sahalara gerektiği yerde poller yerleştirildi. Zone’lar adres kapsamını ve kimlik profillerini ayırdı. Keşif, bilinen seed node ve onaylı subnetlerle sınırlandı. Node şablonları cihaz sınıfına göre DCI, alarm eşiği ve sorumlu ekip atadı. Lokasyon nesneleri, kurumun genel merkez ve saha hiyerarşisini teknik VLAN yapısından bağımsız temsil etti.

Harita iki seviyede tasarlandı: yönetim için lokasyonların sağlık ve WAN durumunu gösteren sade görünüm, ağ ekibi için cihaz-port ilişkilerini içeren teknik görünüm. Tünel bilgisi otomatik kaynaktan güvenilir biçimde gelmiyorsa açıklamalı manuel bağ kullanıldı. Değişiklik sonrası günlük keşif ile haftalık doğrulama raporu ayrıldı. Alarm yönlendirme, bakım modu ve eskalasyon kuralları hizmet sahipleriyle test edildi.

Alternatifler ve karar gerekçesi

Tamamen elle çizilmiş diyagramlar sunum için temiz olabilir, fakat durum ve envanterle bağları zayıftır. Yalnızca otomatik topoloji ise veri eksik olduğunda karmaşık ve yanıltıcı görünür. Hibrit yöntem seçildi: cihaz ve standart komşuluklar otomatik, iş açısından kritik WAN ve hizmet bağımlılıkları doğrulanmış manuel ilişkilerle tutuldu. Otomasyonun bilmediğini uydurmasına izin verilmedi.

Her sahaya poller kurmak ek sunucu ve güncelleme yükü getirir; düşük gecikmeli, küçük ofislerde merkezi polling yeterli bırakıldı. SNMP yerine yalnızca agent kullanmak ağ cihazlarını kapsamazdı; yalnızca SNMP de uygulama seviyesini eksik bırakırdı. NetXMS tercihi mevcut yetkinlik ve entegrasyon ihtiyacına uyuyordu, ancak mimari ilkeler başka NMS ürünlerinde de geçerlidir.

Güvenlik ve operasyonel riskler

NMS, ağın ayrıntılı haritasını ve yönetim kimliklerini tuttuğu için yüksek değerli bir sistemdir. Yönetim arayüzü ayrı ağdan erişilmeli, MFA ve rol tabanlı yetki uygulanmalı, servis hesapları kasada saklanmalıdır. SNMP yazma yetkisi izleme için kullanılmamalıdır. Poller ile merkez arasındaki trafik şifrelenmeli; gerçek topoloji ekranları genel sunum veya blog içeriğinde paylaşılmamalıdır.

Yanlış eşikler alarm yorgunluğu, agresif polling ise cihaz ve WAN yükü üretir. NMS yedeği yalnızca veritabanını değil şablon, harita ve anahtar kurtarma süreçlerini kapsamalıdır. Otomatik keşifle bulunan bilinmeyen cihaz olay olarak ele alınmalı ama doğrudan tehdit sayılmamalıdır. Sürüm yükseltmeleri laboratuvarda denenmeli, poller uyumluluğu ve alarm teslimi uçtan uca kontrol edilmelidir.

Çıkarılan Dersler

Kontrol Listesi