DHCP Sorunlarını Giderme: Yaygın Hatalar ve Çözümler

Yazar:komut.io ekibi Windows Server Ağ Yönetimi
0 Yorum

Yıllar içinde DHCP sorunlarıyla boğuşmayan sistem yöneticisi pek azdır. Bir sabah işe gelirsiniz, telefonlar çalmaya başlar: “IP alamıyorum”, “internete giremiyorum”, “yazıcıya bağlanamıyorum.” Tüm bu şikayetlerin arkasında çoğu zaman DHCP’nin sessiz sedasız bozulmuş olması yatar. Bu yazıda Windows Server ortamında sık karşılaşılan DHCP sorunlarını, gerçek dünya senaryolarıyla birlikte ele alacağız. Doğrudan uygulanabilir komutlar ve adım adım çözüm yöntemleriyle konuyu derinlemesine inceleyeceğiz.

DHCP Sorunlarına Yaklaşım Felsefesi

DHCP hataları genellikle iki ana kategoriye düşer: istemci taraflı sorunlar ve sunucu taraflı sorunlar. Hangisinin söz konusu olduğunu anlamadan koşturmaya başlamak, sizi zaman kaybına uğratır. Önce sorunu lokalize edin.

Bir istemcinin IP alamadığını öğrendiğinizde şu soruyu sorun: Sadece bu istemci mi etkilenmiş, yoksa ağdaki birden fazla cihaz mı? Eğer tek bir cihaz etkilenmişse sorun büyük olasılıkla istemci tarafındadır. Eğer belirli bir VLAN veya subnet’teki tüm cihazlar etkilenmişse sunucu veya relay konfigürasyonuna bakmanız gerekir.

Temel Tanı Komutları

Sorun gidermeye başlamadan önce mevcut durumu netleştirin. Hem istemci hem de sunucu tarafında kullanabileceğiniz temel komutlar şunlardır:

İstemci tarafında:

# Mevcut IP konfigürasyonunu görüntüle
ipconfig /all

# IP adresini yenileme (önce bırak, sonra al)
ipconfig /release
ipconfig /renew

# DNS ve ARP önbelleğini temizle
ipconfig /flushdns
arp -d *

Sunucu tarafında (PowerShell):

# DHCP servisinin durumunu kontrol et
Get-Service -Name DHCPServer | Select-Object Name, Status, StartType

# Tüm scope'ları listele
Get-DhcpServerv4Scope

# Belirli bir scope'un istatistiklerini görüntüle
Get-DhcpServerv4ScopeStatistics -ScopeId 192.168.10.0

Bu komutların çıktıları size başlangıç noktası verecektir.

Senaryo 1: “169.254.x.x” APIPA Adresi Sorunu

Bir istemcinin 169.254.x.x aralığında adres aldığını görürseniz bu, DHCP sunucusuna ulaşamadığı anlamına gelir. Windows, DHCP sunucusuna erişemediğinde APIPA (Automatic Private IP Addressing) mekanizmasıyla bu aralıktan kendi kendine adres atar.

Olası nedenler:

  • DHCP sunucusu servisi durmuş
  • Scope’ta kullanılabilir adres kalmamış (scope exhaustion)
  • DHCP Relay Agent yanlış yapılandırılmış
  • Güvenlik duvarı DHCP trafiğini engelliyor (UDP 67/68)
  • İstemci ile sunucu arasındaki ağ bağlantısı kopuk

Scope tükenmesi özellikle kurumsal ortamlarda sık karşılaşılan bir durumdur. Sabahları çok sayıda kullanıcı aynı anda ağa bağlandığında, scope’taki tüm adresler dağıtılmış olabilir.

# Scope doluluk oranını kontrol et
Get-DhcpServerv4ScopeStatistics -ScopeId 192.168.10.0 | 
    Select-Object ScopeId, AddressesFree, AddressesInUse, PercentageInUse

# Süresi dolmuş leaseları temizle (dikkatli kullanın)
Get-DhcpServerv4Lease -ScopeId 192.168.10.0 | 
    Where-Object {$_.AddressState -eq "ActiveReservation" -and $_.LeaseExpiryTime -lt (Get-Date)} |
    Remove-DhcpServerv4Lease

Eğer scope gerçekten tükeniyorsa ve büyütme imkanınız yoksa, lease süresini kısaltmayı düşünebilirsiniz. Varsayılan 8 günlük lease süresi, büyük ağlarda adreslerin uzun süre meşgul kalmasına yol açar.

Senaryo 2: Conflict Detection ve Duplicate IP Sorunları

Bu senaryoyu yaşayan bir sistemin belirtileri şöyledir: Zaman zaman bazı cihazlar ağa bağlanır, zaman zaman bağlanamaz. Event Log’da “DHCP server determined that IP address X.X.X.X is already in use” gibi uyarılar görürsünüz.

Statik IP adresleri atanmış cihazlar DHCP pool’u ile çakışıyorsa bu kaosa neden olur. Yazıcılar, sunucular veya ağ ekipmanları için elle atanmış IP’ler, DHCP scope’unun dışında tutulmalı ya da rezervasyon yapılmalıdır.

# DHCP çakışma tespit sayısını ayarla (2-3 arası önerilir)
Set-DhcpServerv4Scope -ScopeId 192.168.10.0 -ConflictDetectionAttempts 2

# Mevcut çakışmaları listele
Get-DhcpServerv4Conflict -ScopeId 192.168.10.0

# Çakışma kaydını temizle
Remove-DhcpServerv4Conflict -ScopeId 192.168.10.0 -IPAddress 192.168.10.55

Conflict detection etkinleştirildiğinde DHCP sunucusu, adresi vermeden önce ping atar. Bu küçük gecikmeye değer, çünkü çift IP sorunu ortamda ciddi bağlantı problemlerine yol açar.

Rezervasyon oluşturma:

# MAC adresine göre rezervasyon tanımla
Add-DhcpServerv4Reservation `
    -ScopeId 192.168.10.0 `
    -IPAddress 192.168.10.20 `
    -ClientId "00-1A-2B-3C-4D-5E" `
    -Description "Muhasebe Yazicisi - HP LaserJet"

Rezervasyon tanımladıktan sonra ilgili istemcide ipconfig /release ve ipconfig /renew komutlarını çalıştırmayı unutmayın.

Senaryo 3: DHCP Relay Agent Sorunları

Birden fazla VLAN bulunan ortamlarda DHCP istekleri broadcast olduğundan router veya Layer 3 switch üzerinden geçemez. Bu durumda DHCP Relay Agent devreye girer. Relay ayarları yanlışsa, belirli subnet’lerdeki tüm cihazlar IP alamaz.

Bu senaryoda şu soruları sormak gerekir: Relay Agent aktif mi? Doğru DHCP sunucusu IP’sini gösteriyor mu? DHCP sunucusu üzerinde ilgili scope tanımlı mı?

# Windows Server üzerinde DHCP Relay Agent konfigürasyonunu kontrol et
# (RRAS ile yapılandırılmışsa)
Get-RemoteAccess | Select-Object -ExpandProperty RoutingDomainConfig

# DHCP sunucusunda hangi scope'ların aktif olduğunu görüntüle
Get-DhcpServerv4Scope | Where-Object {$_.State -eq "Active"} | 
    Select-Object ScopeId, Name, SubnetMask, StartRange, EndRange

Cisco veya HP switch üzerinde relay yapılandırmak için cihazın CLI’ına girmeniz gerekir, ancak Windows tarafında scope’un doğru tanımlandığından emin olun. Relay Agent’ın çalıştığı interface’in IP adresiyle aynı subnet’te bir scope yoksa DHCP sunucusu isteği reddeder.

Scope’a superscope ekleme (birden fazla subnet aynı fiziksel segmentte ise):

# Superscope oluştur
Add-DhcpServerv4Superscope -SuperscopeName "Bina-A-Superscope" `
    -ScopeId 192.168.10.0, 192.168.11.0

Senaryo 4: DHCP Database Bozulması

Bu, nadir ama ciddi bir senaryodur. Sunucu aniden kapanırsa veya donanım arızası yaşanırsa DHCP veritabanı bozulabilir. Belirtiler şöyle sıralanır: Servis başlatılamıyor, Event Log’da “DHCP Server database error” görünüyor, lease kayıtları tutarsız.

# DHCP veritabanını yedekle
Backup-DhcpServer -ComputerName "DHCP-SUNUCU" -Path "C:DHCP_Backup"

# Servisi durdur, veritabanını onar
Stop-Service -Name DHCPServer

# Veritabanı dosyasının konumuna git ve jetpack ile onarım yap
# Varsayılan konum: C:WindowsSystem32dhcp
cd C:WindowsSystem32dhcp
jetpack dhcp.mdb dhcp_temp.mdb

# Servisi yeniden başlat
Start-Service -Name DHCPServer

Eğer jetpack ile onarım çalışmazsa yedeği geri yükleyin:

# Yedeği geri yükle
Restore-DhcpServer -ComputerName "DHCP-SUNUCU" -Path "C:DHCP_Backup"

Bu yüzden DHCP veritabanının düzenli yedeklenmesi kritik önem taşır. Bunu otomatikleştirmek için Windows Görev Zamanlayıcı ile bir PowerShell betiği kurabilirsiniz.

Senaryo 5: Rogue DHCP Server (Sahte DHCP Sunucusu)

Bu senaryo, özellikle büyük ağlarda tam bir kabus olabilir. Ağda yetkisiz bir DHCP sunucusu aktif olduğunda istemciler yanlış IP, gateway veya DNS bilgileri alabilir. Sonuç: kimse internete çıkamaz ya da daha kötüsü trafik yanlış yönlendirilir.

Belirtiler: Bazı istemciler IP alıyor ama internet çalışmıyor, gateway adresi beklenenden farklı görünüyor, DNS sorguları yanıt vermiyor.

# Ağdaki aktif DHCP sunucularını tespit et
# Bu komut Wireshark veya Network Monitor ile tamamlanmalıdır
# PowerShell ile mevcut kiralama kaynaklarını analiz et

Get-DhcpServerv4Lease -ScopeId 192.168.10.0 | 
    Group-Object -Property ServerIP | 
    Select-Object Name, Count

Rogue DHCP tespiti için en güvenilir yöntem Wireshark’tır. Ağ üzerinde DHCP Discover paketi yollayıp hangi sunuculardan Offer geldiğini görürsünüz. Yetkisiz sunucu tespit edildiğinde önce hangi cihaz olduğunu bulmak, ardından o cihazın DHCP servisini kapatmak gerekir.

Korunma yöntemi: Yönetilen switchlerde DHCP Snooping özelliği mutlaka aktifleştirilmeli. Bu özellik, sadece belirlenen güvenilir portların DHCP Offer paketi göndermesine izin verir.

Senaryo 6: DNS Dinamik Güncelleme Sorunları

DHCP sunucusu, istemcilere adres verirken DNS kayıtlarını da otomatik güncellemesi gerekebilir. Bu yapılandırma yanlışsa istemciler IP alır ama isim çözümlemesi çalışmaz, yani istemci adına ping atılamaz.

# DHCP scope için DNS dinamik güncelleme ayarını kontrol et
Get-DhcpServerv4DnsSetting -ScopeId 192.168.10.0

# DNS dinamik güncellemeyi aktifleştir
Set-DhcpServerv4DnsSetting `
    -ScopeId 192.168.10.0 `
    -DynamicUpdates "Always" `
    -DeleteDnsRROnLeaseExpiry $true `
    -UpdateDnsRRForOlderClients $true

Burada dikkat edilmesi gereken nokta şudur: DHCP sunucusunun DNS sunucusunda güncellemeleri yapabilmesi için DNSUpdateProxy grubuna eklenmesi veya özel izin yapılandırması gerekebilir. Özellikle Active Directory ortamlarında bu adım atlanırsa kayıtlar oluşturulmaz.

# DHCP sunucu hesabını DNS güvenli güncelleme için yapılandır
# Active Directory Users and Computers üzerinde yapılır
# veya PowerShell ile:

$dhcpServer = "DHCP-SUNUCU$"
$dnsZone = "sirket.local"

# DNS bölgesine DHCP sunucusu için yazma izni ver
$acl = Get-Acl "AD:DC=$dnsZone,CN=MicrosoftDNS,DC=DomainDnsZones,DC=sirket,DC=local"

Senaryo 7: Failover DHCP Yapılandırması Sorunları

Windows Server 2012 ve sonrasında DHCP Failover özelliği geldi. İki DHCP sunucu arasında yük dağılımı veya yedeklilik sağlar. Ancak bu özelliğin de kendine özgü sorunları vardır.

En sık karşılaşılan sorun: Failover partneri arasındaki senkronizasyon kesilmesi. Bu durumda her iki sunucu da aynı adresi farklı istemcilere verebilir.

# Failover ilişkisini kontrol et
Get-DhcpServerv4Failover

# Failover durumunu görüntüle
Get-DhcpServerv4Failover | Select-Object Name, State, PartnerServer, Mode

# Senkronizasyonu zorla
Invoke-DhcpServerv4FailoverReplication -Name "SirketFailover" -Force

Failover durumu “CommunicationInterrupted” veya “PartnerDown” ise iki sunucu arasındaki ağ bağlantısını kontrol edin. Varsayılan failover portu TCP 647’dir, güvenlik duvarında açık olmalıdır.

# Failover partner sunucusunu test et
Test-NetConnection -ComputerName "DHCP-SUNUCU-2" -Port 647

# Gerekirse failover ilişkisini kaldır ve yeniden kur
Remove-DhcpServerv4Failover -Name "SirketFailover"

Add-DhcpServerv4Failover `
    -ComputerName "DHCP-SUNUCU-1" `
    -PartnerServer "DHCP-SUNUCU-2" `
    -Name "SirketFailover" `
    -ScopeId 192.168.10.0 `
    -Mode "LoadBalance" `
    -LoadBalancePercent 50 `
    -MaxClientLeadTime "01:00:00" `
    -AutoStateTransition $true

Event Log ve Loglama

DHCP sorunlarının büyük çoğunluğu Event Log incelemesiyle hızla teşhis edilebilir. Windows DHCP sunucusu, varsayılan olarak C:WindowsSystem32dhcp dizininde günlük log dosyaları oluşturur.

# DHCP ile ilgili Event Log kayıtlarını filtrele
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-DHCP-Server'
    Level = 2  # Sadece hatalar
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Id, Message | Format-List

# DHCP audit log dosyasını oku (bugünün logu)
$logFile = "C:WindowsSystem32dhcpDhcpSrvLog-" + (Get-Date -Format "ddd") + ".log"
Get-Content $logFile | Where-Object {$_ -match "^1[0-9]|^[2-9][0-9]"} | 
    Select-Object -Last 50

DHCP log dosyalarındaki olay kodlarından en sık karşılaşılanlar:

  • ID 10: Yeni IP kiralandı
  • ID 11: Kira yenilendi
  • ID 12: Kira bırakıldı
  • ID 13: IP çakışması tespit edildi
  • ID 15: Kira reddedildi (scope doldu veya çakışma)
  • ID 20: Yetkilendirme başarılı
  • ID 21: Yetkilendirme başarısız

DHCP Sunucusunu Yetkilendirme Sorunu

Active Directory ortamında DHCP sunucusu yetkisiz ise istemcilere IP dağıtmaz. Bu, rogue DHCP koruması için tasarlanmış kasıtlı bir davranıştır.

# DHCP sunucusunun yetkili olup olmadığını kontrol et
Get-DhcpServerInDC

# Sunucuyu yetkilendir
Add-DhcpServerInDC -DnsName "dhcp-sunucu.sirket.local" -IPAddress 192.168.10.5

# Yetkilendirmeyi kaldır (dikkatli kullanın)
Remove-DhcpServerInDC -DnsName "dhcp-sunucu.sirket.local"

Eğer yeni kurduğunuz bir DHCP sunucusu çalışmıyorsa ve Event Log’da yetkilendirme hatası görüyorsanız, bu adım genellikle sorunu çözer. Yetkilendirme için Domain Admin yetkisine ihtiyaç duyulduğunu unutmayın.

Proaktif İzleme için Hızlı Script

Sorun çıkmadan önce DHCP sağlığını izlemek, reaktif olmaktan çok daha iyidir. Aşağıdaki betik, scope doluluk oranlarını kontrol eder ve belirlenen eşiği aşanları raporlar:

# DHCP Scope Doluluk Izleme Betiği
$uyariEsigi = 80  # Yüzde

$dhcpSunucu = "DHCP-SUNUCU"
$raporSatiri = @()

Get-DhcpServerv4ScopeStatistics -ComputerName $dhcpSunucu | ForEach-Object {
    if ($_.PercentageInUse -ge $uyariEsigi) {
        $raporSatiri += [PSCustomObject]@{
            ScopeId         = $_.ScopeId
            Dolu            = "$($_.PercentageInUse)%"
            KullanilabilirAdres = $_.AddressesFree
            Uyari           = "KRITIK: Scope dolmak uzere!"
        }
    }
}

if ($raporSatiri.Count -gt 0) {
    $raporSatiri | Format-List
    # Burada e-posta bildirimi veya monitoring sistemine entegrasyon eklenebilir
    Write-Warning "Toplam $($raporSatiri.Count) scope kritik doluluk seviyesinde!"
} else {
    Write-Host "Tum scope'lar normal seviyede." -ForegroundColor Green
}

Bu betiği günlük çalışacak şekilde Görev Zamanlayıcı’ya ekleyin ve çıktıyı bir log dosyasına ya da e-posta sistemine yönlendirin.

Sonuç

DHCP sorunları, görünürde basit ama derinleştiğinde karmaşık bir konu. Tecrübe şunu gösteriyor: sorunların büyük çoğunluğu birkaç temel sebebe dayanır: scope tükenmesi, yanlış relay yapılandırması, statik IP çakışmaları ve yetkilendirme sorunları. Bu kategorileri aklınızda tutarak sorgulayıcı bir yaklaşımla gittiğinizde, çoğu sorunu 15-20 dakika içinde çözebilirsiniz.

Proaktif izleme, buradaki en kritik nokta. Scope doluluk oranlarını, failover senkronizasyon durumunu ve Event Log’ları düzenli takip eden bir yapı kurarsanız, kullanıcılar “IP alamıyorum” demeden sizi aramadan önce sorunu fark eder ve müdahale edersiniz. Bu da son tahlilde hem kullanıcı memnuniyetini artırır hem de sizi sabah erkenden uyandıran sinirli aramalardan kurtarır.

DHCP loglama seviyesini artırmayı, DHCP Snooping’i switch seviyesinde uygulamayı ve en az iki DHCP sunucusu ile failover kurgulamayı standart uygulama haline getirmenizi öneririm. Bu üç adım, ortamınızı DHCP kaynaklı kesintilere karşı önemli ölçüde dayanıklı kılar.

Bir yanıt yazın

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