Ağ Sorun Giderme Komutları: Ping, Traceroute, DNS, Port

“İnternet yok” ya da “sunucuya ulaşamıyorum” diye başlayan bir sorunda ilk iş birkaç komut çalıştırmaktır. Ama bir komutun çıktısı, kendisine sorulan sorudan fazlasını söylemez. Ping’e yanıt gelmemesi sunucunun kapalı olduğunu göstermez; traceroute’ta yıldız görmek yolun orada kesildiği anlamına gelmez. Bu yazı en sık kullanılan komutları tek tek ele alıyor: her biri hangi soruyu cevaplar, çıktısı nasıl okunur, başarılı ya da başarısız sonuç neyi kanıtlar ve neyi kanıtlamaz.

Komutlar Windows ve Linux içindir. Örneklerde sitenin adres planını kullanıyoruz: istemci 10.0.20.25, gateway 10.0.20.1, intranet sunucusu 10.0.30.10, DNS sunucusu 10.0.30.11. Yazıdaki bütün çıktılar temsili, öğretici çıktılardır; gerçek bir ağda ölçülmemiştir ve satırlar işletim sistemi sürümüne göre biraz farklı görünebilir.

Her komut tek bir soruyu cevaplar. Sağdaki sütun, sonucun tek başına söylemediği şeydir; sonraki bölümler her satırı açıyor.

Önce kendi makineniz: adres ve rota

Uzağı test etmeden önce istemcinin kendi ayarına bakılır: Windows’ta ipconfig /all, Linux’ta ip addr ve ip route. Hangi dört değerin kontrol edileceği ve yanlış olduklarında ne anlama geldikleri Wi-Fi Bağlı Ama İnternet Yok yazısında anlatıldı; burada tekrar etmiyoruz.

Bir şey eklemek yararlı: belirli bir hedefe giden trafiğin hangi yoldan çıkacağını sormak. Linux’ta ip route get 10.0.30.10 çekirdeğin o hedef için seçeceği rotayı, gateway’i ve arayüzü gösterir; man sayfasına göre bunu yaparken paket göndermez. Windows’ta route print yönlendirme tablosunun tamamını listeler. İki komut da yalnızca yerel kararı gösterir; o gateway’in paketi gerçekten ileteceğini kanıtlamaz. İstemcinin gateway’in MAC adresini öğrenip öğrenmediğini ise arp -a (Windows) ve ip neigh show (Linux) gösterir; ARP tablosunun nasıl okunduğu MAC, IP, ARP ve Default Gateway yazısında.

ping: hedef yanıt veriyor mu?

ping 10.0.30.10            (Windows)
ping -c 4 10.0.30.10       (Linux)

Ping, hedefe ICMP Echo Request gönderir ve Echo Reply bekler. Varsayılanları işletim sistemine göre değişir ve bu fark çıktıyı yorumlarken önemlidir:

Windows: 4 istek gönderip durur. Veri alanı 32 bayttır, her yanıt için 4 saniye beklenir. -t ile siz durdurana kadar sürer.
Linux (iputils): -c verilmezse siz Ctrl+C ile durdurana kadar saniyede bir istek gönderir, durunca özet basar. Veri alanı 56 bayttır. Bazı sistemlerde başka bir ping uygulaması bulunabilir; varsayılanları kendi sisteminizin man sayfasından kontrol edin.

Pinging 10.0.30.10 with 32 bytes of data:
Reply from 10.0.30.10: bytes=32 time=1ms TTL=63
Reply from 10.0.30.10: bytes=32 time=1ms TTL=63
...
Ping statistics for 10.0.30.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Temsili Windows çıktısı. time gidiş-dönüş süresidir. TTL yanıt paketinin IP başlığından gelir; bu yazıda yorumlamıyoruz.

Yanıt geldiyse: ICMP Echo hedefe ulaşmış ve yanıt geri dönmüş demektir; bu hedef için iki yönlü bir IP yolu vardır. Ama bu, sunucudaki web servisinin çalıştığını ya da TCP 443’e izin verildiğini göstermez. Ping ICMP’yi test eder, uygulamayı değil.

Yanıt gelmediyse (Windows’ta Request timed out., Linux’ta yanıt satırı yok ve özetteki kayıp %100): süre içinde yanıt gelmemiştir. Nedeni hedefin kapalı olması olabilir; ama hedefin kendi güvenlik duvarı, yoldaki bir ACL ya da firewall politikası ICMP’yi düşürüyor ya da yanıt geri dönemiyor da olabilir. Ping bunlardan hangisi olduğunu söylemez.

“Unreachable” mesajı geldiyse: Yoldaki bir cihaz ICMP Destination Unreachable döndürmüştür; RFC 792 bu mesajda ağın, hostun, protokolün ya da portun ulaşılamaz olduğunu belirten kodlar tanımlar. Dikkat: Windows bu satırı da Reply from diye başlatır. Satırdaki adres hedefin değil, mesajı üreten cihazın adresidir; Reply from görmek başarı demek değildir.

traceroute: yol nerelerden geçiyor?

tracert -d 198.51.100.10          (Windows)
traceroute -n 198.51.100.10       (Linux)

-d ve -n, adımlardaki adresler için isim çözümlemesi yapılmasını engeller; çıktı daha hızlı gelir ve DNS sorunları sonucu karıştırmaz.

Traceroute, deneme paketlerini her adımda TTL değerini bir artırarak gönderir. TTL’si sıfıra düşen router paketi atar ve kaynağa bir ICMP Time Exceeded mesajı gönderebilir; çıktıdaki her satır bu mesajı gönderen cihazdır. Mekanizmanın ayrıntısı ICMP’nin konusu; burada okuma tarafına odaklanıyoruz.

İki işletim sistemi farklı paket gönderir:

Windows tracert ICMP Echo gönderir. Üst sınır -h ile değiştirilir; Microsoft’un örnek çıktısında 30 adımdır.
Linux traceroute (yaygın 2.1 sürümü) varsayılan olarak UDP datagramları gönderir; ilk deneme 33434 numaralı porta gider ve her denemede port bir artar. Her adıma üç deneme yapar, en fazla 30 adım gider. -I ile ICMP Echo, -T ile TCP SYN gönderir; TCP yönteminde hedef port varsayılan olarak 80’dir ve -p ile değiştirilir. Man sayfası UDP ve ICMP yöntemlerinin yetkisiz kullanıcılarca kullanılabileceğini belirtir; TCP yöntemi için bu notu vermez, sisteminizde sudo gerekebilir. Bu araç her dağıtımda kurulu gelmeyebilir.

Aynı hedefe giden iki komut bu yüzden farklı sonuç verebilir: bir firewall ICMP Echo’ya izin verip yüksek UDP portlarını düşürüyorsa Windows’ta iz tamamlanırken Linux’ta yıldızlarla biter.

Yıldızlı bir adımdan sonra yanıtlar sürüyorsa yol orada kesilmemiştir; yalnızca o cihaz deneme paketine yanıt vermemiştir.

Yıldız (*) ne demek? O deneme için zaman aşımı süresinde yanıt gelmemiştir. Microsoft’un belgesi bazı router’ların TTL’si dolan paketleri sessizce düşürdüğünü ve bu adımların tracert için görünmez kaldığını belirtir. Firewall’lar da politika gereği bu yanıtları göndermeyebilir ya da geçirmeyebilir. Yani yıldız bir cihazın deneme paketine yanıt vermediğini gösterir; trafiğin orada durduğunu değil.

Okurken iki durumu ayırın:

Yıldızdan sonra yanıtlar sürüyorsa yol o noktada kesilmemiştir; diyagramdaki 2. ve 4. adımlar böyledir.
Yıldızlar sona kadar sürüyorsa son yanıt veren adımdan sonrası hakkında traceroute bilgi veremez. Deneme paketleri düşüyor, yanıtlar dönmüyor ya da gerçekten bir kesinti var olabilir. Asıl uygulamanın trafiğiyle yapılan bir test (sonraki bölümler) bu belirsizliği çözer.

Satırdaki adres, Time Exceeded mesajını gönderen arayüzdür; Microsoft bunu router’ın yakın taraftaki arayüzü olarak tanımlar. Aynı router başka bir yönden bakıldığında başka bir adresle görünebilir.

DNS testleri: isim neye çözülüyor?

nslookup intranet.example.com 10.0.30.11            (Windows; Linux'ta kuruluysa)
Resolve-DnsName intranet.example.com                 (Windows PowerShell)
dig @10.0.30.11 intranet.example.com                 (Linux)
getent ahosts intranet.example.com                   (Linux)

Server:  dns.example.com
Address:  10.0.30.11

Name:    intranet.example.com
Address:  10.0.30.10

Temsili nslookup çıktısı. İlk blok soruyu kimin cevapladığını, ikinci blok cevabı gösterir.

Bu komutların hepsi aynı şeyi ölçmez. Ayrım şudur: DNS sunucusuna doğrudan soran araçlar ile işletim sisteminin isim çözümleme sırasını izleyen araçlar.

nslookup kendi sorgusunu gönderir. Microsoft’un belgesine göre ikinci parametre verilmezse varsayılan DNS sunucusuna, verilirse o sunucuya sorar; sorun giderme belgesi de nslookup’ın yalnızca yapılandırılmış birincil DNS sunucusuyla konuştuğunu belirtir. Windows’un DNS istemcisi ise önce önbelleğe, sonra hosts dosyasına bakar, en son DNS sunucusuna sorar. Bu yüzden hosts dosyasında kaydı olan bir isim için nslookup başka, tarayıcı başka bir adres görebilir.
dig sunucuyu @ ile vermezseniz /etc/resolv.conf’taki sunuculara sorar. Linux’ta işletim sisteminin sırasını (hosts dosyası, DNS ve diğer kaynaklar, /etc/nsswitch.conf ayarına göre) görmek için getent ahosts kullanılır. dig ve Linux’taki nslookup her dağıtımda kurulu gelmeyebilir; çoğu zaman ayrı bir DNS araçları paketindedir.
Resolve-DnsName seçeneklerine göre davranır. Microsoft’un sorun giderme belgesindeki örnekte, hosts dosyasında kaydı olan bir isim ağa hiç sorgu gitmeden o kayıtla döner. -NoHostsFile hosts dosyasını atlar, -CacheOnly yalnızca yerel önbellekten cevaplar, -Server sorulacak sunucuyu belirler, -DnsOnly yalnızca DNS protokolünü kullanır (LLMNR ve NetBIOS denenmez). Windows’ta önbelleği ipconfig /displaydns gösterir; hosts dosyasından yüklenen kayıtlar da buradadır. ipconfig /flushdns önbelleği temizler.

Tarayıcı da farklı davranabilir: kendi önbelleği ve DNS ayarları olabilir. Kısacası bir DNS testi, sorduğunuz kaynağın o anki cevabını gösterir; uygulamanın aynı cevabı kullandığını değil.

Hata mesajlarını da ayırın. Microsoft’un nslookup belgesindeki tabloya göre timed out, sunucunun belirli süre ve deneme sonunda yanıt vermediği anlamına gelir: sunucuya ulaşılamıyor, yolda filtre var ya da servis çalışmıyor olabilir. Nonexistent domain ise sunucunun yanıt verdiğini ve bu ismi tanımadığını gösterir; ağ yolu çalışmaktadır, sorun kayıttadır ya da yanlış sunucuya sorulmuştur. Refused sunucunun isteği reddettiği anlamına gelir. İç ve dış DNS sunucusunu karşılaştırarak sorunu ayırmak Wi-Fi Bağlı Ama İnternet Yok yazısındaki akışın bir adımıdır.

Port testi: TCP portu yanıt veriyor mu?

Test-NetConnection 10.0.30.10 -Port 443       (Windows PowerShell)

ComputerName     : 10.0.30.10
RemoteAddress    : 10.0.30.10
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 10.0.20.25
TcpTestSucceeded : True

Temsili çıktı. TcpTestSucceeded : True, istemci ile sunucu arasında 443 numaralı portta TCP el sıkışmasının tamamlandığını gösterir: o portta dinleyen bir servis vardır ve yol iki yönde bu akışa izin verir. False ise bağlantının kurulamadığını söyler. Belge, kapalı bir portu bir firewall’un düşürdüğü porttan ayıran bir alan tanımlamaz; nedeni başka yoldan aranır.

Microsoft’un belgesi bu cmdlet için ping, TCP testi ve rota izleme tanımlar; -Port bir TCP portudur. UDP’de el sıkışma yoktur ve bir UDP portunu “açık” diye doğrulayan genel bir test yoktur: kapalı bir UDP portu sessiz kalabilir, açık bir port da anlamadığı bir isteğe yanıt vermeyebilir. UDP servisini en iyi o servisin kendi isteği test eder. DNS için UDP/53 testi, yukarıdaki nslookup ya da dig sorgusunun kendisidir.

curl -v: uygulama hangi aşamaya kadar geliyor?

curl.exe -v https://intranet.example.com/      (Windows)
curl -v https://intranet.example.com/          (Linux)

curl -v, bir HTTPS isteğini adım adım gösterir ve TCP testinin bittiği yerden devam eder. Curl belgesine göre * ile başlayan satırlar curl’ün ek bilgisi, > ile başlayanlar gönderilen başlıklar, < ile başlayanlar alınan başlıklardır.

*   Trying 10.0.30.10:443...
* Connected to intranet.example.com (10.0.30.10) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=intranet.example.com
> GET / HTTP/2
> Host: intranet.example.com
< HTTP/2 200

Temsili çıktı; satırların metni curl sürümüne göre değişir. Aşamaları şöyle okuyun:

Trying 10.0.30.10:443: İsim çözülmüş, TCP bağlantısı deneniyor. Burada takılıp zaman aşımı alıyorsanız sorun TCP yolundadır.
Connected: TCP el sıkışması tamam. Test-NetConnection’ın gösterdiği nokta budur.
TLS satırları: TLS el sıkışması ve sertifika. Curl sertifikayı varsayılan olarak doğrular; sertifika güvenilir değilse ya da URL’deki isimle eşleşmiyorsa burada hata verir ve durur. -k doğrulamayı kapatır; teşhis dışında kullanmayın.
< HTTP/2 200: Sunucu isteği karşılamıştır. Başka bir durum kodu da bir HTTP yanıtıdır; TCP ve TLS aşamaları geçilmiştir. RFC 9110’a göre 403 sunucunun isteği anladığını ama karşılamayı reddettiğini, 502 gateway ya da proxy olarak çalışan sunucunun arkadaki (upstream) sunucudan geçersiz bir yanıt aldığını, 503 sunucunun isteği şu an karşılayamadığını (örneğin geçici aşırı yük ya da bakım) belirtir. Kod sorunun hangi katmanda görüldüğünü daraltır ama kök nedeni tek başına göstermez; neden sunucu ya da proxy loglarında aranır.

Bu yüzden “porta bağlanılıyor” demek “uygulama çalışıyor” demek değildir. Ters yönde de geçerlidir: 200 almak, uygulamanın her işlevinin (oturum açma, dosya yükleme) çalıştığını göstermez.

İki not: Windows PowerShell 5.1’de curl bir takma addır ve Invoke-WebRequest çalıştırır; gerçek curl için curl.exe yazın. PowerShell 7’de bu takma ad yoktur. Ayrıca curl belgesi -v çıktısının çerez ya da kimlik bilgisi gibi hassas veri içerebileceği konusunda uyarır; çıktıyı paylaşmadan önce kontrol edin.

netstat ve ss: bu makinede ne dinliyor, kime bağlı?

netstat -ano          (Windows)
ss -tunap             (Linux)

Bu komutlar ağa paket göndermez; makinenin kendi soketlerini listeler. netstat -ano bütün TCP bağlantılarını ve dinlenen TCP/UDP portlarını (-a), sayısal adreslerle (-n) ve her birinin süreç kimliğiyle, yani PID ile (-o) gösterir. ss -tunap TCP (-t) ve UDP (-u) soketlerini, isim çözmeden (-n), dinleyenler dahil (-a) ve süreç bilgisiyle (-p) listeler.

  Proto  Local Address        Foreign Address      State          PID
  TCP    10.0.20.25:51514     10.0.30.10:443       ESTABLISHED    4120

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511    127.0.0.1:443       0.0.0.0:*         users:(("nginx",pid=812,fd=6))

Temsili çıktılar. İlk satır istemci tarafıdır: 10.0.20.25, geçici port 51514’ten sunucunun 443 numaralı portuna bağlı. İkinci satır bir sunucuda görülebilecek bir tuzağı gösterir: servis 443’te dinliyor ama yalnızca 127.0.0.1 adresinde. Bu servise yalnızca makinenin kendisi ulaşabilir; ağdan bu porta gelen bağlantılar kabul edilmez. Tüm arayüzlerde dinleyen bir servis 0.0.0.0:443 ya da *:443 olarak görünür.

Gösterir: Yerel soketleri, TCP durumlarını (LISTEN, ESTABLISHED, TIME_WAIT gibi) ve soketin hangi sürece ait olduğunu. Kanıtlamaz: Portun ağdan erişilebilir olduğunu. Makinenin kendi güvenlik duvarı ya da yoldaki bir firewall bağlantıyı yine engelleyebilir; bunu ancak başka bir makineden yapılan bir bağlantı testi gösterir.

Süreç bilgisi için yetki gerekebilir. Microsoft, yürütülebilir dosya adını gösteren netstat -b seçeneğinin yeterli yetki olmadan başarısız olacağını belirtir; bunun için genellikle yönetici olarak açılmış bir komut istemi kullanılır. Linux’ta ss -p başka kullanıcılara ait soketlerin süreç bilgisini sudo olmadan göstermeyebilir.

macOS için kısa not

macOS’ta ping, traceroute, nslookup, dig ve curl Terminal’de kullanılabilir, ama BSD kökenli oldukları için seçenekler ve varsayılanlar Linux’takilerle birebir aynı değildir. ip ve ss komutları yoktur. Bir seçeneği kullanmadan önce man ping gibi kendi sisteminizin belgesine bakın.

Kendinizi deneyin

Alıştırma 1: Windows çalışan istemciden (10.0.20.25) ping 10.0.30.10 dört kez Request timed out. veriyor. Hemen ardından Test-NetConnection 10.0.30.10 -Port 443 çalıştırıyorsunuz ve TcpTestSucceeded : True alıyorsunuz. Sunucu çalışıyor mu? Ping’in başarısız olmasının nedeni kesin olarak söylenebilir mi?

Cevap ve açıklama

Sunucu çalışıyor mu? Sunucu açık ve 443’te TCP bağlantısı kabul eden bir servis var; istemciyle sunucu arasındaki yol bu akışa iki yönde izin veriyor. TcpTestSucceeded : True yalnızca TCP bağlantısının kurulabildiğini gösterir; HTTPS hizmetinin bütünüyle çalıştığını göstermez.
Ping neden başarısız? ICMP Echo ya da Echo Reply bir yerde düşürülüyor olabilir: sunucunun kendi güvenlik duvarı, yoldaki bir ACL ya da firewall politikası. Ping’in sonucu bu adaylardan hangisi olduğunu ayırmaz; neden kesin olarak belirlenemez.
Ne yapılır? Ping sonucu tek başına “sunucu kapalı” diye yorumlanmamalıdır. Asıl soru HTTPS erişimiyse TLS el sıkışması, sertifika ve HTTP yanıtı curl -v ile ayrıca doğrulanır. ICMP’nin neden yanıtlanmadığı önemliyse sunucunun güvenlik duvarı kuralları ve yoldaki politika incelenir ya da trafik iki uçta yakalanır.

Alıştırma 2: Linux çalışan bir istemciden traceroute -n 198.51.100.10 çalıştırıyorsunuz. Birinci adımda 10.0.20.1 yanıt veriyor; 2’den 30’a kadar bütün satırlar * * *. Aynı istemcide curl -v https://portal.example.com/ (adres 198.51.100.10) Connected satırını, TLS el sıkışmasını ve HTTP/2 200 yanıtını gösteriyor. Yol 2. adımda kesik mi? Yıldızlar neden görünüyor olabilir?