ipconfig, netstat ve ping ile Windows Ağ Tanılama

Bir Windows Server ortamında ağ sorunu çıktığında, ilk refleks genellikle ekrana bakmak ve “neden bağlanamıyorum?” diye düşünmek oluyor. Yıllarca farklı kurumsal ortamlarda çalışırken öğrendiğim şey şu: doğru araçları doğru sırayla kullanmak, sorunu saatlerce uğraşmak yerine dakikalar içinde çözmenizi sağlıyor. ipconfig, netstat ve ping üçlüsü, Windows ağ tanılamasının temel taşları. Basit görünüyorlar, ama derinlemesine bildiğinizde size çok şey anlatıyorlar.

ipconfig: Ağ Yapılandırmanızın Aynası

ipconfig komutu, pek çok sysadmin tarafından sadece IP adresini öğrenmek için kullanılan bir araç olarak görülür. Oysa bu komut, özellikle /all parametresiyle birlikte kullanıldığında, ağ yapılandırmanızın neredeyse tam bir fotoğrafını çeker.

Temel Kullanım ve Parametreler

ipconfig

Bu komut size aktif ağ adaptörlerinin IP adresi, subnet mask ve default gateway bilgisini verir. Hızlı kontrol için yeterli ama sorun giderme için genellikle yetersiz.

ipconfig /all

İşte asıl güç burası. Bu çıktıda şunları görürsünüz:

• Physical Address (MAC Adresi): Adaptörün donanım adresi. Firewall kurallarında veya switch port güvenliğinde bu adrese ihtiyacınız olur.
• DHCP Enabled: DHCP’den mi yoksa statik olarak mı atanmış?
• DHCP Server: Hangi sunucu IP dağıtıyor?
• Lease Obtained / Lease Expires: DHCP kirasının ne zaman alındığı ve ne zaman biteceği.
• DNS Servers: Hangi DNS sunucularını kullanıyor?
• IPv6 Address: Link-local veya global IPv6 adresi var mı?

Kurumsal bir ortamda karşılaştığım yaygın bir senaryo şu olurdu: Kullanıcı “internete çıkamıyorum” diyor, ama ipconfig /all çıktısına bakıyorsunuz ve DNS sunucusu olarak 169.254.x.x gibi bir şey görüyorsunuz. Bu, APIPA (Automatic Private IP Addressing) aralığı ve DHCP sunucusuna ulaşamadığının işareti. Doğrudan problemi çözmeye çalışmak yerine önce bu çıktıyı okumayı öğrenin.

DNS Önbelleği Sorunları ve Çözümü

DNS sorunları, özellikle dahili servis adları değiştiğinde veya bir sunucu taşındığında baş ağrısına dönüşür. Kullanıcı eski IP’ye gitmeye devam eder çünkü önbellekte eski kayıt var.

ipconfig /displaydns

Bu komut, makinenin DNS önbelleğindeki tüm kayıtları listeler. Hangi domain’lerin hangi IP’lere çözümlendiğini görebilirsiniz. Eğer bir kayıt yanlışsa:

ipconfig /flushdns

Önbelleği temizler. Sonra tekrar ipconfig /displaydns çalıştırarak yeni çözümlemenin doğru yapıldığını teyit edin. Bu iki komut kombinasyonu, web uygulaması geçişlerinde ve DNS değişikliklerinin devreye alınmasında sıkça kullanılır.

DHCP Yenileme İşlemleri

Bazen bir makine, geçersiz bir IP konfigürasyonuyla takılı kalır. Bunu çözmek için:

ipconfig /release
ipconfig /renew

/release mevcut DHCP kirasını bırakır, /renew yeni bir kira ister. Dikkat: Belirli bir adaptör için de yapabilirsiniz. Birden fazla NIC olan sunucularda çok işe yarar:

ipconfig /release "Ethernet 2"
ipconfig /renew "Ethernet 2"

Tırnak içindeki isim, adaptörün sistem üzerindeki adıyla eşleşmeli. Adaptör adlarını ipconfig /all çıktısından öğrenebilirsiniz.

ping: Basit Ama Vazgeçilmez

ping komutunu küçümseyenlere şunu söylerim: Doğru parametrelerle kullandığınızda, ağ katmanlarını tek tek izole etmenizi sağlayan güçlü bir tanılama aracıdır. Sorun, çoğu kişinin ping 8.8.8.8 yazıp “cevap geliyor, sorun yok” deyip geçmesi.

Temel Parametreler ve Anlamları

-t: Durdurana kadar ping atmaya devam eder. Ctrl+C ile durdurursunuz. Ağ kararlılığını test etmek için idealdir.

-n [sayı]: Kaç tane echo request gönderileceğini belirler. Varsayılan 4’tür.

-l [boyut]: Paket boyutunu byte cinsinden belirler. Varsayılan 32 byte.

-f: Fragment olmayan (Don’t Fragment) bit’i set eder. MTU sorunlarını tespit etmek için kullanılır.

-i [TTL]: Time To Live değerini belirler.

-w [ms]: Cevap için bekleme süresi (timeout). Varsayılan 4000ms.

Gerçek Dünya Senaryo 1: Ağ Kararlılığı Testi

Kullanıcılar “bağlantı kesiliyor” diye şikayet ediyor ama siz orada olmadığınızda sorun olmuyor. Şunu deneyin:

ping -t 192.168.1.1 > C:ping_log.txt

Bu komutu arka planda çalışır bırakın. Saat farkı olan problemlerde (mesela gece 03:00’te oluşan bağlantı kesintileri), log dosyasında tam olarak hangi saatlerde timeout aldığınızı görebilirsiniz. “Request timed out” satırlarını arayın.

Gerçek Dünya Senaryo 2: MTU Sorunlarının Tespiti

VPN bağlantılarında ya da farklı ISP’ler arasında geçişlerde sıkça MTU problemi yaşanır. Küçük paketler gidiyor ama büyük paketler gitmiyor. Bu klasik bir MTU uyumsuzluğu belirtisidir.

ping -f -l 1472 192.168.1.1

Eğer “Packet needs to be fragmented but DF set” hatası alırsanız, paket boyutunu düşürün:

ping -f -l 1400 192.168.1.1

Bu şekilde binary search yaparak maksimum iletebileceğiniz paket boyutunu bulursunuz. Bulduğunuz değere 28 ekleyin (IP header 20 byte + ICMP header 8 byte) ve bu sizin MTU değeriniz olur. NIC veya VPN adaptörünüzün MTU’sunu buna göre ayarlayabilirsiniz.

Sorun Giderme Akışı

Ağ sorunlarında ping’i belirli bir sırayla kullanın. Bu sıra, problemi izole etmenizi sağlar:

ping 127.0.0.1

Önce loopback. Bu başarısız olursa TCP/IP stack’inde ciddi bir sorun var demektir. Pek nadir görülür ama görmezden gelmeyin.

ping <kendi_IP_adresiniz>

Kendi NIC’inizi test edin. Çalışıyorsa adaptör ve driver sorunsuz.

ping <default_gateway>

Yerel ağa çıkabiliyor musunuz? Bu başarısız olursa yerel ağ sorunudur.

ping 8.8.8.8

Gateway çalışıyorsa internete çıkıyor musunuz? IP seviyesinde internet bağlantısını test eder.

ping google.com

DNS çözümlemesi çalışıyor mu? 8.8.8.8’e ping gidiyorsa ama domain name’e gitmiyorsa, DNS probleminiz var demektir.

Bu beş adım, ağ sorunlarını katman katman izole etmenin en pratik yoludur.

netstat: Bağlantıların Gerçek Tablosu

netstat, bence üçü içinde en az anlaşılan ama en çok bilgi veren komut. Hangi portların dinlendiğini, hangi bağlantıların aktif olduğunu, ağ istatistiklerini ve routing tablosunu gösterir. Güvenlik olaylarında, performans sorunlarında ve servis sorunlarında olmazmazdır.

Kritik Parametreler

-a: Tüm aktif bağlantıları ve dinlenen portları gösterir.

-n: Adresleri ve port numaralarını sayısal formatta gösterir. DNS çözümlemesi yapmaz, bu yüzden çok daha hızlı çalışır.

-o: Her bağlantı için PID (Process ID) gösterir. Hangi process hangi portu kullanıyor öğrenmek için kritik.

-b: Her bağlantıyı oluşturan executable’ı gösterir. Yönetici olarak çalıştırmanız gerekir.

-s: Protokol bazında istatistikleri gösterir.

-r: Routing tablosunu gösterir.

-p [protokol]: Belirli bir protokolü filtreler (TCP, UDP, TCPv6 vb.)

En Çok Kullandığım Kombinasyonlar

netstat -ano

Bu benim en çok kullandığım kombinasyon. -a tüm bağlantılar, -n sayısal format, -o PID. Hızlı çalışır ve çıktı okunabilirdir.

netstat -ano | findstr :443

443 portunu kullanan tüm bağlantıları filtreler. Belirli bir port için anlık durum analizi. :80, :3389, :1433 gibi kritik portları izlemek için bu kalıbı kullanın.

netstat -ano | findstr LISTENING

Sadece dinlenen portları gösterir. Hangi servislerin hangi portlarda beklediğini görmek için.

Gerçek Dünya Senaryo 3: Port Çakışması

Bir uygulama “Address already in use” veya “Port zaten kullanımda” hatası veriyor. netstat ile kolayca çözebilirsiniz:

netstat -ano | findstr :8080

Çıktıda 8080 portunu kullanan process’in PID’ini görürsünüz. Diyelim ki PID 4521 çıktı:

tasklist | findstr 4521

Bu size process adını verir. Eğer bu process gerekli değilse ya da hatalı çalışıyorsa, Task Manager’dan veya taskkill komutuyla sonlandırabilirsiniz.

Gerçek Dünya Senaryo 4: TIME_WAIT Problemi

Yüksek trafik alan sunucularda sıkça karşılaşılan bir durum: çok sayıda bağlantı TIME_WAIT durumunda sıkışıyor ve yeni bağlantı için port bulunamıyor.

netstat -ano | findstr TIME_WAIT | find /c "TIME_WAIT"

Bu komut, TIME_WAIT durumundaki bağlantı sayısını sayar. Eğer bu sayı binlerle ifade ediliyorsa, Windows’un ephemeral port aralığını veya TIME_WAIT süresini ayarlamanız gerekebilir. Registry üzerinden TcpTimedWaitDelay değerini düşürmek bu durumda yardımcı olur.

Güvenlik Perspektifinden netstat

Bir sunucuda olağandışı bir bağlantı fark ettiğinizde netstat ilk durak olmalı:

netstat -anob

Bu komut yönetici yetkisi gerektiriyor ve her bağlantıyı oluşturan executable’ı gösteriyor. Eğer svchost.exe veya explorer.exe gibi sistem process’leri beklenmedik dış IP’lere bağlantı kuruyorsa, bu ciddi bir uyarı işaretidir. Bağlantı kurulan IP adresleri için WHOIS sorgusu yapın, coğrafi konumu kontrol edin.

Potansiyel bir C&C (Command and Control) bağlantısı şüphesi varsa:

netstat -ano | findstr ESTABLISHED

Tüm aktif bağlantıları listeleyin ve yabancı IP adreslerini inceleyin. Internal ağ dışında kurulmuş beklenmedik ESTABLISHED bağlantılar araştırılmalıdır.

Routing Tablosu Analizi

Çoklu NIC olan sunucularda veya VPN bağlantısı aktifken routing sorunları yaşanabilir. Trafik yanlış interface’ten çıkıyor olabilir:

netstat -r

Bu komut, route print ile eşdeğer çıktı verir. Çıktıda şunlara dikkat edin:

• 0.0.0.0 Network Destination ile 0.0.0.0 Netmask: Bu default route’tur. Metric değeri düşük olan önce kullanılır. Birden fazla default route varsa ve metric değerleri birbirine yakınsa, trafik dengesiz dağılabilir.
• On-link: Bu interface üzerinden direkt erişilebilir anlamına gelir.

Eğer VPN açıkken normal internet trafiği de VPN’den gidiyorsa (split tunneling aktif değilse), netstat -r çıktısında VPN adaptörünün daha düşük metrik değerle default route eklediğini görebilirsiniz.

Komutları Birlikte Kullanmak

Üç komutu birbirleriyle kombinleyerek çok daha güçlü bir tanılama süreci oluşturabilirsiniz. İşte gerçek hayatta uyguladığım bir sorun giderme akışı:

Senaryo: SQL Server’a bağlanılamıyor, uygulama “connection timeout” hatası veriyor.

ipconfig /all

Önce sunucunun IP yapılandırmasını doğrulayın. DNS sunucusu doğru mu? Default gateway doğru mu? IP adresi beklediğimiz subnette mi?

ping <sql_server_ip> -n 10

SQL Server’ın IP adresine 10 ping atın. Paket kaybı var mı? Response time nasıl? 1ms ile 200ms arası yanıtlar varsa ağda ciddi bir gecikme problemi var.

netstat -ano | findstr :1433

SQL Server’ın 1433 portunu dinleyip dinlemediğini kontrol edin. Eğer SQL Server makinesi ise LISTENING görmelisiniz. Eğer istemci makinesi ise ESTABLISHED veya hiç çıktı olmayabilir, ki bu bağlantının kurulamadığını gösterir.

netstat -ano | findstr <sql_server_ip>

SQL Server IP’sine olan tüm bağlantıları listeleyin. Connection sayısı beklenenden fazla mı? Bu connection pool sorununa işaret edebilir.

Bu dört adımın kombinasyonu, sorunu genellikle birkaç dakika içinde lokalize etmenizi sağlar.

Çıktıları Kaydetmek ve Analiz Etmek

Özellikle aralıklı yaşanan sorunlarda, komut çıktılarını kayıt altına almak büyük önem taşır:

netstat -ano >> C:network_log.txt && echo %date% %time% >> C:network_log.txt

Bu komutu Windows Task Scheduler ile belirli aralıklarla çalıştırın. Sorun yaşandığı andaki ağ durumunu kayıt altına alır. Sonradan “o sırada ne oluyordu” sorusuna cevap verebilirsiniz.

Veya powershell ile daha zengin bir çıktı:

netstat -ano | Out-File -Append C:netstat_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt

Her çalıştırmada timestamp’li ayrı bir dosya oluşturur. Karşılaştırmalı analiz için çok kullanışlı.

Sonuç

ipconfig, ping ve netstat üçlüsü, Windows ağ tanılamasının alfabesi. Yıllarca bu araçları kullandım ve her seferinde yeni bir şey keşfettim. Burada anlattığım senaryo ve kombinasyonların büyük çoğunluğu, gerçek sorun giderme süreçlerinde öğrendiklerimden oluşuyor.

Şunu net söylemek istiyorum: Bu araçların parametrelerini ezberlemeniz gerekmiyor. Ama ne aradığınızı ve hangi parametrenin sizi oraya götüreceğini bilmeniz gerekiyor. netstat -ano ile PID bulup tasklist ile eşleştirme yapmak, ya da ping ile MTU problemini tespit etmek, bu tür pratik kombinasyonlar sizi diğer sysadmin’lerden ayıran şeydir.

Pratik öneri: Sonraki ağ sorununuzda doğrudan çözüme atlamayın. Önce ipconfig /all, sonra ping hiyerarşisi, sonra netstat. Bu üç adımlı yaklaşım, sizi çoğu zaman soruna en hızlı götüren yol olacaktır. Biraz disiplinli bir tanılama süreci, saatlerce rastgele deneme yanılma yapmaktan çok daha üretken.