Ağ Adaptörü Sorunları: Windows Server Ağ Hata Tespiti

Sabah 08:00’de telefon çalıyor, “Sunucu ağa bağlanmıyor, üretim durdu” diyorlar. Bu senaryoyu yaşamış her sistem yöneticisi bilir: panik anında doğru adımları atmak, saatlerce sürebilecek arıza süresini dakikalara indirmenin tek yoludur. Windows Server ortamlarında ağ adaptörü sorunları, hem basit yapılandırma hatalarından hem de derin sürücü veya donanım problemlerinden kaynaklanabilir. Bu yazıda, gerçek dünya senaryolarından yola çıkarak sistematik bir hata tespit süreci anlatacağım.

Temel Durum Tespiti: Nereden Başlamalı?

Ağ sorunlarında ilk yapılacak iş paniğe kapılmamak ve sistematik ilerlemektir. Önce mevcut durumu bir anlık görüntü gibi çekip belgelemelisiniz.

ipconfig ile Temel Bilgileri Toplama

ipconfig /all

Bu komut size adaptörün MAC adresi, IP adresi, subnet mask, varsayılan ağ geçidi ve DNS sunucu bilgilerini verir. Çıktıda dikkat etmeniz gereken bazı kritik noktalar var:

• Media disconnected ifadesi görüyorsanız fiziksel katmanda sorun vardır, önce kablo ve switch portunu kontrol edin
• Autoconfiguration IPv4 Address ile başlayan 169.254.x.x adresi görüyorsanız DHCP sunucusuna ulaşılamıyor demektir
• DNS Suffix alanı boşsa domain joined makinelerde ciddi kimlik doğrulama sorunları yaşarsınız

Bir üretim ortamında karşılaştığım gerçek bir senaryoyu paylaşayım: SQL Server çalıştıran bir sunucuda bağlantı kesilmeleri yaşanıyordu. ipconfig çıktısı normal görünüyordu ama sorun, adaptörün birden fazla IP adresine sahip olmasından kaynaklıyordu. Eski bir yapılandırma artığı olan ikinci IP, bazı istemcilerin yanlış adrese bağlanmasına yol açıyordu.

Bağlantı Durumunu Hızlıca Kontrol Etme

netsh interface show interface

Bu komutun çıktısında her adaptörün yönetim durumu ve bağlantı durumunu görebilirsiniz. Admin State sütununda “Disabled” gören adaptör için önce neden devre dışı bırakıldığını araştırın, doğrudan aktifleştirmeye atlayıp yapılandırma tutarsızlıklarına düşmeyin.

Adaptör Sürücü Sorunları

Windows Server ortamlarında en sık karşılaşılan ama en geç fark edilen sorunlardan biri sürücü problemleridir. Özellikle Windows Update sonrasında sürücüler otomatik güncellenerek uyumsuzluk yaratabilir.

Device Manager Üzerinden Komut Satırı ile Sorun Tespiti

pnputil /enum-devices /class net /connected

Bu komut ağ adaptörlerinizi ve durumlarını listeler. Sarı ünlem işareti veya hata kodu gören adaptörler için sürücü güncellemesi veya geri alma gerekebilir.

Sürücü bilgilerini daha detaylı incelemek için:

Get-NetAdapter | Select-Object Name, InterfaceDescription, DriverVersion, DriverDate, Status | Format-List

Bir veri merkezi projesinde Dell sunucularda Broadcom adaptörlerinde yaşanan intermittent bağlantı kopmalarının kaynağı, Windows Server 2019 ile tam uyumlu olmayan eski bir sürücüydü. Üreticinin sitesinden en güncel sürücüyü indirip yükledikten sonra sorun tamamen ortadan kalktı. Bu nedenle adaptör sürücünüzü her zaman işletim sistemi güncellemesinin ardından kontrol etme alışkanlığı edinin.

Sürücüyü Geri Alma (Rollback)

Eğer güncelleme sonrası sorun başladıysa PowerShell ile sürücü bilgilerini alıp Device Manager üzerinden geri alabilirsiniz. Önce hangi sürücünün sorun çıkardığını tespit edin:

Get-WinEvent -LogName System | Where-Object {$_.Message -like "*network*" -or $_.Message -like "*adapter*"} | Select-Object TimeCreated, Message -First 20

Bu komut sistem olay günlüğünden ağ ile ilgili son 20 olayı getirir. Sürücü güncellemesinin tam zamanı ile sorunun başlama zamanının örtüşmesi, rollback kararını netleştirir.

TCP/IP Yığını Sorunları ve Sıfırlama

Windows Server ortamlarında bazen TCP/IP yığınının kendisi bozulabilir. Bu durum genellikle virüs temizleme araçları, hatalı üçüncü taraf yazılımlar veya yarım kalan güncellemeler sonrası yaşanır.

Winsock ve TCP/IP Sıfırlama

netsh winsock reset catalog
netsh int ip reset resetlog.txt
netsh int ipv6 reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Bu komutları sırasıyla çalıştırdıktan sonra sunucuyu yeniden başlatmanız gerekir. Yeniden başlatmadan önce üretim sunucusunda çalışan servisleri kontrol edin, aktif bağlantıları not alın.

Gerçek bir senaryo: Bir müşteri firmasında Exchange Server kurulu Windows Server 2016 makinesi, belirli istemcilerden gelen bağlantı isteklerine cevap vermiyordu. Ping atılabiliyordu ama TCP bağlantıları kurulumda takılıp kalıyordu. Netstat çıktısı incelendiğinde binlerce TIME_WAIT durumunda bağlantı birikimiyle karşılaştık. Winsock sıfırlama ve TCP registry parametrelerinin düzenlenmesi sorunu çözdü.

Gelişmiş Ağ Tanılama Araçları

netstat ile Bağlantı Analizi

netstat -ano | findstr "ESTABLISHED"
netstat -s

-a: Tüm bağlantıları ve dinleme portlarını gösterir -n: Adresleri ve port numaralarını sayısal biçimde gösterir -o: Her bağlantıyla ilişkili işlem kimliğini (PID) gösterir -s: Protokol başına istatistikleri gösterir

netstat -s çıktısında TCP bölümündeki Segments Retransmitted değerine dikkat edin. Bu değer sürekli artıyorsa ağ katmanında ciddi bir paket kaybı probleminiz var demektir. Normal bir ortamda bu oran toplam segmentlerin yüzde birinden az olmalıdır.

PowerShell ile Kapsamlı Ağ Tanılama

Windows Server 2012 R2 ve sonrasında gelen NetAdapter PowerShell modülü son derece güçlüdür:

Get-NetAdapterStatistics | Select-Object Name, ReceivedUnicastPackets, OutboundPackets, ReceivedErrors, OutboundErrors | Format-Table -AutoSize

ReceivedErrors ve OutboundErrors değerleri sıfırdan büyükse bu, donanım düzeyinde sorunlara işaret eder. Switch portu hatası, kablo kalitesi veya NIC donanım arızası düşünülmelidir.

Adaptörün hız ve duplex ayarlarını kontrol etmek için:

Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object {$_.RegistryKeyword -eq "SpeedDuplex"} | Select-Object DisplayValue

Birçok ortamda “Auto Negotiation” ayarının sorun çıkardığını gördüm. Özellikle eski switch’lere bağlı modern NIC’lerde hız/duplex uyuşmazlığı ciddi performans sorunlarına yol açar. Bu durumda hem switch portu hem de NIC tarafında aynı hız ve duplex değerini elle sabitlemek çözüm olur.

VLAN ve Teaming Sorunları

Enterprise ortamlarda NIC teaming ve VLAN yapılandırmaları ciddi sorun kaynakları olabilir.

NIC Teaming Durumunu Kontrol Etme

Get-NetLbfoTeam | Select-Object Name, TeamingMode, LoadBalancingAlgorithm, Status
Get-NetLbfoTeamMember | Select-Object Team, Name, InterfaceDescription, TransmitLinkSpeed

NIC teaming yapılandırmasında sık karşılaşılan hatalar:

• Switch Dependent teaming modunda switch tarafında LACP/802.3ad yapılandırması yapılmamış olması
• Team üyesi adaptörlerin farklı hız veya duplex ayarlarına sahip olması
• Standby adaptörün yanlış yapılandırılmış olması

Bir banka projesinde karşılaştığım vaka şöyleydi: Uygulama sunucusu üzerinde iki NIC ile LACP teaming yapılmıştı. Sunucu yeniden başlatıldıktan sonra bağlantı tamamen kesildi. Get-NetLbfoTeam çıktısında Status “Degraded” gösteriyordu. Sorun, switch tarafında bir port kanalı güncellemesinin yapılmasına rağmen Windows tarafındaki teaming modunun Switch Independent olarak kalmasıydı. Teaming modu güncellenerek sorun giderildi.

Güvenlik Duvarı ve Filtre Sürücüsü Sorunları

Bazen ağ bağlantısı fiziksel olarak sağlam olsa da güvenlik duvarı kuralları veya üçüncü taraf filtre sürücüleri trafiği engelleyebilir.

Windows Güvenlik Duvarı Kurallarını İnceleme

netsh advfirewall show allprofiles
netsh advfirewall firewall show rule name=all | findstr "Enabled"
Get-NetFirewallRule | Where-Object {$_.Enabled -eq "True" -and $_.Direction -eq "Inbound"} | Select-Object DisplayName, Action, Profile | Sort-Object Action

Geçici test amacıyla güvenlik duvarını devre dışı bırakmak yerine, spesifik bir port için izin kuralı oluşturup test etmek çok daha güvenlidir:

New-NetFirewallRule -DisplayName "Test-Port-8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

Test sonrasında bu kuralı kaldırmayı unutmayın:

Remove-NetFirewallRule -DisplayName "Test-Port-8080"

Üçüncü taraf güvenlik yazılımlarının yüklediği mini-port filtreleri de sorun çıkarabilir. Bu filtreleri görmek için:

netsh wfp show filters

Çıktı uzun olacaktır ama hangi sürücünün hangi trafiği engellediğini anlamak için bu çıktıyı bir metin editöründe incelemeniz gerekebilir.

Event Log ile Sistematik Hata Takibi

Tüm bu manuel kontrollerin ötesinde, Windows Event Log ağ sorunları için son derece değerli bilgiler barındırır.

Ağ İlgili Olayları Filtreleme

Get-WinEvent -LogName "System" | Where-Object {$_.ProviderName -eq "Tcpip" -or $_.ProviderName -eq "NDIS" -or $_.ProviderName -eq "NetBT"} | Select-Object TimeCreated, ProviderName, Id, Message | Sort-Object TimeCreated -Descending | Select-Object -First 30

Dikkat edilmesi gereken kritik Event ID’ler:

• Event ID 4227: TCP/IP kaynak yetersizliği, ephemeral port tükenmesi
• Event ID 4201: Ağ bağlantısı kesildi
• Event ID 4202: Ağa tekrar bağlandı
• Event ID 10317: NIC bağlantı hızı değişti (link flap sorunlarında sürekli tekrar eder)
• Event ID 1014: DNS çözümleme zaman aşımı

NDIS kaynaklı olaylar özellikle sürücü seviyesi sorunları için kritiktir. Bir sunucuda saniyeler içinde defalarca tekrar eden Event ID 10317 görüyorsanız, kablo veya switch port arızasından kaynaklanan link flapping sorununuz vardır.

Get-WinEvent -LogName "System" | Where-Object {$_.Id -eq 10317} | Select-Object TimeCreated, Message | Group-Object {$_.TimeCreated.Date} | Select-Object Name, Count

Bu komutla günlük bazında link flap sayısını görebilirsiniz. Normal bir sunucuda bu değer sıfır olmalıdır.

DNS Sorunları ve Ağ Bağlantısı İlişkisi

Ağ bağlantısı var ama uygulamalar çalışmıyor diyorsanız, DNS çözümleme sorunlarını da gündeminize alın.

DNS Çözümleme Sorunlarını Teşhis Etme

nslookup servername.domain.local
Resolve-DnsName -Name "servername.domain.local" -Type A -Server 192.168.1.1
Test-NetConnection -ComputerName "servername.domain.local" -Port 445

Test-NetConnection komutu son derece kullanışlıdır. Hem DNS çözümlemesini hem de TCP port bağlantısını tek komutla test edebilirsiniz. Çıktıdaki PingSucceeded ve TcpTestSucceeded alanlarına bakın.

DNS önbelleği bozulmuşsa temizleyin:

Clear-DnsClientCache
ipconfig /flushdns
Register-DnsClient

Pathping ve Tracert ile Yol Analizi

Sorun kendi sunucunuzda değil de ağın bir noktasındaysa yol analizi araçları devreye girer.

pathping -n 8.8.8.8
tracert -d 8.8.8.8

pathping çıktısında her hop için paket kaybı yüzdesi gösterilir. Belirli bir hop noktasında yüksek paket kaybı, o noktadaki cihazda sorun olduğunu gösterir. Ancak bazı routerlar ICMP sorgularını kasıtlı olarak yanıtsız bırakır, bu nedenle yalnızca pathping çıktısına bakarak karar vermek yanıltıcı olabilir.

Ağ Performans Sorunları için Gelişmiş İnceleme

Bağlantı var ama yavaş diyorsanız, performans analizi gereklidir.

Get-NetAdapterAdvancedProperty -Name "*" | Where-Object {$_.RegistryKeyword -in ("*RSS","*VMQ","LargeSendOffloadV2IPv4","*TCPChecksumOffloadIPv4")} | Select-Object Name, DisplayName, RegistryKeyword, DisplayValue

RSS (Receive Side Scaling): Çok çekirdekli işlemcilerde ağ yükünü çekirdekler arasında dağıtır. Sanal ortamlarda bazen sorun yaratabilir.

VMQ (Virtual Machine Queue): Hyper-V ortamlarında kullanılır. Hatalı yapılandırılmış VMQ, ciddi performans sorunlarına yol açabilir.

Large Send Offload (LSO): TCP segmentasyonunu NIC donanımına devreder. Bazı sürücülerde bu özellik sorun çıkarır, devre dışı bırakarak test edebilirsiniz:

Set-NetAdapterAdvancedProperty -Name "Ethernet" -RegistryKeyword "LargeSendOffloadV2IPv4" -RegistryValue 0

Değişikliği uyguladıktan sonra performans testini tekrarlayın. İyileşme olduysa bu özelliği devre dışı bırakın ve sürücü güncellemesi için üreticiye başvurun.

Sanal Ortamlarda Ek Kontroller

Hyper-V veya VMware üzerinde Windows Server çalıştırıyorsanız, ekstra kontrol noktaları var.

Get-VMNetworkAdapter -VMName "SunucuAdi" | Select-Object Name, SwitchName, MacAddress, Status, IPAddresses
Get-VMNetworkAdapter -VMName "SunucuAdi" | Get-VMNetworkAdapterFailoverConfiguration

Sanal switch yapılandırmasını da kontrol edin:

Get-VMSwitch | Select-Object Name, SwitchType, AllowManagementOS, NetAdapterInterfaceDescription

VMware ortamında ise VM Tools’un güncel olup olmadığını kontrol edin. Güncel olmayan VM Tools, ağ sürücüsü sorunlarının başlıca nedenleri arasındadır.

Hızlı Referans: Sorun Tespiti Akışı

Bir ağ sorunu yaşandığında aşağıdaki sırayı izlemenizi öneririm:

• Fiziksel katmanı kontrol et: Kablo, switch port lambası, ipconfig /all çıktısında “Media connected” durumu
• IP yapılandırmasını doğrula: Doğru IP, subnet, gateway ve DNS bilgileri
• Gateway’e ping at ve tracert çalıştır: Sorunun yerel mi yoksa dışarıda mı olduğunu belirle
• Event Log’u tara: NDIS, Tcpip ve NetBT kaynaklarından gelen olayları incele
• netstat -s ile istatistikleri kontrol et: Yüksek retransmission ve hata sayılarını tespit et
• Sürücü versiyonunu doğrula: Son güncelleme tarihi ve versiyonu kontrol et
• TCP/IP yığınını sıfırla: Son çare olarak winsock reset ve ip reset uygula

Sonuç

Windows Server ağ adaptörü sorunları, yüzeysel bakıldığında basit görünse de katmanlı yapısı nedeniyle derinlemesine inceleme gerektirir. Fiziksel katmandan başlayıp sürücü, TCP/IP yığını, güvenlik duvarı ve uygulama katmanına kadar sistematik ilerlediğinizde sorunu çok daha hızlı bulursunuz. Rastgele ayarları değiştirmek yerine her adımda neyi test ettiğinizi ve neyi dışladığınızı belgeleyin.

Bu yazıda paylaştığım komutları sık erişilen bir script dosyasına veya bir not uygulamasına kaydedin. Sabah 08:00’deki panik anında doğru komutu hatırlamaya çalışmak yerine, hazır şablonunuzdan çalışmak sizi hem sakinleştirir hem de değerli zamanınızı kurtarır. Ağ sorunları karşısında en büyük silahınız sistematik yaklaşım ve iyi belgelenmiş bir troubleshooting playbook’tur.