Ağ sorunları, sistem yöneticilerinin günlük hayatının kaçınılmaz bir parçası. Sabah işe geliyorsunuz, bir kullanıcı “internet yok” diye bağırıyor, bir başkası “sunucuya bağlanamıyorum” diyor. Bu anlarda hızlıca CMD açıp birkaç komut çalıştırabilmek, saatlerce sürebilecek sorun giderme sürecini dakikalara indirebilir. Bu yazıda Windows ortamında ağ sorunlarını gidermek için kullanabileceğiniz temel araçları, gerçek dünya senaryolarıyla birlikte ele alacağım.
Neden CMD ile Ağ Sorunlarını Gideriyoruz?
GUI tabanlı araçlar işe yarasa da CMD komutları birkaç önemli avantaj sunar. Öncelikle uzak masaüstü bağlantısı bile olmasa, sadece bir PowerShell remoting veya SSH bağlantısıyla komutları çalıştırabilirsiniz. Ayrıca betiklere entegre edebilir, zamanlanmış görevler oluşturabilir ve çıktıları log dosyalarına yönlendirebilirsiniz. GUI’de tek tek tıkladığınız şeyleri burada tek satırda halledebilirsiniz.
Şimdi gelelim bu araçların nasıl kullanıldığına.
ipconfig: Ağ Yapılandırmanızın Anlık Görüntüsü
ipconfig komutu, Windows’ta ağ arabirimi yapılandırmasını görüntülemek için kullanılan temel araçtır. Sorun gidermeye her zaman buradan başlamanızı öneririm çünkü önce “elimizde ne var” sorusunu yanıtlamamız gerekiyor.
Temel Kullanım
ipconfig
Bu komut size aktif ağ arabirimlerini, IP adreslerini, subnet mask’ı ve default gateway’i gösterir. Hızlı bir kontrol için yeterli.
ipconfig /all
/all parametresi çok daha fazla bilgi verir. DNS sunucuları, DHCP sunucusu adresi, MAC adresi (Physical Address), DHCP’nin etkin olup olmadığı ve lease bilgileri gibi detayları görebilirsiniz. Özellikle DHCP Enabled satırına dikkat edin. Statik IP olması gereken bir sunucuda burası “Yes” yazıyorsa sorun bulundu demektir.
DHCP Sorunlarını Gidermek
Bir kullanıcı veya sunucu 169.254.x.x gibi bir IP almışsa, DHCP sunucusuna ulaşamadığı anlamına gelir. Bu durumda şu komutları sırayla çalıştırın:
ipconfig /release
ipconfig /renew
/release mevcut IP adresini bırakır, /renew DHCP sunucusundan yeni bir adres ister. Eğer /renew sonrasında hala 169.254.x.x alıyorsanız, sorun DHCP sunucusunda ya da ağ altyapısındadır.
DNS Cache Sorunları
“Web sitesi açılmıyor ama ping atabiliyorum” şikayetlerinin büyük çoğunluğu DNS cache sorunudur. Özellikle bir sunucunun IP adresi değiştikten sonra eski kayıtlar cache’de kalabilir:
ipconfig /flushdns
Bu komutu çalıştırdıktan sonra Successfully flushed the DNS Resolver Cache mesajını görmelisiniz. Sonrasında bağlantıyı tekrar deneyin.
DNS cache içeriğini silmeden önce görüntülemek isterseniz:
ipconfig /displaydns
Bu çıktıda hangi alan adlarının hangi IP adreslerine çözümlendiğini görebilirsiniz. Hatalı bir kayıt varsa flushdns ile temizleyebilirsiniz.
Pratik parametre özeti:
- /all: Tüm arabirim detaylarını gösterir
- /release: DHCP IP adresini serbest bırakır
- /renew: DHCP’den yeni IP ister
- /flushdns: DNS çözümleyici önbelleğini temizler
- /displaydns: DNS önbellek içeriğini gösterir
- /registerdns: DNS kayıtlarını yeniden kaydeder
ping: Bağlantı Testi ve Gecikme Ölçümü
ping, ICMP Echo Request paketleri göndererek hedef hostun erişilebilir olup olmadığını test eder. Basit görünse de doğru parametrelerle çok güçlü bir araç haline gelir.
Temel Kullanım ve Senaryo
ping 8.8.8.8
Bu komut varsayılan olarak 4 paket gönderir. Eğer tüm paketler kayboluyorsa (Request timed out), hedef host erişilebilir değil ya da ICMP paketlerini engelliyor demektir. Firewall’ların ICMP’yi engelleyebildiğini unutmayın, bu yüzden ping başarısız olması mutlaka hostun down olduğu anlamına gelmez.
Sürekli Ping (Monitoring Senaryosu)
Ağ kararsızlığını tespit etmek için sürekli ping çok işe yarar:
ping -t 192.168.1.1
-t parametresi siz Ctrl+C ile durdurana kadar ping atmaya devam eder. Çıktıda aralıklı “Request timed out” görüyorsanız, ağ bağlantısı aralıklı kesiliyor demektir. Bu durumu kaydetmek için çıktıyı dosyaya yönlendirebilirsiniz:
ping -t 192.168.1.1 >> C:Logsping_log.txt
Paket Boyutu ve MTU Sorunları
Büyük paketlerin iletiminde sorun yaşandığını düşünüyorsanız, farklı boyutlarda paketlerle test edebilirsiniz:
ping -l 1472 -f 8.8.8.8
Burada -l 1472 paket boyutunu 1472 byte olarak ayarlar, -f ise “Don’t Fragment” bayrağını set eder. Eğer bu ping başarısız olup küçük paketlerle başarılı oluyorsa, MTU sorunuyla karşı karşıyasınız demektir. VPN tünelleri ve bazı ISP altyapıları bu soruna sık yol açar.
Ping ile Sistematik Sorun Tespiti
Gerçek bir senaryo üzerinden gidelim: Kullanıcı bir web sitesine erişemiyor. Şu sırayla ping testi yapın:
ping 127.0.0.1
ping 192.168.1.254
ping 8.8.8.8
ping google.com
127.0.0.1(loopback) başarısızsa TCP/IP stack’inde ciddi bir sorun var- Default gateway’e ping başarısızsa yerel ağ bağlantısı kopuk
8.8.8.8başarısız ama gateway başarılıysa ISP veya routing sorunu- IP ping başarılı ama alan adı başarısızsa DNS sorunu var
Bu sistematik yaklaşım, sorunun tam olarak nerede olduğunu hızla belirlemenizi sağlar.
Pratik parametre özeti:
- -t: Sürekli ping atar, Ctrl+C ile durdurulur
- -n [sayı]: Belirtilen sayıda paket gönderir
- -l [boyut]: Paket boyutunu byte cinsinden ayarlar
- -f: Fragment edilmez bayrağı ekler
- -i [TTL]: Time to Live değerini ayarlar
- -w [ms]: Yanıt için bekleme süresini milisaniye cinsinden ayarlar
- -4: IPv4 kullanmaya zorlar
- -6: IPv6 kullanmaya zorlar
tracert: Paketin Yolculuğunu İzlemek
ping ile hedefin erişilebilir olup olmadığını test edersiniz, ancak bağlantı sorunlarında paketin tam olarak nerede takıldığını bulmak için tracert kullanırsınız.
tracert google.com
Her satır bir “hop” yani bir yönlendirici veya ağ cihazını temsil eder. Üç süre sütunu göreceksiniz, bunlar üç farklı probe paketinin yanıt süresidir. Eğer belirli bir hop’tan sonra yıldız (*) görüyorsanız, o noktadan ötesi erişilebilir değil demektir.
tracert -d 192.168.10.50
-d parametresi DNS çözümlemesini devre dışı bırakır, bu da her hop için DNS sorgusu yapılmamasını sağlar. Sonuç olarak tracert çok daha hızlı tamamlanır. Uzak bir sunucuya tracert atarken bu parametreyi kullanmanızı öneririm.
netstat: Ağ Bağlantılarını ve Portları İzlemek
netstat komutu, aktif ağ bağlantılarını, dinleme durumundaki portları, istatistikleri ve routing tablosunu görüntüler. Özellikle “hangi uygulama hangi portu kullanıyor” sorusunu yanıtlamak için vazgeçilmezdir.
Aktif Bağlantıları Görüntülemek
netstat -an
Bu komut tüm aktif bağlantıları ve dinleme durumundaki portları sayısal formatta gösterir. -a tüm bağlantıları ve listening portları, -n ise sayısal adresleri (DNS çözümlemesi olmadan) gösterir. Çıktı hızlıca uzun bir liste haline geleceğinden, belirli bir port için filtreleme yapabilirsiniz:
netstat -an | findstr :443
Bu komut 443 portuyla ilgili tüm bağlantıları listeler. Bir web sunucusu üzerinde çalışıyorsanız kaç aktif HTTPS bağlantısı olduğunu böyle görebilirsiniz.
Hangi Uygulama Hangi Portu Kullanıyor?
Bir port çakışması yaşadığınızda veya hangi uygulamanın belirli bir portu dinlediğini bulmak istediğinizde:
netstat -ano
-o parametresi her bağlantı için PID (Process ID) bilgisini ekler. PID’yi öğrendikten sonra Task Manager veya tasklist komutuyla uygulamayı tespit edebilirsiniz:
tasklist | findstr "1234"
Burada 1234 yerine netstat çıktısında gördüğünüz PID’yi yazın.
Gerçek Dünya Senaryosu: Port 8080 Çakışması
Bir uygulama sunucusuna yeni bir servis kuruyorsunuz ama servis başlamıyor. Log’larda “Port 8080 already in use” hatası görüyorsunuz:
netstat -ano | findstr :8080
Çıktıda şöyle bir şey göreceksiniz:
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 3456
PID 3456 olan process’i bulun:
tasklist /FI "PID eq 3456"
Çıktı size tam olarak hangi uygulamanın bu portu kullandığını söyler. Artık ya o uygulamayı kapatabilir ya da yeni servisiniz için farklı bir port yapılandırabilirsiniz.
Bağlantı İstatistiklerini İzlemek
Sunucuda paket kaybı veya bağlantı sorunları yaşandığında protokol istatistiklerine bakmak faydalı olabilir:
netstat -s
Bu komut TCP, UDP, IP ve ICMP protokolleri için ayrıntılı istatistikler gösterir. TCP kısmındaki Segments Retransmitted değeri yüksekse, ağda ciddi paket kaybı var demektir. Connection Failures ve Connections Reset değerleri de dikkat etmeniz gereken metriklerdir.
Pratik parametre özeti:
- -a: Tüm bağlantıları ve listening portları gösterir
- -n: Sayısal adres ve port numaraları kullanır
- -o: Her bağlantı için PID gösterir
- -s: Protokol bazlı istatistikleri gösterir
- -r: Routing tablosunu gösterir
- -b: Her bağlantı için uygulamayı gösterir (yönetici yetkisi gerekir)
- -p [protokol]: Belirli bir protokol için filtreler (TCP, UDP, ICMP)
nslookup ve DNS Sorunlarını Gidermek
DNS sorunları ağ şikayetlerinin önemli bir bölümünü oluşturur. nslookup komutu bu sorunları gidermek için temel araçtır.
nslookup google.com
Varsayılan DNS sunucunuzu kullanarak sorgu yapar. Çıktıda sunucu adını, sunucu IP’sini ve sorguladığınız alan adının IP adreslerini görürsünüz.
Belirli bir DNS sunucusunu test etmek için:
nslookup google.com 8.8.8.8
Bu komut Google’ın DNS sunucusunu kullanarak sorgu yapar. Kendi DNS sunucunuz çalışmıyor ama 8.8.8.8 ile sorgu başarılıysa, sorun kendi DNS sunucunuzdadır.
Gelişmiş Senaryo: Sunucu Erişim Sorununun Tam Tespiti
Diyelim ki uygulama ekibi “192.168.50.100 sunucusundaki servise bağlanamıyoruz” dedi. İşte adım adım sorun giderme sürecim:
Adım 1: Temel bağlantıyı test et
ping 192.168.50.100
Eğer ping başarılıysa, sunucu fiziksel olarak erişilebilir. Başarısızsa tracert ile yolu kontrol et.
Adım 2: Servis portunu test et
netstat -an | findstr 192.168.50.100
Aktif bağlantı var mı? Varsa hangi durumdalar? ESTABLISHED mi, TIME_WAIT mi?
Adım 3: Hedef sunucudan port dinleniyor mu?
Hedefe RDP veya başka bir yolla bağlanabiliyorsanız, orada şunu çalıştırın:
netstat -ano | findstr :8443
Port LISTENING durumundaysa servis çalışıyor demektir. Sorun muhtemelen firewall’dadır.
Adım 4: DNS çözümlemesini kontrol et
nslookup appserver01
ipconfig /displaydns | findstr appserver01
Eski bir IP cache’de kalıyor olabilir. ipconfig /flushdns ile temizleyin.
Adım 5: Routing tablosunu kontrol et
route print
Hedef IP için doğru bir route var mı? Default gateway doğru mu? Bu sorular routing sorunlarını ortaya çıkarır.
Faydalı Kombinasyonlar ve Otomasyon
Gerçek hayatta bu komutları tek tek değil, birlikte kullanırsınız. İşte bazı pratik kombinasyonlar:
Ağ durumunu tek komutla kaydet:
(echo === ipconfig /all ===) & ipconfig /all & (echo === netstat -an ===) & netstat -an & (echo === route print ===) & route print > C:Logsnetwork_snapshot.txt
Belirli aralıklarla ping testi yap ve kaydet:
for /L %i in (1,1,100) do (ping -n 1 192.168.1.1 >> ping_results.txt & timeout /t 5 /nobreak > nul)
Bu komut 100 kez, 5 saniye aralıklarla ping atar ve sonuçları dosyaya kaydeder. Ağ kararsızlığını belgelerken çok işe yarar.
Ağ bağlantısı koptuğunda event oluştur:
ping -n 1 8.8.8.8 | findstr "TTL" > nul || echo %date% %time% - Baglanti koptu >> C:Logsconnectivity.log
Bu satırı zamanlanmış görev olarak her dakika çalıştırırsanız, bağlantı sorunlarının tam zamanını kayıt altına alırsınız.
Dikkat Edilmesi Gereken Noktalar
Ağ sorunlarını giderirken sık yapılan hatalardan bahsetmek gerekiyor:
Ping’e fazla güvenmek: Birçok firewall ve host, ICMP paketlerini engeller. Ping başarısız olması her zaman host’un down olduğu anlamına gelmez. Port bazlı testleri de mutlaka yapın.
DNS cache’i göz ardı etmek: “Bağlantı sağlıklı ama site açılmıyor” diye saatlerce uğraşılan sorunların büyük kısmı ipconfig /flushdns ile çözülür. Bunu erken aşamada deneyin.
netstat çıktısını yanlış yorumlamak: TIME_WAIT durumundaki bağlantılar kaygı verici görünse de normaldir. TCP protokolü gereği bağlantılar kapandıktan sonra bir süre bu durumda kalır. Binlerce TIME_WAIT varsa ve artıyorsa o zaman incelemeniz gerekir.
IPv6’yı unutmak: Sorun giderirken sadece IPv4’e odaklanmak yaygın bir hatadır. ipconfig /all çıktısında IPv6 adreslerine de bakın. Bazı uygulamalar IPv6 üzerinden bağlantı kurmaya çalışır ve beklenmedik davranışlar ortaya çıkabilir.
Sonuç
CMD tabanlı ağ araçları, yıllarca Windows sistem yöneticilerinin temel silahları olmuştur ve olmaya devam edecektir. ipconfig ile mevcut durumu tespit edip, ping ile temel bağlantıyı test eder, tracert ile paketin yolunu izler, netstat ile hangi portların ne durumda olduğunu anlarsınız. Bu araçları birlikte ve sistematik bir şekilde kullanmak, karmaşık görünen sorunları dakikalar içinde çözmenizi sağlar.
Üstelik bu komutların hepsini betiklere entegre edebilir, zamanlanmış görevler olarak çalıştırabilir ve çıktıları merkezi log sistemlerinize gönderebilirsiniz. GUI araçları ne kadar gelişse de, komut satırının betiklenebilirliği ve uzaktan erişilebilirliği onu her zaman vazgeçilmez kılacaktır.
Bir dahaki ağ sorununda doğrudan Google aramak yerine önce bu adımları takip edin. Çoğu zaman cevabı zaten kendi komut satırınızda bulacaksınız.