Windows Firewall Kaynaklı Bağlantı Sorunlarını Giderme

Tarafındankomut
0 Comments

Bir sabah erken saatte telefon çalıyor: “Hocam, uygulama sunucusuna bağlanamıyoruz, üretim durdu!” Bu tür senaryoların yüzde doksanında suçlu ya ağ ekibi ya da Windows Firewall oluyor. Çoğu zaman da ikisi birlikte. Windows Firewall, yanlış yapılandırıldığında ya da beklenmedik bir güncelleme sonrası değiştiğinde, sizi saatlerce uğraştırabilecek sinsi bir sorun kaynağına dönüşür. Bu yazıda Windows Firewall kaynaklı bağlantı sorunlarını nasıl teşhis edeceğinizi, hangi araçları kullanacağınızı ve gerçek dünya senaryolarında nasıl çözeceğinizi adım adım anlatacağım.

Windows Firewall Neden Bu Kadar Sinsi?

Windows Firewall, özellikle Server ortamlarında birkaç farklı katmanda çalışır. Domain Profile, Private Profile ve Public Profile olmak üzere üç profil bulunur ve sunucunuz hangi profilde olduğuna bağlı olarak tamamen farklı kurallar devreye girer. Bir sunucunun yanlışlıkla Public Profile’a geçmesi, tüm gelen bağlantıları aniden kesmek için yeterlidir.

Bunun yanı sıra, Group Policy üzerinden uygulanan kurallar yerel kurallarla çakışabilir. Yerel olarak bir port açtığınızı düşünürsünüz ama GPO o portu kapıyor olabilir. Ya da tam tersi: GPO’dan açtığınız bir kural, yerel bir “block” kuralı tarafından override ediliyor olabilir.

Temel Teşhis: Sorun Gerçekten Firewall Mı?

Firewall’a suç atmadan önce bağlantı sorununu doğrulamak gerekir. Klasik bir yanlış tanı senaryosu: Firewall’u tamamen kapattınız, sorun devam ediyor. O zaman suçlu başka bir şey demektir.

Test 1: Temel Bağlantı Kontrolü

# Hedef sunucuya basit ping testi
ping -n 4 192.168.1.100

# Port erişilebilirliğini test et (PowerShell)
Test-NetConnection -ComputerName 192.168.1.100 -Port 443

# Daha detaylı bilgi için
Test-NetConnection -ComputerName 192.168.1.100 -Port 1433 -InformationLevel Detailed

TcpTestSucceeded : False çıktısı görüyorsanız, bağlantı gerçekten kesilmiş demektir. Ama bu Firewall mı yoksa servis mi diye hâlâ bilmiyoruz.

Test 2: Servis Kendi Dinliyor mu?

Firewall’u suçlamadan önce uygulamanın porta gerçekten dinlediğini doğrulayın.

# Sunucu üzerinde hangi portlar dinleniyor
netstat -ano | findstr LISTENING

# Belirli bir port için
netstat -ano | findstr :1433

# PowerShell ile daha temiz çıktı
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort

Eğer servis porta dinlemiyorsa, sorun Firewall değil servisin kendisidir. Bunu tespit etmek çok kritik çünkü saatlerce Firewall ile uğraşıp sonunda uygulamanın çökmüş olduğunu fark etmek gerçekten sinir bozucu.

Test 3: Firewall’u Geçici Olarak Devre Dışı Bırakma

Bu adımı sadece test ortamında veya bakım penceresi açıkken yapın.

# Tüm profillerde firewall'u kapat (test için!)
netsh advfirewall set allprofiles state off

# Bağlantıyı test et, sonra MUTLAKA geri aç
netsh advfirewall set allprofiles state on

Firewall kapanınca sorun çözülüyorsa, kural problemi var demektir. Devam edelim.

Mevcut Firewall Durumunu Anlamak

Aktif Profili Tespit Etme

# Hangi profil aktif?
netsh advfirewall monitor show currentprofile

# Tüm profillerin durumunu göster
netsh advfirewall show allprofiles

Bu komutu çalıştırdığınızda dikkat etmeniz gereken nokta: Sunucu domain’e bağlıyken Domain Profile kullanıyor olmalı. Eğer çıktıda Public Profile active görüyorsanız, büyük ihtimalle domain bağlantısında sorun var ve sunucu yanlış profile düşmüş.

Mevcut Kuralları Listeleme

# Tüm inbound kuralları listele
netsh advfirewall firewall show rule name=all dir=in

# Belirli bir porta ait kuralları bul
netsh advfirewall firewall show rule name=all | findstr "1433"

# PowerShell ile daha kullanışlı çıktı
Get-NetFirewallRule | Where-Object {$_.Enabled -eq "True"} | Select-Object DisplayName, Direction, Action, Profile | Format-Table -AutoSize

# Sadece belirli porta ait aktif kurallar
Get-NetFirewallRule -Enabled True | Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq "443"}

Burada dikkat edilmesi gereken bir husus: Aynı port için hem Allow hem Block kuralı olabilir. Windows Firewall’da Block kuralı her zaman Allow kuralını geçersiz kılar. Bu öncelik sırası çok önemli.

Gerçek Dünya Senaryosu 1: SQL Server’a Uzak Bağlantı Sorunu

Bir müşteride uygulama sunucusu, SQL Server’a bağlanamıyordu. SQL Server aynı datacenter’da, aralarında fiziksel bir firewall yok. Sorun Windows Firewall’daydı.

Teşhis adımları:

# SQL Server sunucusunda - servis dinliyor mu?
netstat -ano | findstr :1433

# Çıktı geldi, yani SQL dinliyor
# Test-NetConnection uygulama sunucusundan
Test-NetConnection -ComputerName SQLSRV01 -Port 1433
# TcpTestSucceeded : False

# SQL Server'da firewall kurallarını kontrol et
Get-NetFirewallRule -DisplayName "*SQL*" | Select-Object DisplayName, Enabled, Action, Direction

Sorun şuydu: Birisi SQL Server üzerinde “SQL Server (TCP-In)” kuralını devre dışı bırakmış ama Default Instance için 1433 portu açık kalmış. Named Instance için dinamik port kullanılıyordu ve o port için hiç kural yoktu.

Çözüm:

# SQL Server Browser servisine izin ver (UDP 1434)
New-NetFirewallRule -DisplayName "SQL Server Browser" -Direction Inbound -Protocol UDP -LocalPort 1434 -Action Allow

# Named Instance için dinamik port varsa, programı doğrudan ekle
New-NetFirewallRule -DisplayName "SQL Server Instance" -Direction Inbound -Program "C:Program FilesMicrosoft SQL ServerMSSQL15.INSTANCE01MSSQLBinnsqlservr.exe" -Action Allow

# Veya sabit port atanmışsa
New-NetFirewallRule -DisplayName "SQL Named Instance TCP" -Direction Inbound -Protocol TCP -LocalPort 52000 -Action Allow

Gerçek Dünya Senaryosu 2: GPO’nun Ezdiği Yerel Kural

Bu senaryo özellikle kurumsal ortamlarda çok sık yaşanır. Yerel olarak bir kural ekliyorsunuz, test ediyorsunuz, çalışıyor. Sunucuyu yeniden başlatıyorsunuz ya da gpupdate /force çalıştırıyorsunuz ve kural gidiyor.

# GPO'dan gelen kuralları tespit et
Get-NetFirewallRule | Where-Object {$_.PolicyStoreSourceType -eq "GroupPolicy"} | Select-Object DisplayName, Action, Direction

# Yerel kurallar
Get-NetFirewallRule | Where-Object {$_.PolicyStoreSourceType -eq "Local"} | Select-Object DisplayName, Action, Direction

# Hangi GPO'ların firewall yönettiğini görmek için
gpresult /h C:Tempgpresult.html
# HTML raporu oluşturur, tarayıcıda açarak inceleyebilirsiniz

GPO’dan gelen bir Block kuralı, yerel Allow kuralınızı ezip geçiyor olabilir. Bu durumda yerel kural eklemek işe yaramaz, GPO’yu değiştirmeniz gerekir. Bunun için domain admin yetkisi veya Group Policy yöneticisi ile koordine çalışmanız şart.

Firewall Log’larını Aktif Hale Getirme

Firewall logları varsayılan olarak kapalıdır ve açmadan sorun tespiti yapmak kör uçuş gibidir. Mutlaka açın.

# Hem dropped hem allowed paketleri logla
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

# Log dosyasının yerini ayarla
netsh advfirewall set allprofiles logging filename "C:WindowsSystem32LogFilesFirewallpfirewall.log"

# Log boyutunu ayarla (MB cinsinden)
netsh advfirewall set allprofiles logging maxfilesize 4096

Log dosyası oluşturulduktan sonra gerçek zamanlı izleme yapabilirsiniz:

# PowerShell ile log'u gerçek zamanlı izle
Get-Content "C:WindowsSystem32LogFilesFirewallpfirewall.log" -Wait -Tail 50

# Sadece DROP olan satırları filtrele
Get-Content "C:WindowsSystem32LogFilesFirewallpfirewall.log" | Where-Object {$_ -match "DROP"}

# Belirli bir IP'den gelen drop'ları bul
Get-Content "C:WindowsSystem32LogFilesFirewallpfirewall.log" | Where-Object {$_ -match "DROP" -and $_ -match "192.168.1.50"}

Log çıktısında şöyle satırlar göreceksiniz:

2024-01-15 14:23:45 DROP TCP 192.168.1.50 10.0.0.100 54321 1433 0 - 0 0 0 - - - RECEIVE

Bu satırı okuyalım: 192.168.1.50 adresinden 10.0.0.100 adresine, 54321 kaynak portundan 1433 hedef portuna gelen TCP paketi DROP edilmiş. İşte sorunun tam yeri.

Windows Firewall ile Monitor Show Komutu

# Firewall'un o an engellediği bağlantıları görmek
netsh advfirewall monitor show firewall rule name=all

# Aktif güvenlik ilişkilendirmelerini göster
netsh advfirewall monitor show mmsa
netsh advfirewall monitor show qmsa

# Tüm profillerin detaylı durumu
netsh advfirewall show allprofiles verbose

Kural Ekleme ve Yönetimi

PowerShell ile Kural Ekleme

# Basit inbound TCP kuralı
New-NetFirewallRule `
    -DisplayName "Web Uygulamasi HTTPS" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow `
    -Profile Domain,Private `
    -Enabled True

# Sadece belirli bir IP aralığından gelen trafiğe izin ver
New-NetFirewallRule `
    -DisplayName "Management Network RDP" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -RemoteAddress "10.10.0.0/24" `
    -Action Allow `
    -Profile Domain `
    -Enabled True

# Belirli bir uygulamaya izin ver (port numarasından bağımsız)
New-NetFirewallRule `
    -DisplayName "Custom App Allow" `
    -Direction Inbound `
    -Program "C:AppsMyServiceservice.exe" `
    -Action Allow `
    -Enabled True

# Mevcut kuralı güncelle
Set-NetFirewallRule -DisplayName "Web Uygulamasi HTTPS" -RemoteAddress "10.0.0.0/8"

# Kuralı sil
Remove-NetFirewallRule -DisplayName "Web Uygulamasi HTTPS"

Kural Önceliği Sorunu

Windows Firewall kural önceliği şu sıraya göre işler:

  • En yüksek öncelik: GPO Block kuralları
  • İkinci öncelik: GPO Allow kuralları
  • Üçüncü öncelik: Yerel Block kuralları
  • Dördüncü öncelik: Yerel Allow kuralları
  • Varsayılan: Profile’ın varsayılan davranışı (genelde inbound block)

Bu sıralamayı bilmek sorunları çok hızlı lokalize etmenizi sağlar.

Özel Durum: Windows Defender Firewall ile Gelişmiş Güvenlik

GUI üzerinden yapılan değişiklikler zaman zaman CLI ile çelişebilir. Her ikisini de kullanıyorsanız tutarsızlıklar oluşabilir.

# Tüm firewall konfigürasyonunu export et (yedek almak için de kullanışlı)
netsh advfirewall export "C:Backupfirewall_backup.wfw"

# Yedeği geri yükle
netsh advfirewall import "C:Backupfirewall_backup.wfw"

# Firewall'u fabrika ayarlarına döndür (DİKKATLİ KULLANIN!)
netsh advfirewall reset

# Sadece inbound kurallarını varsayılana döndür
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound

Gerçek Dünya Senaryosu 3: Windows Update Sonrası Bağlantı Kaybı

Klasik senaryo: Cuma gecesi update uygulandı, pazartesi sabahı kimse uygulamaya bağlanamıyor. Update sonrası özellikle şu durumlara dikkat edin:

Bazı büyük feature update’ler Windows Firewall ayarlarını sıfırlayabilir. Bunu önlemek ve yaşandığında hızlıca tespit etmek için:

# Mevcut kural sayısını kontrol et (anormal düşüş var mı?)
(Get-NetFirewallRule).Count

# Son değişiklikleri event log'dan takip et
Get-WinEvent -LogName "Microsoft-Windows-Windows Firewall With Advanced Security/Firewall" |
    Where-Object {$_.TimeCreated -gt (Get-Date).AddDays(-1)} |
    Select-Object TimeCreated, Id, Message |
    Format-List

# Event ID 2004: Kural eklendi
# Event ID 2005: Kural değiştirildi
# Event ID 2006: Kural silindi
# Event ID 2033: Tüm kurallar silindi (KRİTİK ALARM!)

Event ID 2033 görürseniz, firewall kuralları tamamen silinmiş demektir. Bu genellikle netsh advfirewall reset çalıştırıldığında ya da bazı yükleme scriptlerinin hatalı çalışmasında olur.

Audit Politikası ile Bağlantı İzleme

Sadece Firewall logları yetmez, bazen Windows’un Security audit loglarını da devreye almanız gerekir.

# Filtering Platform bağlantı izlemeyi aç
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable

# Filtering Platform packet drop izlemeyi aç
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

# Mevcut audit politikasını kontrol et
auditpol /get /subcategory:"Filtering Platform Connection"

Bu ayar etkinleştirildikten sonra Security Event Log’unda şu event ID’leri görürsünüz:

  • 5156: Bağlantıya izin verildi
  • 5157: Bağlantı engellendi
  • 5152: Paket düşürüldü
  • 5154: Uygulama porta dinlemeye başladı
# Security log'dan engellenen bağlantıları filtrele
Get-WinEvent -LogName Security |
    Where-Object {$_.Id -eq 5157} |
    Select-Object -First 20 |
    Format-List TimeCreated, Message

Çoklu NIC Durumu

Birden fazla ağ kartı olan sunucularda Firewall kuralları bazen sadece belirli bir interface’e bağlı olabilir. Bu da karışıklığa yol açar.

# Interface profil atamasını kontrol et
Get-NetConnectionProfile

# Belirli bir interface'in profili
Get-NetConnectionProfile -InterfaceAlias "Ethernet0"

# Interface'e göre firewall durumu
netsh advfirewall monitor show currentprofile

Yönetim trafiği için ayrı bir NIC varsa ve o NIC yanlış profile atanmışsa, yönetim bağlantıları kesilir. Bu durumda:

# Interface'in profilini değiştir (dikkatli ol, domain bağlantısını kesebilir)
Set-NetConnectionProfile -InterfaceAlias "Ethernet1" -NetworkCategory Private

IPSec ve Windows Firewall Etkileşimi

Özellikle kurumsal ortamlarda IPSec politikaları ile Windows Firewall birlikte çalışır. Connection Security Rules aktifse, kimlik doğrulaması yapılmamış bağlantılar bloklanabilir.

# Mevcut connection security kurallarını listele
Get-NetIPsecRule | Select-Object DisplayName, Enabled, Mode

# IPSec monitoring
netsh advfirewall monitor show consec

# IPSec istatistikleri
netsh ipsec dynamic show stats

Eğer IPSec politikası devredeyse ve istemci bu politikayı karşılamıyorsa, Firewall izin veriyor olsa bile bağlantı kurulmaz. Bu durumu Security Event Log’daki 5451 ve 5452 event ID’leri gösterir.

Toplu Sunucu Yönetimi için PowerShell

Birden fazla sunucuda aynı sorunu tespit etmeniz gerekiyorsa:

# Birden fazla sunucuda firewall durumunu kontrol et
$sunucular = @("SRV01", "SRV02", "SRV03", "SRV04")

foreach ($sunucu in $sunucular) {
    $durum = Invoke-Command -ComputerName $sunucu -ScriptBlock {
        $profil = Get-NetFirewallProfile | Where-Object {$_.DefaultInboundAction -eq "Block"}
        [PSCustomObject]@{
            Sunucu = $env:COMPUTERNAME
            FWDurumu = (Get-NetFirewallProfile -Profile Domain).Enabled
            AktifProfil = (Get-NetConnectionProfile).NetworkCategory
        }
    }
    $durum | Format-List
}

Sık Yapılan Hatalar ve Kaçınma Yolları

Windows Firewall yönetiminde sık karşılaştığım hataları şöyle sıralayabilirim:

  • “Any” adresine kural yazmak: Tüm IP aralığına izin vermek yerine kaynak IP’yi kısıtlayın. Yönetim portları için özellikle kritik.
  • Profile seçmeyi unutmak: Kural eklerken profile belirtmezseniz tüm profillere uygulanır. Domain profile için açtığınız kural, sunucu Public profile’a düştüğünde de aktif olur.
  • Test sonrası firewall’u açık unutmak: netsh advfirewall set allprofiles state off yaptınız, test ettiniz, açmayı unuttunuz. Monitoring sistemleri devreye girmeden önce bir güvenlik açığı oluşturdunuz demektir.
  • Log almadan troubleshoot etmek: Firewall log’ları kapalıyken sorun çözmeye çalışmak gereksiz zaman kaybettirir.
  • Kural isimlerini anlamlı yazmamak: “Rule1”, “Test”, “Yeni kural” gibi isimler bir ay sonra ne olduğunu anlamanızı imkansız kılar.

Sonuç

Windows Firewall sorunlarını çözmenin formülü aslında basit: önce doğru teşhis, sonra çözüm. Çoğu sysadmin aceleyle kural ekliyor ya da firewall’u kapatıyor, sorunu büyütüyor. Doğru yaklaşım şu sırayla gitmek: önce servisin porta dinlediğini doğrula, sonra firewall log’larını aç ve DROP olan paketi gör, ardından ilgili kuralı ekle ya da düzelt.

GPO çakışmaları, Public Profile’a düşen sunucular, update sonrası sıfırlanan kurallar ve IPSec etkileşimi gibi senaryolar için de hazırlıklı olun. Bu yazıdaki PowerShell ve netsh komutlarını bir runbook’a dönüştürüp, bir sonraki “hocam bağlanamıyoruz” telefonu geldiğinde sistematik şekilde kullanabilirsiniz.

Son olarak: değişiklik yapmadan önce yedek alın.

netsh advfirewall export "C:Backupfw_$(Get-Date -Format 'yyyyMMdd_HHmm').wfw"

Bu tek satır sizi çok büyük dertlerden kurtarabilir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir