Windows Server Ağ Adaptörü Yapılandırması ve Sorun Giderme

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

Bir production ortamında ağ adaptörünün yanlış yapılandırılması yüzünden saatler harcadığınız oldu mu? Ben oldu. Üstelik bir Cuma akşamı, tam herkes evine giderken. O deneyimden sonra Windows Server ağ adaptörü yapılandırmasını kafama göre değil, sistematik bir şekilde yapmayı öğrendim. Bu yazıda hem temel yapılandırmayı hem de gerçek hayatta karşılaştığım sorun giderme senaryolarını paylaşacağım.

Ağ Adaptörü Yapılandırmasının Temelleri

Windows Server üzerinde ağ adaptörü yapılandırmasına başlamadan önce mevcut durumu anlamak gerekiyor. Sunucunuza bağlı kaç adaptör var, hangisi hangi role hizmet ediyor, teaming yapılmış mı? Bu soruların cevabını bilmeden yapılan her değişiklik risk taşır.

PowerShell ile mevcut adaptörleri listeleyelim:

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, MacAddress, LinkSpeed

Bu komut size adaptör adını, fiziksel tanımını, durumunu, MAC adresini ve bağlantı hızını verir. Çıktıda “Status” kolonunda “Up” görüyorsanız adaptör aktif ve bağlı demektir. “Disconnected” görüyorsanız fiziksel kablo bağlantısını kontrol etmeniz gerekiyor.

IP yapılandırmasını görmek için:

Get-NetIPAddress | Select-Object InterfaceAlias, IPAddress, PrefixLength, AddressFamily

Burada AddressFamily parametresi IPv4 mi IPv6 mi olduğunu belirtir. PrefixLength ise subnet mask yerine CIDR notasyonu kullanır, yani 24 dediğinde 255.255.255.0 demek.

Statik IP Yapılandırması

DHCP ortamında bile production sunucularına statik IP atamak iyi bir pratiktir. DNS kayıtları, firewall kuralları ve monitoring sistemleri IP değişikliğinden etkilenmesin istemezsiniz.

PowerShell ile statik IP atayalım:

# Önce mevcut IP yapılandırmasını temizle
Remove-NetIPAddress -InterfaceAlias "Ethernet" -Confirm:$false

# Yeni statik IP ata
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.1.100 -PrefixLength 24 -DefaultGateway 192.168.1.1

# DNS sunucularını ayarla
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("192.168.1.10", "192.168.1.11")

Dikkat etmeniz gereken bir nokta var: Remove-NetIPAddress komutunu çalıştırdıktan sonra sunucuya uzak bağlantı üzerinden erişiyorsanız bağlantınız kesilecektir. Bu işlemleri script halinde sırayla çalıştırmanız ya da yerel erişimle yapmanız en güvenlisi. Ben bir keresinde bunu unutup RDP üzerinden çalışırken kendimi dışarıda bıraktım, o an ne hissettim tahmin edin.

Yaptığınız değişikliği doğrulamak için:

Get-NetIPConfiguration -InterfaceAlias "Ethernet"

DNS Yapılandırması ve Sık Yapılan Hatalar

DNS yanlış yapılandırıldığında sunucu domain’e katılamaz, Active Directory replikasyonu bozulur, yazılımlar çalışmaz. Pek çok “ağ sorunu” aslında DNS sorunudur.

Domain üyesi bir sunucuda birincil DNS sunucusu olarak mutlaka domain controller’ın IP’sini kullanın. İkincil DNS olarak başka bir DC veya forwarder ayarlayabilirsiniz ama birincil DNS’i public bir adrese yönlendirmek ciddi sorunlara yol açar.

DNS çözümlemesini test etmek:

# Temel DNS testi
Resolve-DnsName -Name "google.com" -Server 192.168.1.10

# Belirli kayıt tipini sorgula
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.domain.local" -Type SRV

# DNS önbelleğini temizle
Clear-DnsClientCache

# Güncel DNS önbelleğini görüntüle
Get-DnsClientCache

-Server parametresiyle hangi DNS sunucusundan sorgu yapacağınızı belirtebilirsiniz. Bu, sorun gidermede çok işinize yarar. Eğer birinci DNS sunucusu çözümlüyor ama ikincisi çözümlemiyorsa hata noktasını hemen bulursunuz.

NIC Teaming Yapılandırması

Yüksek erişilebilirlik veya yüksek bant genişliği gerektiren ortamlarda NIC teaming kaçınılmaz. Windows Server 2012 ile birlikte bu özellik native olarak geldi, artık üçüncü parti yazılıma gerek yok.

# Mevcut team yapılarını listele
Get-NetLbfoTeam

# Yeni team oluştur
New-NetLbfoTeam -Name "ProductionTeam" -TeamMembers "Ethernet", "Ethernet 2" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

# Team durumunu kontrol et
Get-NetLbfoTeamMember -Team "ProductionTeam"

TeamingMode için üç seçenek var:

  • SwitchIndependent: Switch’in teaming’den haberi olmaz, en yaygın kullanılan mod
  • Static: Switch tarafında da yapılandırma gerektirir, 802.3ad statik
  • Lacp: 802.1ax LACP protokolü, switch desteği gerektirir

LoadBalancingAlgorithm için:

  • Dynamic: Windows Server 2012 R2 ile gelen, hem gelen hem giden trafiği dengeler
  • HyperVPort: Hyper-V ortamlarında VM başına dağıtım yapar
  • TransportPorts: TCP/UDP port bazlı dağıtım
  • MacAddresses: MAC adres bazlı dağıtım, en basit ama en az efektif

Gerçek hayat notu: LACP modunda sorun yaşıyorsanız ve switch ekibiyle koordinasyon sağlayamıyorsanız SwitchIndependent + Dynamic kombinasyonu çoğu durumda yeterlidir.

RSS ve Interrupt Moderation Ayarları

Yüksek trafikli sunucularda ağ performansı için RSS (Receive Side Scaling) ve interrupt moderation ayarlarına bakmak gerekir. Bu ayarlar çoğu zaman göz ardı edilir ama fark yaratır.

# RSS durumunu kontrol et
Get-NetAdapterRss -Name "Ethernet"

# RSS'i etkinleştir ve queue sayısını ayarla
Set-NetAdapterRss -Name "Ethernet" -Enabled $true -NumberOfReceiveQueues 4

# Interrupt moderation ayarlarını görüntüle
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object {$_.DisplayName -like "*Interrupt*"}

# Adaptör gelişmiş özelliklerinin tamamını listele
Get-NetAdapterAdvancedProperty -Name "Ethernet"

Yüksek paket hızına sahip ortamlarda interrupt moderation’ı “Low” veya “Disabled” yapmanız latency’yi düşürür. Ama bu CPU kullanımını artırır. Tradeoff’u bilerek yapın.

Firewall ve Ağ Profili İlişkisi

Windows Firewall, ağ profiline göre davranışını değiştirir. Bir sunucunun yanlış ağ profiline (Public, Private, Domain) atanması beklenmedik bağlantı sorunlarına yol açabilir.

# Mevcut ağ profili bağlantılarını görüntüle
Get-NetConnectionProfile

# Profili değiştir (Domain üyesi olmayan sunucular için)
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

# Firewall profillerinin durumunu kontrol et
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Domain üyesi sunucularda ağ profilini domain olarak görmesi gerekir. Eğer “Public” görüyorsanız DC’ye erişim sorunu olabilir veya NLA (Network Location Awareness) servisi sorun yaşıyordur.

Gerçek Hayat Senaryosu: Aralıklı Bağlantı Kopmaları

Bir müşteride şu senaryoyla karşılaştım: Uygulama sunucusu belirli aralıklarla ağ bağlantısını kaybediyordu. Event log’da kayıt vardı ama net bir neden göstermiyordu. Önce temel kontrolleri yaptım:

# Adaptör istatistiklerini görüntüle
Get-NetAdapterStatistics -Name "Ethernet"

# Hata sayaçlarını izle
$adapter = "Ethernet"
while($true) {
    $stats = Get-NetAdapterStatistics -Name $adapter
    Write-Host "$(Get-Date) - ReceivedErrors: $($stats.ReceivedPacketsWithErrors) | OutboundErrors: $($stats.OutboundPacketsWithErrors)"
    Start-Sleep -Seconds 5
}

Bu döngüyle hata sayaçlarının zaman içinde nasıl değiştiğini izledim. Sonuç? ReceivedPacketsWithErrors her 2-3 dakikada bir artıyordu. Bu fiziksel katman sorununa işaret ediyordu.

# Link state event loglarını kontrol et
Get-WinEvent -LogName "Microsoft-Windows-NDIS-PacketCapture/Diagnostic" -MaxEvents 50

# Alternatif olarak System log'dan filtrele
Get-WinEvent -LogName System | Where-Object {$_.Id -in (4201, 4202, 10317)} | Select-Object TimeCreated, Message

Event ID 4201 bağlantı kesilmesini, 4202 bağlantı kurulmasını gösterir. Log’da bu iki event arka arkaya geliyorsa fiziksel bağlantı problemi düşünün. Sonuçta o senaryoda kablo sorunuydu. Kablo değişince sorun çözüldü. Ama bu noktaya gelmek için PowerShell’in sistematik yardımı olmasa saatlerce uğraşırdım.

MTU Ayarları ve Jumbo Frame

Bazı ortamlarda, özellikle iSCSI veya NFS kullanan yapılarda Jumbo Frame etkinleştirmek isteyebilirsiniz. Ama bunu yapmadan önce tüm yol üzerindeki cihazların (switch, router, hedef) desteklediğinden emin olun. Aksi halde çok daha büyük sorunlar yaşarsınız.

# Mevcut MTU değerini görüntüle
Get-NetIPInterface -InterfaceAlias "Ethernet" | Select-Object InterfaceAlias, NlMtu

# MTU'yu değiştir (standart)
Set-NetIPInterface -InterfaceAlias "Ethernet" -NlMtu 1500

# Jumbo Frame için adaptör ayarını değiştir
Set-NetAdapterAdvancedProperty -Name "Ethernet" -RegistryKeyword "JumboPacket" -RegistryValue 9014

# MTU sorunlarını test et (ping ile path MTU discovery)
Test-NetConnection -ComputerName 192.168.1.1 -InformationLevel Detailed

MTU sorunlarını tespit etmek için ping ile fragment test yapabilirsiniz:

# -f bayrağı fragment yapma, -l boyut belirtir
ping -f -l 1472 192.168.1.1

Eğer 1472 byte ile çalışıyorsa (8 byte ICMP header + 20 byte IP header = 1500 MTU) normal MTU’da sorun yok demektir. Büyük paketlerde sorun yaşıyorsanız path MTU sorununa bakın.

VLAN Yapılandırması

Bazı ortamlarda Windows Server üzerinde direkt VLAN tagging yapmanız gerekebilir. Switch tarafı trunk modunda olmalı.

# Mevcut VLAN yapılandırmasını görüntüle
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object {$_.DisplayName -like "*VLAN*"}

# VLAN ID ayarla
Set-NetAdapterAdvancedProperty -Name "Ethernet" -RegistryKeyword "VlanID" -RegistryValue 100

# VLAN priority tagging
Set-NetAdapterAdvancedProperty -Name "Ethernet" -RegistryKeyword "*PriorityVLANTag" -RegistryValue 3

*PriorityVLANTag değerleri için:

  • 0: Packet Priority ve VLAN devre dışı
  • 1: Sadece Packet Priority etkin
  • 2: Sadece VLAN etkin
  • 3: Her ikisi de etkin

Ağ Performans Sorunlarını Teşhis Etme

Performans sorunu yaşadığınızda önce ölçün, sonra karar verin. Gözle karar vermek yanıltır.

# Anlık ağ throughput'unu izle
$adapter = "Ethernet"
$sample1 = Get-NetAdapterStatistics -Name $adapter
Start-Sleep -Seconds 1
$sample2 = Get-NetAdapterStatistics -Name $adapter

$rxBps = ($sample2.ReceivedBytes - $sample1.ReceivedBytes) * 8
$txBps = ($sample2.SentBytes - $sample1.SentBytes) * 8

Write-Host "RX: $([math]::Round($rxBps/1MB, 2)) Mbps"
Write-Host "TX: $([math]::Round($txBps/1MB, 2)) Mbps"

Daha kapsamlı bir izleme için Performance Monitor’daki network sayaçlarını PowerShell ile okuyabilirsiniz:

# Ağ arayüzü performans sayaçlarını al
$counters = @(
    "Network Interface(*)Bytes Received/sec",
    "Network Interface(*)Bytes Sent/sec",
    "Network Interface(*)Packets Received Errors",
    "Network Interface(*)Output Queue Length"
)

Get-Counter -Counter $counters -SampleInterval 2 -MaxSamples 5

Output Queue Length önemli bir gösterge. Bu değer sürekli 0’dan büyükse adaptör trafiğe yetişemiyor demektir. Bu durumda:

  • Adaptör hızını kontrol edin (autonegotiation sorunu olabilir)
  • NIC teaming düşünün
  • RSS kuyruklarını artırın
  • Offloading ayarlarını gözden geçirin

TCP Offload ve Checksum Ayarları

Ağ sorunlarında, özellikle de uygulama katmanı sorunlarında TCP offload özelliklerini geçici olarak devre dışı bırakmak bazen sorunun kaynağını bulmaya yardımcı olur.

# Offload ayarlarını görüntüle
Get-NetAdapterChecksumOffload -Name "Ethernet"
Get-NetAdapterLso -Name "Ethernet"

# Checksum offload'u devre dışı bırak (sorun giderme için)
Disable-NetAdapterChecksumOffload -Name "Ethernet"

# LSO (Large Send Offload) devre dışı bırak
Disable-NetAdapterLso -Name "Ethernet"

# Tekrar etkinleştir
Enable-NetAdapterChecksumOffload -Name "Ethernet"
Enable-NetAdapterLso -Name "Ethernet"

Not: Bu ayarlar gerçekten sorun giderme amaçlıdır. Production’da kalıcı olarak kapatmayın, CPU yükünü ciddi artırır.

Adaptör Sürücüsü Güncellemeleri

Ağ sorunlarının göz ardı edilen bir kaynağı da eski sürücülerdir. Windows Update her zaman en güncel ağ sürücüsünü getirmeyebilir.

# Mevcut sürücü bilgisini görüntüle
Get-NetAdapter -Name "Ethernet" | Select-Object Name, DriverVersion, DriverDate, DriverProvider

# Sürücü bilgisini daha detaylı görüntüle
$adapter = Get-NetAdapter -Name "Ethernet"
$pnpDevice = Get-PnpDevice -InstanceId $adapter.PnPDeviceID
Get-PnpDeviceProperty -InstanceId $pnpDevice.InstanceId | Where-Object {$_.KeyName -like "*Driver*"}

Sürücü güncellemesi için üretici sitesine gidip sunucunuzun modeline uygun sürücüyü indirmenizi öneririm. Özellikle Intel ve Broadcom adaptörleri için bu durum geçerli. Genellikle sürücü paketleri PowerShell ile sessiz kurulum yapmanıza izin verir.

Routing Tablosunu Yönetmek

Birden fazla ağ adaptörü olan sunucularda routing tablosunun doğru yapılandırılması kritik önem taşır. Yanlış gateway veya çakışan rotalar sinsi bağlantı sorunlarına yol açar.

# Routing tablosunu görüntüle
Get-NetRoute | Sort-Object RouteMetric | Format-Table InterfaceAlias, DestinationPrefix, NextHop, RouteMetric

# Belirli bir hedefe hangi yolun kullanılacağını test et
Find-NetRoute -RemoteIPAddress 8.8.8.8

# Statik rota ekle
New-NetRoute -InterfaceAlias "Ethernet 2" -DestinationPrefix "10.10.0.0/16" -NextHop 192.168.1.254

# Rota sil
Remove-NetRoute -DestinationPrefix "10.10.0.0/16" -Confirm:$false

Birden fazla adaptörde default gateway tanımlanması en sık yapılan hatalardan biridir. Sadece bir adaptörde default gateway olmalı, diğerleri için spesifik rotalar eklenmeli. Aksi halde asimetrik routing sorunları yaşarsınız.

Bağlantı Testleri ve Teşhis Araçları

Klasik ping ve tracert’in yanı sıra PowerShell’deki Test-NetConnection çok daha fazlasını sunar:

# Port erişilebilirliği test et
Test-NetConnection -ComputerName 192.168.1.10 -Port 443

# Traceroute benzeri test
Test-NetConnection -ComputerName google.com -TraceRoute

# Detaylı bağlantı bilgisi
Test-NetConnection -ComputerName 192.168.1.10 -InformationLevel Detailed

# Birden fazla hedefe paralel test
$targets = @("192.168.1.1", "192.168.1.10", "8.8.8.8")
$targets | ForEach-Object -Parallel {
    Test-NetConnection -ComputerName $_ -InformationLevel Quiet
} -ThrottleLimit 5

InformationLevel Detailed çıktısında PingSucceeded, NameResolutionSucceeded ve TcpTestSucceeded alanlarına bakın. Bu üç bilgi sorunun hangi katmanda olduğunu hızlıca gösterir.

Sonuç

Windows Server ağ adaptörü yapılandırması ve sorun giderme, “bir kez ayarla unut” işi değil. Ortam değişir, trafik kalıpları değişir, donanım yaşlanır. Düzenli olarak adaptör istatistiklerini gözden geçirmek, sürücüleri güncel tutmak ve yapılandırma değişikliklerini belgelemek uzun vadede çok zaman kazandırır.

PowerShell bu süreçte gerçek bir güç çarpanı. GUI ile yapabileceğiniz her şeyi PowerShell ile yapabilirsiniz, üstelik script haline getirip tekrar kullanabilirsiniz. Bir yapılandırma script’i hazırlayın, test ortamında deneyin, sonra production’a taşıyın. Bu disiplini bir kez oturdurduğunuzda Cuma akşamları kendinizi dışarıda bırakma riskini büyük ölçüde azaltırsınız.

Son bir not: Değişiklik yapmadan önce mutlaka mevcut yapılandırmayı dışa aktarın. Get-NetIPConfiguration, Get-NetRoute, Get-NetAdapter çıktılarını bir metin dosyasına kaydedin. Geri dönmeniz gerektiğinde bu bilgiler paha biçilmez olur.

Bir yanıt yazın

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