Hafta içi sabahı, prod benzeri ortamımızda birkaç mikroservis aniden birbirine ulaşamaz hale geldi. Uygulama katmanından gelen 500 hataları, iş monitörlerinin kırılması ve CI job’larının başarısız olmasıyla uykusuz bir iki saat başladı. Aşağıda olayı nasıl gördüğümü, adım adım nasıl teşhis ettiğimi ve nihai çözümü nasıl uyguladığımı yazıyorum — isimleri maskelenmiş, ancak gerçekçi teknik detaylarla.
Sorunun Ortaya Çıkışı
Belirtiler şöyleydi: bazı istemciler bir iç servise sorunsuz bağlanırken, diğerleri aynı anda eski bir IP’ye veya hatalı gateway’e yönlendiriliyordu. Uygulama logları “connection refused” veya “dial tcp X:X: connect: no route to host” türündeydi. İlginç olan, sorun herkeste değildi; aynı VLAN’daki makinelerin bazıları doğru, bazıları yanlış DNS cevabı alıyordu.
Tespit – 1: Log ve hızlı doğrulama
İlk işim uygulama ve host loglarına bakmak oldu. Hızlı komutlar:
journalctl -u my-service -n 200
docker logs --tail 200 my-app
Ardından ilgili sunucudan DNS sorguları gönderip cevabı kontrol ettim:
dig +short svc.internal.example.com @192.0.2.53
getent hosts svc.internal.example.com
Bazı makineler doğru (192.168.x.y), bazıları ise eski/yanlış IP (10.10.x.z) döndürüyordu. Bu split‑horizon (aynı isim için farklı cevaplar) benzeri bir durumdu ama bizim beklentimiz tekil iç DNS idi.
Tespit – 2: DNS cache ve resolver farklarını kontrol etmek
Hangi resolver’ın kullanıldığını görmek için /etc/resolv.conf, systemd-resolved ve uygulama düzeyindeki DNS ayarlarına baktım:
cat /etc/resolv.conf
systemd-resolve --status
sssd -i (varsa)
Bazı makinelerde syslog’ta resolver değişiklikleriyle ilgili kayıtlar vardı. Fakat en somut kanıtı ağ trafiği verdi: DHCP üzerinden hangi DNS sunucusunun dağıtıldığını görmek için DHCP paketlerini incelemeye başladım.
Tespit – 3: Ağ trafiğini dinlemek — Rogue DHCP’yi yakalamak
DHCP Offer paketleri içinde Option 6 (DNS servers) değerini görecek şekilde tcpdump aldım:
sudo tcpdump -n -i eth0 'udp and (port 67 or port 68)' -vv
Yayın trafiği içinde kimlik bilgilerini (server identifier) ve verilen DNS IP’lerini gördüm. Beklediğimiz DHCP sunucusundan gelen Offer’lar olduğu gibi, beklemediğimiz başka bir teklif de vardı — farklı bir IP ve içerisinde eski/yanlış DNS adresleri vardı.
Bu, sorunlu makinelerin hatalı DHCP Offer’ı kabul edip yanlış DNS adresi ile konfigüre olduğunu; dolayısıyla bazı istemcilerin farklı DNS server’a (eski split‑horizon kayıtları olan bir DNS) yönlendirildiğini gösteriyordu.
Tespit – 4: Rogue cihazın yeri ve türü
DHCP Offer paketlerindeki MAC ve switch port bilgilerini eşleştirmek için switch üzerinde DHCP snooping/kaydı kontrol ettim. Eğer switch’te bu özellik yoksa, DHCP Offer gönderen cihazı izole etmek için ARP sorguları ve fiziksel lokasyon takibi yaptım. Komut örneği (Cisco benzeri cihazlarda):
show ip dhcp snooping binding | include 00:11:22:33:44:55
show mac address-table address 00:11:22:33:44:55
Sonunda rogue DHCP’yi, yanlışlıkla yönetim VLAN’ına bağlanmış bir test VMware host’unun içinde çalışan eski bir DHCP sunucusu olduğunu buldum. Sahibi sabah erken bir test yapmış, servis otomatik başlayacak şekilde bırakılmıştı.
Çözüm
Yaptığım müdahaleler:
- Rogue DHCP servisini kapattım ve host’un ağ bağdaştırıcısını izoladım:
ssh [email protected]
sudo systemctl stop isc-dhcp-server
sudo systemctl disable isc-dhcp-server
sudo dhclient -r && sudo dhclient
# Windows için: ipconfig /release && ipconfig /renew
sudo systemd-resolve --flush-caches
sudo systemctl restart my-service
Tüm servisler 15–30 dakika içinde normale döndü; CI pipeline’lar yeşile geçti, monitörler sessizleşti.
Alınan Dersler
Bu vaka bana birkaç pratik ders hatırlattı: ağlarda tek bir yanlış test sunucusu bile beklenmedik etkilere yol açabilir. Bundan sonra yaptığım ve herkese önereceğim adımlar:
- DHCP snooping ve port security’yi etkinleştirmek; yetkisiz DHCP Offer’larını filtrelemek.
- Test/deneme host’larını izole bir VLAN’a konumlandırmak; otomatik servis başlatmayı engellemek.
- DNS ve DHCP değişikliklerini algılayacak hafif monitorler koymak — örneğin iç servisler için periyodik
digkarşılaştırması ve anormallik alarmı. - Servis bağımlılık testlerini CI’ye eklemek: deploy sonrası basit DNS + connectivity kontrolleri fail fast yapsın.
- İyi bir iletişim prosedürü: ağ ekipleri, test ekipleri ve sistem operatörleri arasında değişiklik bildirimi zorunlu olsun.
Küçük bir not: bu tip sorunlar genelde yüksek drama üretir ama kök nedeni çoğunlukla basit bir insan hatası veya yanlış konfigürasyondur. O yüzden ilk panik dalgasından sonra sakin kalıp paketlere, offer’lara ve fiziksel lokasyona bakmak çoğu zaman işi bitirir. Bugün de öyle oldu — 2 saatlik koşturma, birkaç tcpdump ve bir kapatma ile ortamı düzene soktum. Sabah kahvemi hak ettim.