Azure VM RDP Bağlanamıyor Hatası Çözümü (2026)

Özet (TL;DR): Azure üzerindeki Windows sanal makinenize RDP ile bağlanamıyorsanız sorunun kaynağı genellikle dört yerden birindedir: ağ güvenlik grubu (NSG) kuralları, sanal makinenin public IP veya routing yapılandırması, Windows üzerindeki Uzak Masaüstü servisi ya da yerel ağınızdaki çıkış engeli. Doğru yaklaşım Azure portalından IP flow verify ile hangi katmanın trafiği reddettiğini saptamak, gerekirse Reset configuration only ile RDP konfigürasyonunu sıfırlamak ve uzun vadede 3389 portunu internete açık tutmak yerine Azure Bastion veya Defender for Cloud Just-in-Time VM Access kullanmaktır. Bu yazı tüm adımları sırayla, Azure portalı + PowerShell + Azure CLI komutlarıyla birlikte gösterir.

Tipik Hata Mesajları ve Belirtiler

Azure VM'inize RDP yapmaya çalıştığınızda karşılaşabileceğiniz hata mesajları farklı katmanlarda farklı sorunlara işaret eder. Aşağıdaki mesajları gördüğünüzde ilk anda hangi yönde araştırmaya başlayacağınızı belirleyebilirsiniz:

• "Remote Desktop can't connect to the remote computer" — Genelde ağ katmanında engelleme: NSG kuralı, eksik public IP, yanlış routing.
• "This computer can't connect to the remote computer" — VM içindeki Uzak Masaüstü servisi durmuş, RDP listener devre dışı veya Windows Firewall RDP'yi kapatıyor olabilir.
• "An internal error has occurred" — 3389 portunu başka bir uygulama tutuyor, Termservice çalışmıyor veya RDP sertifikası sorunlu.
• "An authentication error has occurred. The Local Security Authority cannot be contacted" — CredSSP / NLA (Network Level Authentication) uyumsuzluğu ya da kimlik bilgileri.
• Connect butonu Azure portalında gri — VM'e atanmış public IP yok ve ExpressRoute / Site-to-Site VPN bağlantısı da bulunmuyor.
• Bağlantı timeout — Çoğunlukla yerel internet sağlayıcınız veya kurumsal güvenlik duvarınız çıkış (outbound) TCP 3389'ı engelliyor.

Hangi hatayı aldığınız önemli olsa da, çözüm yaklaşımı aynı sırayı izler: dışarıdan içeriye, ağdan VM'e doğru daralt.

İlk 5 Dakika: Hızlı Ön Kontroller

Sorunlu RDP'lerin yarısı yerel sebepler yüzünden oluşur. Azure tarafına dalmadan önce şu üç şeyi mutlaka kontrol edin:

1. VM gerçekten çalışıyor mu? Azure portalında VM'in Overview sayfasında durum Running olmalı. Stopped / Stopped (deallocated) ise Start ile başlatın ve 2-3 dakika bekleyin.
2. VM Resource Health sağlıklı mı? VM > Help > Resource health üzerinden Microsoft'un platform tarafında bir sorun bildirip bildirmediğini görebilirsiniz. Available dışında bir şey görüyorsanız platform sorunu olabilir; bekleyin veya Microsoft destek kaydı açın.
3. Yerel ağınız 3389'a çıkış izni veriyor mu? Telefon hattınızdan veya başka bir ağdan tetherleyerek bağlanmayı deneyin. Aynı internetten birden fazla bilgisayardan denemek tanı koymaz; tamamen farklı bir ağa geçin.

Bu üçü sağlıklıysa sorun büyük olasılıkla NSG, public IP veya VM içi yapılandırmadadır.

En Sık Neden: NSG Kuralı 3389'u Engelliyor

Yeni oluşturulan Azure VM'lerinde NSG varsayılan olarak internetten gelen tüm inbound trafiği reddeder. Oluştururken "RDP'yi aç" kutusunu işaretlemediyseniz, 3389 internet üzerinden erişilebilir değildir. Sorunun NSG kaynaklı olup olmadığını birkaç dakikada netleştirmenin en hızlı yolu IP flow verify'dır.

Adım 1 — Network Watcher ile IP Flow Verify

1. Azure portalında üst arama çubuğuna Network Watcher yazıp seçin.
2. Sol panelden Network diagnostic tools > IP flow verify tıklayın.
3. Formu şu şekilde doldurun:
   • Virtual machine: Etkilenen VM.
   • Network interface: VM'in birincil NIC'i.
   • Protocol: TCP.
   • Direction: Inbound.
   • Local port: 3389.
   • Local IP address: VM'in private IP'si.
   • Remote IP address: Bağlanmaya çalıştığınız yerel bilgisayarın public IP'si (whatsmyip.com).
   • Remote port: 60000 (herhangi bir client port).
4. Check'e basın. Sonuç Allowed ise NSG değil; Denied ise hangi kuralın trafiği reddettiğini de söyler.

Aynı testi Azure CLI ile de yapabilirsiniz:

az network watcher test-ip-flow --resource-group myResourceGroup --vm myVM --direction Inbound --protocol TCP --local 10.0.0.4:3389 --remote 203.0.113.50:60000

Adım 2 — Effective Security Rules ile NIC + Subnet birleşimini görün

Bir VM'de hem NIC seviyesinde hem subnet seviyesinde NSG olabilir. Trafiğin geçmesi için her ikisinin de izin vermesi gerekir. Azure portal > VM > Networking > Network settings > NIC adı > Help altında Effective security rules kombine listeyi gösterir. PowerShell tarafında:

Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName myVMNic -ResourceGroupName myResourceGroup

Sık karşılaşılan üç hata: (1) Hiçbir Allow kuralı yok ve varsayılan DenyAllInBound (priority 65500) trafiği engelliyor. (2) Daha düşük priority numarasıyla bir Deny kuralı, sonradan eklenen Allow kuralından önce değerlendiriliyor. (3) Subnet NSG izin veriyor ama NIC NSG vermiyor (veya tersi).

Adım 3 — Eksikse 3389 Allow kuralı ekleyin

NSG'de 3389 için Allow kuralı yoksa portalden ekleyin: VM > Networking > Create port rule > Inbound port rule. Kaynak (Source) olarak kendi public IP'nizi belirleyin; * yani internet'in tamamına 3389 açmak kabul edilemez bir güvenlik riskidir. Azure CLI ile:

az network nsg rule create --resource-group myResourceGroup --nsg-name myNSG --name AllowRDP --priority 300 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 3389 --source-address-prefixes 203.0.113.50 --description "Allow RDP from office IP"

VM'in Public IP'si Yok veya Değişti

Azure portalında VM detayında Connect butonu gri görünüyorsa neredeyse her zaman VM'e atanmış public IP yoktur. Mevcut public IP'yi VM > Overview > Public IP address satırında görebilirsiniz. Boşsa iki seçeneğiniz var:

1. Public IP ekleyin: Networking > Network settings > NIC'in IP configuration'ı > Public IP > Associate. Sonrasında NSG'de 3389'un kendi IP'nize açık olduğundan emin olun.
2. Private bağlantı kurun: Üretim ortamlarında daha doğru yol — ExpressRoute, Site-to-Site VPN, Point-to-Site VPN veya Azure Bastion ile private IP üzerinden bağlanmak. Bu, VM'in saldırı yüzeyini neredeyse sıfıra indirir.

Dinamik public IP atadıysanız ve VM yeniden başlatıldıysa IP değişmiş olabilir. RDP'de "Computer" alanına FQDN değil eski IP yazıyorsanız bağlanamazsınız. Static public IP ya da DNS adı kullanın; DNS adını VM'in public IP configuration'ı altında ayarlayabilirsiniz.

VM İçi: RDP Servisi ve Konfigürasyon Sorunları

NSG ve public IP doğruysa sorun VM'in içinde olabilir: RDP servisi durmuş, RDP listener devre dışı kalmış, Windows Firewall kuralları RDP'yi engelliyor ya da kimlik bilgileri yanlış. İyi haber: Azure portalı bunları VM'e bağlanmadan çözmek için pratik kısa yollar sunar.

Reset configuration only — En sık işe yarayan tek tık

VM > Help > Reset password > Mode: Reset configuration only > Update. Bu işlem VMAccess uzantısı üzerinden VM'e bağlanır ve şunları yapar: RDP servisini yeniden başlatır, RDP listener'ı etkinleştirir, Windows Firewall'da 3389 için kuralı geri ekler ve kayıt defterinde fDenyTSConnections değerini 0'a çeker. Parolayı değiştirmediği için canlı sistemde güvenle kullanabilirsiniz.

PowerShell karşılığı:

Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" -VMName "myVM" -Location WestUS -Name "myVMAccessExtension"

Parolayı unuttuysanız — Reset password modu

Mod'u Reset password'a alın, yerel yönetici kullanıcı adı ve yeni parolayı girin. Microsoft Entra ID join VM'lerde bu yöntem çalışmaz; o durumda Entra üzerinden parola sıfırlama veya yetkili başka bir hesapla giriş gerekir.

Serial Console ile son çare

Reset configuration işe yaramazsa Boot diagnostics + Serial Console'u açın. VM > Help > Serial console sizi VM'in COM1'ine bağlar; PowerShell instance açıp 3389'un başka bir uygulama tarafından tutulup tutulmadığını kontrol edebilirsiniz:

Netstat -anob | more

Termservice.exe dışında bir process 3389'da dinliyorsa onu durdurun ve Termservice'i başlatın. Listener kapalıysa kayıt defterinde etkinleştirin:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp" /v fEnableWinStation /t REG_DWORD /d 1 /f

NIC reset ve Redeploy

Hâlâ bağlanamıyorsanız sırasıyla Reset NIC (Help > Reset network adapter) ve Redeploy (Help > Redeploy) deneyin. Redeploy, VM'i altyapıda başka bir host'a taşır — donanım ya da networking sorununu sıfırlar. Dezavantajı: ephemeral disk verisi kaybolur ve dinamik IP'ler değişir.

Yerel Tarafı: ISP, Kurumsal Firewall ve İstemci

Bazı kurumsal ağlar ve mobil operatörler çıkış 3389'u tamamen engeller. Mobil internetinizden veya farklı bir ağdan bağlanabiliyorsanız sorunun büyük ihtimalle yerel firewall'da olduğu kesinleşir. Yapılacaklar:

• Kurumsal ağ yöneticinizden outbound TCP 3389'a Azure'a izin verilmesini isteyin (kaynak: kullanıcı; hedef: VM public IP).
• Daha temiz yol: Azure tarafında Bastion kurun ve VM'e tarayıcı üzerinden HTTPS (443) ile bağlanın. Çoğu kurumsal firewall 443'ü açıktır.
• İstemci tarafında üçüncü parti güvenlik yazılımlarının (VPN client, endpoint protection) RDP'yi engellemediğinden emin olun — geçici olarak devre dışı bırakıp test edin.
• DNS cache'i temizleyin: ipconfig /flushdns. VM'in public IP'si değiştiyse istemci hâlâ eski IP'yi çözümlüyor olabilir.

Üretim İçin Doğru Yaklaşım: 3389'u İnternete Açmayın

RDP'yi internete açık tutmak brute-force, NTLM relay ve zero-day RCE saldırılarının en büyük giriş kapılarındandır. Sorununuzu çözdükten sonra üretim ortamı için aşağıdakilerden birini değerlendirin — biz de Microsoft Azure çözümleri kapsamında müşterilerimize bu modellerden birini kurmayı tavsiye ediyoruz:

• Azure Bastion: PaaS yönetilen jump host. Tarayıcıdan TLS üzerinden RDP/SSH; VM'in public IP'si gerekmez. AzureBastionSubnet adında /26 minimum subnet ister.
• Just-in-Time (JIT) VM Access: Microsoft Defender for Cloud içinde gelir; 3389 portu yalnızca ihtiyaç anında, kullanıcının onayladığı IP'ye, belirlenen süre boyunca açılır. Geri kalan zaman kapalıdır. Microsoft güvenlik çözümleri portföyünün vazgeçilmez bileşeni.
• VPN Gateway veya ExpressRoute: Site-to-site / point-to-site bağlantıyla VM'in private IP'sine erişim. Ofis ağınızdan Azure'a şifreli tünel.
• Azure Private Link: Private endpoint üzerinden public internet'e açmadan kaynaklara erişim.

İdeal kombinasyon: Bastion + JIT + Microsoft Entra Conditional Access ile MFA zorunluluğu. Bu üçlü, RDP saldırı yüzeyini pratikte ortadan kaldırır.

Karar Ağacı: Hangi Sırayla Ne Yapayım?

RDP sorunlarında zaman kaybetmemek için şu sırayı izleyin:

1. VM Running ve Resource Health Available mi? Değilse VM'i başlatın / bekleyin.
2. VM'in atanmış public IP'si var mı? Yoksa Bastion / VPN / public IP ekleyin.
3. Farklı bir ağdan deneyin (mobil hotspot). Bağlanabiliyorsanız sorun yerel ISP/firewall.
4. IP flow verify çalıştırın. Denied ise NSG'yi düzeltin (Allow 3389 + kendi IP'niz).
5. Hâlâ olmuyorsa Reset configuration only deneyin.
6. Hata devam ediyorsa Reset NIC > Restart > Redeploy sırasını uygulayın.
7. Bunlar da çözmediyse Serial Console'dan RDP listener ve Termservice durumunu kontrol edin.

Bu sıra %95 olayı çözer. Kalan %5 için Microsoft Learn — Detailed RDP troubleshooting dökümanı veya Microsoft destek bileti gerekebilir.

Sıkça Sorulan Sorular (SSS)

Azure VM'de RDP varsayılan portu nedir, değiştirebilir miyim?

Varsayılan port TCP 3389'dur. Güvenlik amacıyla portu kayıt defterinden değiştirebilirsiniz (HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber) ancak port değişimi gerçek bir koruma sağlamaz — saldırganlar tüm portları tarar. Doğru çözüm Bastion + JIT + MFA kombinasyonudur.

NSG'de Allow kuralı var ama hâlâ bağlanamıyorum, neden?

Üç ihtimal: (1) Daha yüksek öncelikli (düşük priority numarası) bir Deny kuralı sizin Allow'unuzdan önce değerlendiriliyor. (2) NIC seviyesinde Allow var ama subnet seviyesinde Deny var (veya tersi). (3) Allow kuralındaki source IP'niz değişmiş — ISP'niz size yeni dinamik public IP vermiş olabilir. Effective security rules görünümü bu üç durumu da netleştirir.

Reset configuration only güvenli mi, çalışan uygulamalarımı etkiler mi?

Evet, güvenlidir. İşlem yalnızca RDP servisini ve listener'ı sıfırlar; VM'in diğer servislerini, uygulamalarını veya kullanıcı oturumlarını etkilemez. Üretim VM'lerinde mesai saatleri içinde rahatlıkla uygulanabilir. Yalnızca o sırada aktif RDP oturumu varsa düşer.

Azure Bastion ücretli mi, hangi SKU'lar var?

Bastion ücretlidir; saatlik temel ücret + giden veri ücretinden oluşur. SKU'lar: Developer (ücretsiz / sınırlı, prod'da kullanılmaz), Basic, Standard, Premium. Çoğu kurumsal senaryoda Standard yeterli — host scaling, native client ve IP-tabanlı bağlantı sunar. Premium ise oturum kaydı ve private-only deployment ekler.

Just-in-Time VM Access kullanmak için Defender for Cloud lisansı gerekiyor mu?

Evet. JIT, Microsoft Defender for Cloud'un Defender for Servers Plan 2 kapsamında gelir. Lisans Azure portal > Defender for Cloud > Environment settings altından subscription bazında etkinleştirilir. JIT açıldığında 3389 portu varsayılan olarak Deny edilir; kullanıcı her bağlantıda Request Access yapar ve onaylı süre kadar NSG kuralı dinamik olarak açılır.

Microsoft Entra ID join VM'de RDP'de hangi kullanıcı adıyla giriş yapmalıyım?

Entra ID join VM'lerde AzureAD\[email protected] formatında giriş yaparsınız (Windows 11 / Windows Server 2022+ destekli). Ayrıca o kullanıcı için Azure RBAC tarafında Virtual Machine User Login veya Virtual Machine Administrator Login rolü atanmış olmalı. MFA / Conditional Access politikaları varsa RDP istemcisinin Web Account Manager (WAM) destekli olması gerekir.

VM'i restart ettim public IP değişti, nasıl sabitlerim?

Public IP kaynağında Assignment ayarını Static olarak değiştirin. Static IP, VM stop-deallocate olsa dahi korunur; dynamic IP ise VM her durduğunda boşa düşer. Static IP biraz daha pahalıdır ama prod ortamı için zorunludur. Alternatif: VM'e DNS adı atayın (örn: myvm.westeurope.cloudapp.azure.com) ve bağlantıyı IP yerine DNS üzerinden yapın.

Sonuç: Sorunu Çözmek Yeterli Değil, Tekrar Etmemesini Sağlayın

Azure VM'e RDP bağlantı sorunlarının büyük kısmı sistemli bir tanıyla 10-15 dakikada çözülür: önce VM ve ağ durumunu doğrulayın, NSG'yi IP flow verify ile test edin, gerekirse Reset configuration only ile RDP'yi sıfırlayın. Public IP yoksa veya değiştiyse ya da yerel ağınız 3389'u engelliyorsa hızla anlarsınız.

Ama asıl iş bundan sonra başlar. RDP'yi internete açık tutmak — özellikle * kaynaklı NSG kuralıyla — kurumsal güvenliğin en büyük açıklarından biridir. Çözümü kalıcılaştırmak için Azure Bastion, Just-in-Time VM Access ve Microsoft Entra Conditional Access üçlüsünü değerlendirin. Bu mimari yatırımı bir kez yaptığınızda hem benzer RDP sorunları büyük ölçüde ortadan kalkar hem de uyumluluk denetimlerinde (ISO 27001, KVKK, NIS2) güvenli uzak erişim kontrolünü kolayca kanıtlayabilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak Azure altyapı kurulumu, Bastion / JIT VM Access mimarisi ve güvenli uzak erişim tasarımında uçtan uca destek sağlıyoruz. Mevcut Azure ortamınızda RDP / SSH erişim modelinizi denetleyip iyileştirmemizi ister misiniz? İletişim sayfamızdan bize ulaşın, kısa bir teknik ön görüşmeyle başlayalım.