Ağ Bağlantısı Neden Kesilir: Temel Sorun Giderme Yaklaşımı

Ağ bağlantısının kesilmesi, bir sysadmin olarak en sinir bozucu durumların başında gelir. Özellikle gece 2’de telefon açılıp “sunucuya bağlanamıyorum” denildiğinde, kafanızda onlarca olasılık dönmeye başlar. Fiziksel mi, yazılımsal mı, DNS mi, routing mi? Bu yazıda sistematik bir yaklaşımla ağ bağlantı sorunlarını nasıl çözeceğinizi, hangi araçları kullanacağınızı ve gerçek dünya senaryolarında nelere dikkat etmeniz gerektiğini ele alacağız.

Önce Paniklemeden Durumu Değerlendir

Bir ağ sorunu geldiğinde yapılacak ilk şey, sorunu doğru tanımlamaktır. “Bağlantı yok” ifadesi aslında çok geniş bir kavram. Bağlantı tamamen mı yok, yoksa yavaş mı çalışıyor? Belirli bir hedefe mi ulaşılamıyor, yoksa genel mi? Sorun yeni mi başladı, yoksa hep böyle miydi?

Bu soruların cevapları sizi doğrudan doğru yöne yönlendirir. Sistematik yaklaşım olmadan saatlerce hata ayıklayabilirsiniz. OSI modelini aklınızın bir köşesinde tutun: fiziksel katmandan başlayın, uygulama katmanına doğru ilerleyin.

Fiziksel Katman: Kablo, NIC ve Bağlantı Durumu

Evet, bazen sorun gerçekten kablo olabiliyor. Kariyer boyunca kaç kez “bu olamaz” diyerek başladığım sorunun gevşek bir kablo olduğuna tanık oldum. Önce fiziksel durumu kontrol edin.

Linux’ta network arayüzünün durumunu görmek için:

ip link show
ip addr show

Bu komutlar arayüzlerin UP/DOWN durumunu, MAC adreslerini ve atanmış IP adreslerini gösterir. Eğer bir arayüz DOWN durumundaysa:

ip link set eth0 up

Daha ayrıntılı donanım bilgisi için:

ethtool eth0

Bu komutun çıktısında Speed, Duplex ve Link detected: yes/no satırlarına bakın. Eğer link detected: no görüyorsanız sorun fiziksel katmanda demektir. Windows tarafında ise Device Manager üzerinden NIC durumuna bakabilir ya da PowerShell ile şunu çalıştırabilirsiniz:

Get-NetAdapter | Select-Object Name, Status, LinkSpeed

Duplex uyumsuzluğu da klasik bir tuzaktır. Switch portunda full-duplex ayarlıyken NIC’in half-duplex olarak müzakere etmesi, bağlantının kurulmasına rağmen ciddi paket kayıplarına yol açar. ethtool çıktısındaki Duplex satırını switch konfigürasyonuyla karşılaştırın.

IP Katmanı: Adres, Subnet ve Gateway Kontrolü

Fiziksel bağlantı tamam, ama IP yapılandırması sorunlu olabilir. DHCP’den adres alınamaması, yanlış subnet mask veya eksik gateway bu katmanda sıkça karşılaşılan sorunlardır.

Mevcut IP konfigürasyonunu kontrol etmek için:

ip addr show eth0
ip route show

ip route show çıktısında mutlaka bir default route görmelisiniz. Örneğin:

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.100 metric 100

Eğer default route yoksa dış dünyaya paket gönderemezsiniz. Manuel olarak eklemek için:

ip route add default via 192.168.1.1 dev eth0

DHCP istemcisini yeniden başlatmak da işe yarayabilir:

dhclient -r eth0 && dhclient eth0

Ya da systemd tabanlı sistemlerde:

systemctl restart NetworkManager

Gerçek Dünya Senaryosu: Duplicate IP

Bir keresinde production ortamında iki sunucuya aynı statik IP atanmıştı. Her iki sunucu da zaman zaman ağa erişemez hale geliyordu, sorun aralıklı olduğu için tespit etmek zorlaşmıştı. arping komutu bu tür sorunları hemen gün yüzüne çıkarır:

arping -I eth0 192.168.1.100

Eğer farklı MAC adreslerinden yanıtlar geliyorsa ağda aynı IP’yi kullanan birden fazla cihaz var demektir. Bu durumda iki yanıt satırı görürsünüz ve hangi MAC adresinin sorunlu olduğunu anlayabilirsiniz.

ICMP ile Temel Erişilebilirlik Testi

Fiziksel ve IP katmanları tamam, sıra erişilebilirlik testine geliyor. ping komutu basit görünür ama doğru yorumlandığında çok şey söyler.

ping -c 4 -W 2 8.8.8.8
ping -c 4 192.168.1.1
ping -c 4 google.com

Bu üç komutu sırayla çalıştırın. Mantığı şudur:

• Gateway ping’i: Yerel ağ bağlantısı var mı?
• Harici IP ping’i: Internet erişimi var mı?
• Domain ping’i: DNS çalışıyor mu?

Eğer gateway’e ping atabiliyorsunuz ama 8.8.8.8’e atamıyorsanız sorun routing veya NAT’ta. 8.8.8.8’e atabiliyorsunuz ama google.com’a atamıyorsanız sorun DNS’te. Bu üçlü test, sorunu hangi katmana atmanız gerektiğini hızla gösterir.

Ping sonuçlarında packet loss ve RTT değerlerine dikkat edin. %0 kayıp ve sabit RTT mükemmel durumu, aralıklı kayıplar ve değişken RTT ise bağlantı kalitesi sorununu işaret eder.

DNS Sorunlarını Tespit Etmek

DNS sorunları, bağlantı var ama “site açılmıyor” gibi şikayetlerin arkasındaki en yaygın nedendir. Önce hangi DNS sunucusunu kullandığınızı kontrol edin:

cat /etc/resolv.conf
resolvectl status

Sonra DNS çözümlemesini test edin:

nslookup google.com
dig google.com
dig google.com @8.8.8.8

dig komutu çok daha detaylı bilgi verir. Çıktıda ANSWER SECTION boşsa veya SERVFAIL görüyorsanız DNS sunucusu sorunlu demektir. Son satırdaki Query time değerine de bakın; normal bir DNS sorgusu 1-50ms arasında cevaplanmalıdır, 1000ms üzeri değerler DNS sunucusunda sorun olduğuna işaret eder.

Google’ın DNS sunucusuna yönlendirdiğinizde çözümleme başarılı oluyorsa sorun yerel DNS sunucunuzdadır:

dig google.com @8.8.8.8
dig google.com @1.1.1.1

DNS cache sorunları için:

# systemd-resolved kullanan sistemlerde
systemd-resolve --flush-caches
resolvectl flush-caches

Gerçek Dünya Senaryosu: Kısmi DNS Arızası

Bir müşteri ortamında sadece belirli domainlerin çözümlenmediği, diğerlerinin normal çalıştığı bir durum yaşadık. Sorunun kaynağı DNS sunucusundaki yanlış zone konfigürasyonuydu. Belirli bir domain grubunun recursive sorgusu bloklanmıştı. dig +trace google.com komutu DNS çözümleme zincirini adım adım göstererek sorunun tam olarak nerede koptuğunu tespit etmemizi sağladı:

dig +trace problematic-domain.com

Traceroute ile Paket Yolunu İzlemek

Ping başarısız olduğunda veya yüksek gecikme yaşandığında, paketin nerede takılı kaldığını anlamak için traceroute kullanın.

traceroute 8.8.8.8
traceroute -n 8.8.8.8
mtr --report 8.8.8.8

-n parametresi: DNS çözümlemesi yapmadan sadece IP adresleri gösterir, daha hızlı sonuç verir.

mtr komutu traceroute ve ping’i birleştiren çok daha kapsamlı bir araçtır. Her hop için paket kaybı ve gecikme istatistiklerini gerçek zamanlı gösterir. Production sorunlarında mtr’yi tercih ediyorum çünkü anlık bir snapshot yerine sürekli güncellenen istatistikler sunuyor.

Traceroute çıktısında dikkat edilecekler:

• Yıldız işaretleri (*): O hop’tan yanıt gelmiyor, ICMP bloklanmış olabilir veya gerçek bir sorun var
• Belirli bir hop’tan sonra tüm satırlarda yıldız: Paket o noktada kayboluyor
• Ani RTT artışı: O hop veya sonrasında gecikme sorunu var

Aktif Bağlantılar ve Port Durumu

Bazen sorun bağlantının kendisinde değil, belirli bir servise ulaşamamaktan kaynaklanır. Hangi portların dinlediğini ve mevcut bağlantıları görmek için:

ss -tlnp
ss -tulnp
netstat -tlnp

-t: TCP bağlantıları -u: UDP bağlantıları -l: Sadece dinleyen (listening) soketler -n: Port numaralarını sayısal göster -p: Hangi process kullandığını göster

Bir porta gerçekten ulaşıp ulaşamadığınızı test etmek için:

telnet 192.168.1.10 80
nc -zv 192.168.1.10 80
nc -zv -w 3 192.168.1.10 443

nc (netcat) çok daha güvenilir bir araçtır. -z parametresi sadece port taraması yapar, veri göndermez. -v verbose modunu açar. -w 3 ise 3 saniyelik timeout belirler.

Firewall Kuralları: Gizli Engeller

Bazen ağ konfigürasyonu tamamen doğru olmasına rağmen bağlantı kurulamaz. Firewall kuralları şüpheli birinci sırada yer alır.

Linux’ta iptables kurallarını listeleyin:

iptables -L -n -v
iptables -L INPUT -n -v --line-numbers
ip6tables -L -n -v

Eğer nftables kullanıyorsanız:

nft list ruleset
nft list table inet filter

firewalld kullanan sistemlerde:

firewall-cmd --list-all
firewall-cmd --list-all-zones

Sorun giderme sırasında geçici olarak tüm kuralları devre dışı bırakmak (production dışı ortamda!) sorunu izole etmek için işe yarar:

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F

Bunu yaptıktan sonra bağlantı sağlanıyorsa sorun kesinlikle firewall kurallarındaydı demektir. Sonra kuralları tek tek ekleyerek hangisinin blokladığını bulun.

Gerçek Dünya Senaryosu: Güncelleme Sonrası Bağlantı Kaybı

Bir sistem güncellemesinin ardından belirli sunuculardan dışarıya bağlantı kurulamaz hale geldi. Ping çalışıyor, DNS çalışıyor ama HTTP/HTTPS bağlantıları timeout veriyor. iptables -L -n -v çıktısını incelediğimizde, güncelleme sürecinde yüklenen yeni bir paketin OUTPUT zinciri için kısıtlayıcı kurallar eklediğini gördük. Bu tür durumlar için sistem güncellemelerinden önce ve sonra firewall kurallarının snapshot’ını almak iyi bir pratiktir:

iptables-save > /tmp/iptables-backup-$(date +%Y%m%d).txt

Network Namespace ve Routing Table Kontrolü

Daha karmaşık ortamlarda, özellikle container ve sanal makine altyapılarında, routing tablosundaki tutarsızlıklar bağlantı sorunlarına yol açar.

ip route show table all
ip rule show

Belirli bir hedefe paketin hangi yolu izleyeceğini anlamak için:

ip route get 8.8.8.8
ip route get 10.0.0.5

Bu komut, o hedefe gidecek paketin hangi arayüzü ve hangi gateway’i kullanacağını doğrudan söyler. Çıktı şöyle görünür:

8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 0

Birden fazla NIC olan sunucularda asimetrik routing sorunu sıkça yaşanır. Paket bir arayüzden çıkar, yanıt başka bir arayüze gelir ama sunucu bu yanıtı reddeder. Bu durumu çözmek için policy based routing veya rp_filter ayarını kontrol etmeniz gerekir:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter

Paket Yakalama: Gerçeği Görmek

Tüm bu kontroller sonuç vermediğinde son silah paket analizidir. tcpdump ile trafiği doğrudan yakalayabilirsiniz.

tcpdump -i eth0 -n host 8.8.8.8
tcpdump -i eth0 -n port 443
tcpdump -i any -n -w /tmp/capture.pcap
tcpdump -i eth0 -n 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'

-i eth0: Hangi arayüzü dinleyeceğini belirtir -n: IP adresleri ve port numaralarını sayısal gösterir -w: Yakalananları dosyaya yazar (Wireshark ile açılabilir)

Bir bağlantı sorunu debug ederken özellikle şunlara bakın: SYN paketi gidiyor mu? SYN-ACK yanıtı geliyor mu? Eğer SYN gönderiliyor ama SYN-ACK gelmiyorsa sorun karşı tarafta veya ağın ortasındadır. Eğer SYN-ACK geliyor ama üçlü el sıkışma tamamlanmıyorsa local firewall veya uygulama katmanında bir sorun olabilir.

Aralıklı Bağlantı Sorunları: En Zorlu Durum

Sürekli yaşanan bir bağlantı sorunundan çok daha sinir bozucu olan aralıklı bağlantı sorunlarıdır. Müdahale etmek istediğinizde her şey yolunda görünür. Bu tür sorunlar için log izleme ve periyodik test scriptleri yazmanız gerekir.

#!/bin/bash
TARGET="8.8.8.8"
LOG="/var/log/connectivity_check.log"

while true; do
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
    if ping -c 1 -W 2 $TARGET > /dev/null 2>&1; then
        echo "$TIMESTAMP - OK" >> $LOG
    else
        echo "$TIMESTAMP - FAIL" >> $LOG
        # İsteğe bağlı: mail veya slack notification
    fi
    sleep 30
done

Bu script her 30 saniyede bir bağlantıyı test eder ve sonucu loglar. Aralıklı sorunu yakaladığınızda, o andaki ağ durumunu anlık olarak kaydetmek için daha kapsamlı bir script yazabilirsiniz.

Aralıklı sorunların yaygın nedenleri:

• Spanning tree flap’leri: Switch’ler arasında döngü ve spanning tree yeniden hesaplama
• NIC driver sorunları: Yüksek yük altında NIC’in timeout’a düşmesi
• Yanlış autonegotiation: Bağlantının zaman zaman hızı yeniden müzakere etmesi
• DHCP lease problemleri: Lease süresi dolduğunda IP yenileme sırasındaki kısa kesintiler

Kernel Log ve Sistem Günlükleri

Ağ sorunlarını araştırırken sistem loglarını ihmal etmeyin. Kernel seviyesindeki ağ hataları burada kayıt altına alınır.

dmesg | grep -i "eth|network|link|error" | tail -50
journalctl -u NetworkManager -f
journalctl -k | grep -i "net|eth|link"

Özellikle dmesg çıktısında “link is down”, “NIC reset”, “TX timeout” gibi mesajlar donanım sorununa işaret eder. “neighbour table overflow” mesajı ARP tablosunun dolduğunu, büyük ağlarda performans sorunlarına yol açabileceğini gösterir. Bu durumda ARP table limitlerini artırmanız gerekir:

sysctl net.ipv4.neigh.default.gc_thresh1
sysctl net.ipv4.neigh.default.gc_thresh2
sysctl net.ipv4.neigh.default.gc_thresh3

Sonuç

Ağ sorunlarını çözmek bir dedektiflik çalışmasıdır. Katman katman ilerlemek, rastgele şeyler denemek yerine sistematik bir yaklaşım benimsemek sizi çok daha hızlı sonuca götürür. Fiziksel bağlantıdan başlayın, IP konfigürasyonunu kontrol edin, DNS’i test edin, routing’e bakın ve firewall kurallarını inceleyin. Her adımda edindiğiniz bilgi sizi bir sonraki adıma yönlendirir.

Deneyimlerime göre ağ sorunlarının büyük çoğunluğu birkaç temel kategoride toplanır: yanlış IP/gateway konfigürasyonu, DNS arızaları, firewall kuralı çakışmaları ve fiziksel/donanım sorunları. Bu kategorileri hızlı test edebilecek bir checklist elinizde bulundurmanız, gece yarısı telefon açıldığında hayat kurtarır.

Son olarak, production ortamınızda ağ altyapısını izleyen bir monitoring sisteminin olması şart. Sorun oluştuktan sonra debug etmek yerine sorun oluşmadan önce anomaliyi tespit etmek, hem size hem kullanıcılara çok daha iyi bir deneyim sunar. Zabbix, Prometheus+Grafana veya basit bir Nagios kurulumu bu konuda işinizi ciddi ölçüde kolaylaştıracaktır.