Default Route Olmadan Sunucu Neden Kendi Ağı Dışına Çıkamaz?

Ağ sorunlarının en yanıltıcı olanlarından biri yarım çalışan bağlantıdır. Sunucu komşu cihazı görür, yönetim arayüzüne aynı VLAN içinden erişilir ve servis ayakta görünür; fakat farklı bir lokasyondaki uygulamaya veya internete paket gidemez. Bu tabloda kabloyu, sürücüyü ya da güvenlik duvarını ilk şüpheli ilan etmek kolaydır. Gerçekte kernel, kendi bağlı ağı dışında kalan hedef için bir sonraki durağı bilmiyor olabilir.

20 Temmuz 2026 tarihinde ele aldığımız vakada teknik ayrıntı küçük, etkisi genişti: routing tablosunda varsayılan rota yoktu. Olay, default route kavramını yalnızca bir komut çıktısı olarak değil, ağ tasarımındaki karar mekanizması olarak anlatmak için iyi bir örnek oldu. Bir paketin hedefi önce en özel rota ile eşleştirilir; hiçbir özel kayıt bulunamazsa varsayılan rota devreye girer. O kayıt da yoksa sistem tahminde bulunmaz, paketi göndermez.

Sorunun ortaya çıkışı

Yeni devreye alınan bir Linux sunucu aynı subnet içindeki izleme ve yönetim sistemleriyle konuşabiliyordu. Başka bir VLAN üzerindeki kimlik servisine ve dış güncelleme kaynaklarına erişim ise başarısızdı. IP adresi doğru göründüğü için uygulama ekibi sorunu hedef servislerde aramaya başladı. Ağ ekibi de yerel ping sonuçlarını bağlantının sağlıklı olduğuna dair kanıt olarak yorumladı.

İki bulgu aslında çelişmiyordu. Aynı prefix içindeki hedefler için sunucu ARP veya komşuluk keşfi yaparak doğrudan iletişim kurar; yönlendiriciye ihtiyaç duymaz. Hedef bağlı ağın dışına çıktığında ise paket bir next hop adresine teslim edilmelidir. Route tablosunda buna uygun özel ya da varsayılan kayıt bulunmadığı için dış iletişim başlamadan yerel sistemde sona eriyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım “ping çalışıyor, ağ sağlam” cümlesiydi. Ping sonucunun değeri hedefin nerede olduğuna bağlıdır; yalnızca komşu sunucuya ulaşmak yönlendirmeyi sınamaz. İkinci varsayım, DNS hatasının ayrı bir servis problemi olduğuydu. DNS sunucusu farklı bir subnet içindeyse ona giden sorgu da aynı eksik rota nedeniyle çıkamaz. Uygulama hataları bu nedenle birbirinden bağımsız görünse de ortak köke sahipti.

Bir başka karışıklık, gateway adresinin arayüz yapılandırmasında yazılı olmasının kernel tablosunda etkin rota bulunduğu anlamına geldiğiydi. Yapılandırma dosyası hatalı girintilenmiş, yanlış renderer tarafından yönetilmiş veya uygulanmamış olabilir. Bu yüzden beklenen ayarı okumakla yetinmeyip çalışan sistemin ip route çıktısını ve belirli hedef için seçtiği yolu görmemiz gerekiyordu.

Teknik analiz

Linux yönlendirme kararı en uzun prefix eşleşmesine dayanır. Örneğin bağlı ağ rotası, o ağdaki hedefler için varsayılan rotadan daha özeldir. Uzak bir iş ağına tanımlı statik rota varsa o rota seçilir; hiçbir özel eşleşme yoksa 0.0.0.0/0 kaydı kullanılır. Birden çok default route bulunduğunda metric, policy routing ve kaynak adres kuralları ayrıca değerlendirilmelidir.

İncelemede ip route show table main ile ana tabloyu, ip rule ile ek politika tablolarını ve ip route get ile kernelin gerçek kararını kontrol ettik. Gateway aynı L2 ağında mı, arayüz up mı ve komşuluk kaydı oluşuyor mu sorularını ayrı test ettik. Traceroute çıktısını tek başına hüküm vermek için kullanmadık; ara cihazlar tanılama paketlerine yanıt vermeyebilir.

# Güvenli yönlendirme gözlemi
ip -br address
ip route show table main
ip rule show
ip route get 198.51.100.20
ip neigh show

Uygulanan çözüm veya önerilen mimari

Onaylı ağ tasarımındaki gateway adresi ile sunucunun prefix bilgisi karşılaştırıldı. Geçici rota bakım oturumunda eklenip farklı ağlardaki izinli test uçlarına erişim gözlendi. Sonuç olumlu olunca kalıcı ağ tanımına varsayılan rota eklendi ve konfigürasyon doğrulama aracı çalıştırıldı. Uygulama öncesinde mevcut dosya ile konsol erişimi hazır tutuldu; işlem sonrasında servis bağımlılıkları uçtan uca sınandı.

Önerilen mimaride sunucular için tek bir default gateway, yalnızca gerçekten gereken özel ağlar için açıklamalı statik rotalar bulunuyor. Birden fazla uplink varsa gelişigüzel iki default route yerine metric veya policy routing tasarımı yapılıyor. Ağ envanteri hangi subnetin hangi yönlendirici üzerinden erişildiğini belgelediği için sunucu ayarı ile güvenlik duvarı rotası birlikte değişiklik kaydına bağlanıyor.

Alternatifler ve karar gerekçesi

Her uzak subnet için statik rota yazmak teknik olarak mümkündü. Ancak büyüyen çok lokasyonlu yapıda bu yöntem sunucu başına farklılık, unutulan ağlar ve bakım yükü yaratacaktı. Default route ile kurumun yönlendirme katmanına teslim etmek daha sade ve merkeziydi. Yalnızca yönetim ağı gibi farklı güvenlik yoluna ihtiyaç duyan istisnalar özel rota olarak bırakıldı.

Dinamik routing protokolünü doğrudan uygulama sunucularında çalıştırmak da değerlendirilebilir, fakat bu vaka için gereksiz karmaşıklık ve geniş hata alanı oluşturuyordu. DHCP üzerinden rota dağıtımı standardın uygun olduğu istemci ağlarında yararlıdır; sabit servis sunucularında değişiklik kontrolü ve öngörülebilirlik daha ağır bastı. Karar, en fazla özelliği değil en az sürprizi üreten tasarıma göre verildi.

Güvenlik ve operasyonel riskler

Default route eklemek erişimi düzeltirken sunucunun daha geniş bir ağa paket gönderebilmesini de sağlar. Bu, host firewall ve ağ segmentasyonu ihtiyacını ortadan kaldırmaz. Yanlış veya güvenilmeyen gateway trafiği gözlemleyebilir ya da kara deliğe düşürebilir. Gateway değeri doğrulanmalı, egress politikaları en az yetkiyle tutulmalı ve yalnızca gerekli servis hedeflerine izin verilmelidir.

İki varsayılan rotanın kontrolsüz varlığı asimetrik trafik, oturum kopması ve zor teşhis edilen aralıklı hatalar doğurabilir. Sanal platform taşıması veya arayüz adı değişikliği de kalıcı tanımı geçersiz bırakabilir. Bu yüzden açılış sonrası route uygunluğu izlenmeli, konfigürasyon sapması raporlanmalı ve ağ değişikliği uygulama sahiplerinin fonksiyon testini de içermelidir.

Çıkarılan Dersler

Kontrol Listesi