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