Bir gece yarısı telefon çalıyor. Üretim sunucunuz erişilemez hale gelmiş, ekip panikliyor ve siz de neyin ne olduğunu bilmeden terminale oturuyorsunuz. İşte bu an, sistematik bir yaklaşımın ne kadar değerli olduğunu anladığınız andır. Ağ sorunları, rastgele komutlar çalıştırarak çözülmez. Katmanlı, metodolojik bir yaklaşım gerektirir. Bu yazıda, ağ sorunlarını adım adım nasıl gidereceğinizi, hangi komutları hangi sırayla kullanacağınızı ve gerçek dünya senaryolarında bu komutların bize ne anlattığını ele alacağız.
Temel Felsefe: OSI Modelini Aklınızda Tutun
Ağ sorunlarını gidermirken kafanızın bir köşesinde her zaman OSI katmanları olsun. Fiziksel katmandan başlayıp uygulama katmanına doğru çıkmak, size mantıklı bir yol haritası sunar. Kabloyu kontrol etmeden DNS sorununa atlamak zaman kaybıdır. Fiziksel bağlantı yok mu? Zaten her şey oradan çözülür.
Pratik olarak şöyle düşünebilirsiniz: Önce “makine ağda var mı?”, sonra “doğru yere bakıyor mu?”, ardından “hedefe ulaşabiliyor mu?” ve son olarak “uygulama katmanında sorun var mı?” sorularını sırasıyla yanıtlayın.
Adım 1: Arayüz Durumunu Kontrol Etmek
İlk durağımız ağ arayüzleri. Makine fiziksel veya sanal olarak ağa bağlı mı, bağlıysa IP adresi almış mı, arayüz UP durumda mı?
ip addr showBu komutun çıktısını okumayı bilmek kritik. Her arayüz için dikkat etmeniz gerekenler:
- state UP / state DOWN: Arayüzün fiziksel durumu
- inet 192.168.1.100/24: IPv4 adresi ve subnet maskesi
- inet6: IPv6 adresi (bazı servislerde bunu da kontrol etmeniz gerekebilir)
- link/ether: MAC adresi (aynı MAC iki yerde varsa cidli sorun)
Eski sistemlerde ifconfig hala kullanılıyor olabilir ama modern Linux sistemlerde ip komutu standart haline geldi. Eğer arayüz DOWN görünüyorsa:
sudo ip link set eth0 upArayüz UP ama IP adresi yoksa, DHCP’den adres almayı deneyin:
sudo dhclient eth0
# veya systemd-networkd kullanıyorsanız
sudo systemctl restart systemd-networkd
# NetworkManager kullanıyorsanız
sudo nmcli device connect eth0Gerçek dünya notu: Bir keresinde bir müşterinin sunucusu tam olarak bu nedenle erişilemez haldeydi. Fiziksel switch portu yanlışlıkla kapatılmış, arayüz DOWN durumuna düşmüştü. ip addr show bize bunu saniyeler içinde gösterdi.
Adım 2: Yönlendirme Tablosunu İncelemek
Arayüz UP ve IP adresi var, harika. Peki paketler nereye gidiyor? Yönlendirme tablosu olmadan, makine trafiği nereye göndereceğini bilmez.
ip route showBeklediğiniz çıktı şuna benzer olmalı:
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.100 metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100Burada default via satırı çok önemli. Bu satır yoksa, internete veya dış ağa hiçbir paket gidemez. Varsayılan gateway eksikse manuel ekleyebilirsiniz:
sudo ip route add default via 192.168.1.1 dev eth0Birden fazla ağ arayüzü olan sunucularda, yanlış gateway tanımlanmış olabilir. Örneğin eth0 iç ağ için, eth1 dış ağ için kullanılıyorsa, her ikisinin de doğru gateway’e işaret ettiğinden emin olun. Bu tür durumlarda metric değerleri de önem kazanır. Düşük metric, daha öncelikli route anlamına gelir.
Adım 3: Temel Bağlantı Testi – Ping
Arayüz OK, route OK. Şimdi gerçekten bir şeylere ulaşabiliyor muyuz?
# Önce loopback test edin
ping -c 4 127.0.0.1
# Sonra gateway'e ping atın
ping -c 4 192.168.1.1
# Ardından dış IP'ye (DNS olmadan test için)
ping -c 4 8.8.8.8Bu üç ping komutu aslında çok şey anlatır. Loopback çalışıyor ama gateway’e ping atılamıyorsa, sorun yerel ağda veya fiziksel bağlantıda. Gateway’e ulaşılıyor ama 8.8.8.8’e ulaşılamıyorsa, sorun ISP tarafında veya firewall’da. 8.8.8.8’e ulaşılıyor ama alan adları çözümlenemiyorsa, sorun DNS’de.
Ping çalışmıyor diye paniklemek de doğru değil. Bazı güvenlik duvarları ICMP paketlerini blokladığı için ping engelli olabilir. Bu yüzden ping başarısız olduğunda hemen “internet yok” demeyin.
# Ping atılamayan bir hedefe TCP ile test
curl -v --connect-timeout 5 https://google.comAdım 4: DNS Sorunlarını Tespit Etmek
DNS sorunları, ağ sorunlarının belki de en sık karşılaşılan nedenlerinden biri. “Siteye giremiyorum” diye gelen şikayetlerin yarısı DNS kaynaklıdır.
# DNS sorgulama
dig google.com
# Sadece A kaydı
dig google.com A
# Belirli bir DNS sunucusunu kullanarak sorgulama
dig @8.8.8.8 google.com
# nslookup alternatifi
nslookup google.com
nslookup google.com 8.8.8.8dig komutunun çıktısında dikkat etmeniz gerekenler:
- ANSWER SECTION: Yanıt geldi mi?
- Query time: Sorgu ne kadar sürdü? 2000ms üzeri ciddi gecikme var demek.
- SERVER: Hangi DNS sunucusuna sorgu atıldı?
Sistemin hangi DNS sunucularını kullandığını görmek için:
cat /etc/resolv.confEğer DNS çözümlemesi çalışmıyorsa ama IP ile ulaşılabiliyorsa, /etc/resolv.conf dosyasını kontrol edin ve geçici olarak Google DNS ekleyin:
# Geçici düzeltme (sistem yeniden başlatıldığında sıfırlanabilir)
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
# systemd-resolved kullanıyorsanız
sudo systemd-resolve --statusGerçek dünya senaryosu: Bir e-ticaret şirketinde gece 02:00’de alarmlar çalmaya başladı. Uygulama veritabanına bağlanamıyordu. DNS sorunu değil mi diye düşünülebilir ama /etc/resolv.conf incelendiğinde, systemd-resolved bir güncelleme sonrası düzgün yapılandırılmamış ve search domain listesi bozulmuştu. Uygulama FQDN yerine kısa isim kullanıyordu ve bu kısa isim artık çözümlenemiyordu.
Adım 5: Traceroute ile Paketin Yolculuğunu İzlemek
Ping atıyorsunuz ama yanıt yavaş veya paket kaybı var. Sorun nerede? Kendi ağınızda mı, ISP’de mi, uzak sunucuda mı?
traceroute google.com
# veya
traceroute -n google.com # DNS çözümlemesi olmadan, daha hızlı
# TCP tabanlı traceroute (ICMP bloklandığında işe yarar)
traceroute -T -p 80 google.comTraceroute çıktısında her satır bir “hop” yani bir yönlendiriciyi temsil eder. * görüyorsanız, o hop ICMP yanıtı vermiyor demek. Bu her zaman sorun değil, bazı yönlendiriciler ICMP yanıtlarını kasıtlı olarak bloklar.
# mtr - traceroute'un daha gelişmiş hali
sudo mtr google.com
sudo mtr --report --report-cycles 20 google.commtr komutunu özellikle seviyorum çünkü hem traceroute hem de ping özelliklerini bir arada sunar ve paket kaybını yüzde olarak gösterir. Bir hop’ta %10 paket kaybı varsa, sorun büyük ihtimalle o noktada. Ama sonraki hop’lar normal görünüyorsa, o ara hop sadece ICMP’yi throttle ediyor olabilir.
Adım 6: Port ve Servis Erişilebilirliği Kontrolü
Sunucu ping’e yanıt veriyor ama servise erişilemiyor. Sorun firewall mı, servis mi?
# Belirli bir portun açık olup olmadığını test et
telnet 192.168.1.10 80
# veya
nc -zv 192.168.1.10 80
# Birden fazla portu test etmek
nc -zv 192.168.1.10 80 443 8080
# UDP port testi
nc -zuv 192.168.1.10 53
# ss komutu ile yerel dinleyen portları listele
ss -tlnp
# Netstat ile (eski sistemler için)
netstat -tlnpss -tlnp komutu özellikle önemli. Bu komut size hangi servisin hangi portu dinlediğini gösterir. Eğer nginx 80 portunda dinlemiyorsa, dışarıdan da erişilemez.
# Belirli bir porta bağlanmayı test etmek için curl
curl -v telnet://192.168.1.10:22
curl -v http://192.168.1.10:80
# Sadece bağlantı testi, içerik indirmeden
curl -Is --connect-timeout 5 http://192.168.1.10Adım 7: Firewall Kurallarını İncelemek
“Porta erişilemiyor ama servis çalışıyor” diyorsanız, firewall büyük ihtimalle devrede.
# iptables kurallarını listele
sudo iptables -L -v -n
sudo iptables -L INPUT -v -n --line-numbers
# nftables kullanıyorsanız
sudo nft list ruleset
# firewalld kullanıyorsanız (CentOS/RHEL)
sudo firewall-cmd --list-all
sudo firewall-cmd --list-ports
# UFW kullanıyorsanız (Ubuntu)
sudo ufw status verboseFirewall kurallarını okurken dikkat etmeniz gerekenler:
- INPUT chain: Sunucuya gelen trafiği kontrol eder
- OUTPUT chain: Sunucudan çıkan trafiği kontrol eder
- FORWARD chain: Yönlendirilen trafiği kontrol eder
- DROP vs REJECT: DROP sessizce paketi düşürür, REJECT hata döner
Geçici olarak bir portu test amaçlı açmak için:
# iptables ile 8080 portuna izin ver
sudo iptables -I INPUT -p tcp --dport 8080 -j ACCEPT
# UFW ile
sudo ufw allow 8080/tcp
# firewalld ile
sudo firewall-cmd --add-port=8080/tcp --temporaryAdım 8: Paket Yakalama ve Analiz
Tüm kontrolleri yaptınız, hala sorun bulamadınız. Şimdi paketlerin gerçekten gidip gelmediğini görmek için tcpdump kullanma zamanı.
# Belirli bir arayüzde tüm trafiği yakala
sudo tcpdump -i eth0
# Belirli bir host ile olan trafiği yakala
sudo tcpdump -i eth0 host 192.168.1.10
# Belirli bir porta gelen/giden trafiği yakala
sudo tcpdump -i eth0 port 80
# HTTP trafiğini daha okunabilir biçimde görmek
sudo tcpdump -i eth0 -A port 80
# Dosyaya kaydet, Wireshark ile analiz et
sudo tcpdump -i eth0 -w /tmp/capture.pcap
# DNS sorgularını izle
sudo tcpdump -i eth0 -n port 53Tcpdump çıktısını okumak başta korkutucu gelir ama zamanla alışıyorsunuz. Önemli olan SYN, SYN-ACK, ACK üçlüsünü takip etmek. Eğer SYN gönderildi ama SYN-ACK gelmiyorsa, paket karşı tarafa ulaşmıyor veya firewall tarafından düşürülüyor demektir.
Gerçek dünya senaryosu: Bir müşterinin load balancer’ı backend sunuculardan yanıt alamıyordu. Ping çalışıyordu, port açıktı ama bağlantı kurulamıyordu. Tcpdump ile incelediğimizde, backend sunucunun SYN paketlerine yanıt verdiğini ama yanlış source IP ile yanıt döndüğünü gördük. Asimetrik routing sorunu vardı. Paketler bir yoldan geliyor, farklı bir yoldan geri dönüyordu ve stateful firewall bunu düşürüyordu.
Adım 9: Bant Genişliği ve Performans Testi
Bağlantı var, servisler çalışıyor ama yavaş. Performans sorunu mu var?
# iperf3 ile bant genişliği testi (server tarafında)
iperf3 -s
# Client tarafında
iperf3 -c 192.168.1.10
# UDP testi
iperf3 -c 192.168.1.10 -u -b 100M
# Arayüz istatistiklerini izle
watch -n 1 'cat /proc/net/dev'
# ip komutu ile istatistikler
ip -s link show eth0
# nload ile gerçek zamanlı bant genişliği izleme
nload eth0Arayüz istatistiklerinde yüksek hata sayısı (errors) veya paket düşmesi (drops) görüyorsanız, bu genellikle fiziksel katman sorununa işaret eder. Kötü kablo, hatalı NIC veya switch portu bunların başında gelir.
# Ethtool ile fiziksel bağlantı bilgisi
sudo ethtool eth0
# Bağlantı hızı ve duplex kontrolü
sudo ethtool eth0 | grep -E "Speed|Duplex|Link"Half-duplex / full-duplex uyumsuzluğu gerçek bir performans katildir. İki taraf farklı duplex modunda çalışıyorsa, ciddi performans sorunları ve yüksek çarpışma oranları görürsünüz.
Adım 10: Sistem Günlüklerini İncelemek
Tüm bu adımlar boyunca sistem günlükleri altın madenidir. Ağ sorunlarının büyük çoğunluğu bir log kaydı bırakır.
# Kernel mesajlarında ağ ile ilgili kayıtlar
sudo dmesg | grep -i -E "eth|link|network|error"
# Systemd journal ile ağ servis logları
sudo journalctl -u NetworkManager -f
sudo journalctl -u systemd-networkd -f
# Son 1 saatin logları
sudo journalctl --since "1 hour ago" | grep -i network
# Syslog üzerinden
sudo tail -f /var/log/syslog | grep -i network
sudo grep -i "network|eth|link" /var/log/kern.logBir bağlantı kesilip tekrar bağlandığında, dmesg’de genellikle “Link is Down” ve “Link is Up” mesajları görürsünüz. Bu mesajların zaman damgalarını inceleyerek sorunun ne zaman başladığını ve ne sıklıkta oluştuğunu anlayabilirsiniz.
Pratik Sorun Giderme Senaryosu: Hepsini Bir Araya Getirmek
Diyelim ki bir web sunucusuna erişilemiyor şikayeti aldınız. İşte sistematik yaklaşımınız:
# 1. Sunucuya SSH ile bağlanabiliyorsanız, arayüzü kontrol edin
ip addr show
ip route show
# 2. Gateway'e ulaşabiliyoruz mu?
ping -c 4 $(ip route | grep default | awk '{print $3}')
# 3. DNS çalışıyor mu?
dig google.com @8.8.8.8
# 4. Web servisi çalışıyor mu?
systemctl status nginx
# veya
systemctl status apache2
# 5. Port dinleniyor mu?
ss -tlnp | grep ':80|:443'
# 6. Firewall bloklama yapıyor mu?
sudo iptables -L INPUT -v -n | grep -E "80|443|DROP|REJECT"
# 7. Servise yerel olarak erişilebiliyor mu?
curl -I http://localhost
# 8. Dışarıdan test
curl -v http://sunucu-ip-adresiBu akış, sorunu katman katman izole etmenizi sağlar. Her adımda ya sorunu bulursunuz ya da bir sonraki katmana geçersiniz.
Sık Karşılaşılan Sorunlar ve Hızlı Çözümleri
IP çakışması (IP conflict):
# Ağda aynı IP'yi kullanan başka bir cihaz var mı?
sudo arping -I eth0 192.168.1.100MTU sorunları (büyük paketler gidemiyor):
# Farklı boyutlarda paket gönder
ping -c 4 -M do -s 1472 8.8.8.8
ping -c 4 -M do -s 1400 8.8.8.8
# MTU değerini kontrol et
ip link show eth0 | grep mtuARP tablosu sorunu:
# ARP tablosunu görüntüle
arp -n
ip neigh show
# ARP cache'i temizle
sudo ip neigh flush allSonuç
Ağ sorunları, sistematik yaklaşımla ele alındığında çoğu zaman beklenenden hızlı çözülür. Paniklemeden, OSI modelini aklınızda tutarak fiziksel katmandan uygulama katmanına doğru ilerleyin. ip, ping, dig, traceroute, ss, tcpdump gibi araçları öğrenmek için üretim ortamında sorun çıkmasını beklemeyin. Test ortamınızda kasıtlı olarak sorunlar yaratın ve bu araçlarla nasıl tespit edeceğinizi pratikte öğrenin.
En iyi sysadmin, en hızlı koşan değil; doğru yönde koşandır. Metodolojik yaklaşım, sizi gece yarısı panikten kurtarır ve daha da önemlisi, sorunu gerçekten çözdüğünüzden emin olmanızı sağlar. Her sorun giderme oturumundan sonra bir not tutun: neyi denediğinizi, neyin işe yarayıp yaramadığını. Zamanla bu notlar, kendi playbook’unuzu oluşturur ve benzer sorunları çok daha hızlı çözmenizi sağlar.