Ubuntu Sunucuda İnternet Var Gibi Görünüp DNS Çalışmadığında Nereden Başlanır?

Bir Ubuntu sunucuda paket güncellemesi durduğunda ilk refleks çoğu zaman DNS sunucusunu değiştirmektir. Oysa isim çözümleme hatası, ağ zincirindeki daha temel bir kopukluğun görünen son belirtisi olabilir. Bu vakada sunucu arayüzünde geçerli görünen bir IP adresi vardı; buna rağmen hem alan adları hem de dış IP hedefleri erişilemiyordu. Dolayısıyla sorun DNS ile başlamıyor, DNS aşamasına hiç ulaşılamadığı için orada görünüyordu.

Bu çalışma ilk olarak 20 Temmuz 2026 tarihinde, çok lokasyonlu bir kurumun bakım penceresinde ele alındı. İncelemeyi uygulama, resolver ve ağ ayarları arasında rastgele geçiş yaparak değil; yerel arayüzden varsayılan rotaya, ağ geçidinden dış erişime ve en son isim çözümlemeye ilerleyen bir sıra ile yürüttük. Bu yaklaşım hem çözüm süresini kısalttı hem de geçici bir komutla kalıcı yapılandırma arasındaki farkı görünür kıldı.

Sorunun ortaya çıkışı

Bakım sırasında çalışan ekip, apt depolarına ulaşılamadığını ve uygulamanın dış servis adlarını çözemediğini bildirdi. Arayüz aktif, statik IP tanımlı ve aynı ağdaki bazı sistemlerle iletişim mümkündü. Bu görüntü, sunucunun internete bağlı olduğu izlenimini veriyordu. Fakat bağlantı yalnızca yerel yayın alanı içinde çalışıyordu; başka ağlara gidecek paketin hangi yönlendiriciye teslim edileceği tanımlı değildi.

İlk hedefimiz değişiklik yapmak değil, kesintinin sınırını belirlemekti. Arayüz durumu, adres/prefix ilişkisi, route tablosu ve resolver bilgisi ayrı ayrı kaydedildi. Böylece olay kaydına yalnızca “DNS çalışmıyor” yazmak yerine, yerel erişimin var fakat yönlendirilmiş erişimin yok olduğunu gösteren tekrar üretilebilir bir başlangıç durumu ekledik.

İlk belirtiler ve yanlış varsayımlar

En yaygın yanlış varsayım, resolv.conf içinde bir nameserver görülmesinin DNS yolunun çalıştığını kanıtladığıdır. Bu satır yalnızca sorgunun nereye gönderileceğini söyler; hedefe rota bulunduğunu, aradaki güvenlik politikasının izin verdiğini veya yanıtın dönebildiğini kanıtlamaz. İkinci yanılgı da arayüzde IP bulunmasını tam bağlantı kabul etmektir. IP, sadece bağlı subnet için doğrudan iletişim sağlar.

Ekip önce genel DNS hizmetlerini sırayla denemeyi önermişti. Dış bir dokümantasyon IP adresine yapılan ICMP ve TCP temelli kontrollü testler de başarısız olunca resolver değiştirmenin anlamı kalmadı. Ayrıca ağ geçidi adresine dahi erişilemiyorsa üst ağ veya internet üzerinde çalışmak yerine yerel VLAN, prefix, sanal anahtar ve gateway tanımına dönmek gerektiğini netleştirdik.

Teknik analiz

Analiz sırası bilinçliydi: önce ip link ile fiziksel/mantıksal durum, sonra ip address ile adres ve prefix, ardından ip route ile kernel yönlendirme tablosu kontrol edildi. Yerel ağ rotası vardı ancak “default via” kaydı yoktu. ip route get komutu da dış hedef için yol üretemiyordu. Bu bulgu, DNS paketleri dahil bağlı subnet dışına giden tüm trafiğin neden başarısız olduğunu tek başına açıklıyordu.

Geçici rota eklemeden önce ağ geçidinin gerçekten aynı subnet içinde olduğuna ve başka bir arayüzden erişilmediğine baktık. systemd-resolved kullanılıyorsa resolvectl status çıktısındaki arayüz bazlı DNS ve search domain değerlerini de kaydettik. Paket kaybını DNS ile karıştırmamak için isim çözümleme testi ancak gateway ve dış IP testi başarılı olduktan sonra yapıldı.

# Yalnızca gözlem amaçlı, değişiklik yapmaz
ip -br link
ip -br address
ip route show
ip route get 192.0.2.10
resolvectl status
resolvectl query example.invalid

Uygulanan çözüm veya önerilen mimari

Doğru ağ geçidi, kurumun onaylı IP planından doğrulandı ve önce bakım penceresinde geçici rota ile test edildi. Yerel gateway, dış test hedefi ve DNS sorgusu sırasıyla başarılı olduktan sonra ayar Netplan dosyasına işlendi. Dosyanın mevcut renderer yaklaşımı korundu; arayüz adı tahmin edilmedi ve YAML girintisi ayrı bir göz tarafından kontrol edildi. Netplan try kullanılarak süreli geri dönüş imkanı bırakıldı.

Kalıcı tasarımda adres, prefix, varsayılan rota ve kurum içi resolver değerleri tek bir yönetilen yapılandırmada tutuldu. Yapılandırma yönetimi kaydı ile sunucu üzerindeki gerçek durum eşleştirildi. Yeniden başlatma sonrasında aynı test dizisi tekrarlandı; böylece yalnızca çalışan kernel rotasına değil, açılıştan sonra yeniden üretilebilen yapılandırmaya sahip olduğumuz kanıtlandı.

Alternatifler ve karar gerekçesi

DHCP kullanmak, küçük veya geçici sistemlerde gateway ve DNS dağıtımını kolaylaştırabilirdi. Ancak bu sunucunun servis bağımlılıkları sabit adres ve kontrollü değişiklik gerektiriyordu. NetworkManager veya systemd-networkd doğrudan yapılandırılabilirdi; Ubuntu sunucu standardımız Netplan üzerinden renderer yönetmek olduğu için alttaki servise müdahale etmedik. Bu karar araç tercihi değil, işletim tutarlılığı kararıydı.

Yalnızca ip route add ile rota eklemek hızlı bir geçici çözüm olurdu fakat yeniden başlatmada kaybolurdu. Resolver adresini değiştirmek ise temel rotayı onarmadığı için sahte ilerleme yaratacaktı. Seçilen yöntem önce hipotezi geçici ve geri alınabilir biçimde doğruladı, sonra kaynağı kalıcı olarak düzeltti. Acil müdahale ile konfigürasyon yönetimini birbirinden ayırmamak operasyonel borcu azalttı.

Güvenlik ve operasyonel riskler

Yanlış gateway tanımı trafiği yetkisiz bir cihaza yönlendirebilir; yanlış DNS ise isim çözümleme bütünlüğünü bozabilir. Bu nedenle adresler sohbet mesajından veya eski ekrandan kopyalanmadı, onaylı ağ envanterinden alındı. Uzak bağlantı üzerinden Netplan uygulamak oturumu kesebileceği için konsol erişimi ve otomatik geri dönüş süresi hazır tutuldu. Dosya izinleri ile değişiklik geçmişi de kontrol edildi.

Operasyon tarafında en büyük risk, semptom düzelince kök neden kaydını kapatmaktır. İzleme sistemine gateway erişimi, resolver yanıt süresi ve dış bağımlılık kontrolü ayrı sinyaller olarak eklendi. Böylece bir sonraki olayda “internet yok” alarmı yerine hangi katmanın bozulduğu görülebilecek. Test hedefleri de üçüncü taraf gerçek sistemler yerine kurumun izinli uçları ve dokümantasyon adresleriyle sınırlandı.

Çıkarılan Dersler

Kontrol Listesi

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