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

Exit node olarak ilan edilen bir sunucunun yönetim panelinde yeşil görünmesi yanıltıcı bir başarı ölçütüdür. Bu durum sunucunun Tailscale kontrol düzlemine kayıtlı ve rotayı duyurmuş olduğunu gösterebilir; istemciden gelen paketi çekirdek içinde bir arayüzden diğerine aktarabildiğini veya dış ağın yanıtı geri döndürebildiğini göstermez. Veri düzlemindeki her halka ayrıca doğrulanmalıdır.

17 Temmuz 2026 tarihinde bir Ubuntu sunucuda tam olarak bu ayrımı yaşadık. İstemci exit node’u seçiyor, overlay üzerinden sunucuya erişiyor fakat internet trafiği ilerlemiyordu. Sorunu tek bir NAT komutuyla kapatmak yerine IP forwarding, nftables forward zinciri, kaynak adres çevirisi, varsayılan rota, ters yol filtresi ve Tailscale’in kendi netfilter yönetimini beraber inceledik. Kalıcı çözüm, hangi katmanın kime ait olduğunu belgelemekten geçti.

Sorunun ortaya çıkışı

Ubuntu cihaz exit node olarak duyurulmuş ve yönetici tarafından onaylanmıştı. İstemci bu düğümü seçtiğinde sunucunun Tailscale adresine erişebiliyor, fakat dış web ve DNS bağlantıları zaman aşımına uğruyordu. Exit node seçimi kaldırıldığında istemci kendi internet bağlantısını sorunsuz kullanıyordu. Bu karşılaştırma istemci uygulamasından çok, exit node üzerindeki ileri yönlendirme yolunu işaret etti.

Sunucunun kendisi internete çıkabiliyordu; bu da başka bir yanlış güven oluşturdu. Yerel süreçten çıkan paket OUTPUT yolunu, istemciden gelip aktarılacak paket ise FORWARD yolunu kullanır. İkincisi kernel yönlendirme izni, iki arayüz arasında firewall geçişi ve çoğu ağda kaynak NAT gerektirir. Sunucunun kendi bağlantısı bu koşulların hiçbirini tek başına sınamaz.

İlk belirtiler ve yanlış varsayımlar

İlk varsayım Tailscale’in her Linux dağıtımında tüm forwarding ve NAT ayrıntılarını otomatik yöneteceğiydi. Ürünün sürümü, netfilter modu, mevcut firewall yöneticisi ve kurumun elle yazılmış kuralları davranışı değiştirebilir. İkinci varsayım `net.ipv4.ip_forward=1` değerinin yeterli olduğuydu. Kernel aktarımı kabul etse bile forward zinciri paketi düşürebilir veya dönüş ağı overlay adresini tanımayabilir.

Sorunu çözmek için firewall’ı tamamen temizlemek önerildi; bu yöntem hem uzaktan erişimi kesebilir hem de sunucuyu korumasız bırakır. rp_filter değerini global olarak kapatmak da hızlı ama ölçüsüz bir müdahaledir. Önce paket sayacı, route kararı ve günlüklerle hangi aşamada kayıp olduğunu belirledik. Yalnızca ilgili arayüz ve akış için gerekçe oluşursa ayar değiştirilmeliydi.

Teknik analiz

sysctl üzerinden IPv4 ve gerekiyorsa IPv6 forwarding çalışma zamanı değerleri okundu. ip route get ile exit node’un dış hedefe hangi fiziksel arayüz ve kaynak adresle çıkacağı doğrulandı. nft list ruleset çıktısında Tailscale tarafından yönetilen zincirler ile kurum kuralları ayrıştırıldı; forward kabulü ve postrouting masquerade sayaçları test sırasında gözlendi. Gerçek kullanıcı trafiği yerine kontrollü dokümantasyon hedefi kullanıldı.

Paket yakalama gerektiğinde yalnızca bakım penceresinde, dar host ve protokol filtresiyle iki arayüzde başlık seviyesinde gözlem yapıldı; içerik toplanmadı. Tailscale arayüzüne gelen fakat fiziksel arayüzden çıkmayan paket forward politikasını, çıkıp yanıtsız kalan paket NAT veya üst ağ yolunu düşündürür. Yanıt fiziksel arayüze geliyor ama overlay’e dönemiyorsa conntrack, rp_filter ve dönüş kuralları incelenir.

# Salt okunur exit node tanısı
sysctl net.ipv4.ip_forward
ip route get 203.0.113.30
sudo nft list ruleset
tailscale status
tailscale netcheck

Uygulanan çözüm veya önerilen mimari

Forwarding kalıcı sysctl yapılandırmasında etkinleştirildi ve yeniden yükleme sonrası doğrulandı. nftables içinde yalnızca Tailscale arayüzünden gelen, yerleşik bağlantı durumunu izleyen ve onaylı dış arayüze giden trafik için forward politikası tanımlandı. Overlay kaynakları fiziksel ağda yönlendirilmediğinden çıkışta masquerade uygulandı. Tailscale’in yönettiği zincirlerle çakışmamak için kural sahipliği açıkça belgelendi.

İstemci exit node seçimi ACL ve yönetim onayına bağlandı; herkesin keyfi çıkış düğümü kullanmasına izin verilmedi. DNS davranışı ayrıca test edildi çünkü çıkış çalışırken split DNS politikası farklı sonuç üretebilir. Sunucu yeniden başlatıldıktan sonra forwarding, NAT sayaçları ve istemci dış adres doğrulaması tekrarlandı. İzleme sistemine servis durumu yanında veri düzlemi sentetik testi eklendi.

Alternatifler ve karar gerekçesi

Üst yönlendiriciye Tailscale adres aralığı için dönüş rotası eklemek, NAT ihtiyacını kaldırabilir ve kaynak görünürlüğünü korur. Ancak mevcut ağda bu rota tüm dönüş yoluna güvenli biçimde dağıtılamıyordu; sınırlı exit node kapsamı için masquerade daha uygulanabilirdi. Kaynak izlenebilirliğinin kritik olduğu büyük yapılarda yönlendirilmiş model yeniden değerlendirilmelidir.

Sunucuyu tam bir ağ geçidi dağıtımıyla değiştirmek daha güçlü yüksek erişilebilirlik ve politika özellikleri sağlayabilir. Bu vakada az sayıda yetkili kullanıcı ve kontrollü kullanım için mevcut Ubuntu düğümü yeterliydi. iptables ile kural yazmak mümkün olsa da platform standardı nftables idi. İki araç katmanını karıştırmak yerine tek yönetim kaynağı seçerek yeniden başlatma sonrası öngörülebilirliği artırdık.

Güvenlik ve operasyonel riskler

Exit node kullanıcının tüm internet trafiği için güven sınırı haline gelir. Düğüm yöneticisi, DNS ve bağlantı metadatası bakımından hassas bir konumdadır; günlük saklama, yetkili erişim ve gizlilik beklentileri yazılı olmalıdır. Geniş forward kuralı sunucuyu iki ağ arasında istenmeyen router’a çevirebilir. Yönetim servisleri ile transit trafik aynı politika içinde bırakılmamalıdır.

Tek exit node bakım veya bağlantı kesintisinde kullanıcıları internetsiz bırakabilir. Kapasite, CPU, bağlantı tablosu ve uplink kullanımı izlenmeli; otomatik seçim varsa beklenen coğrafi ve yasal çıkış noktası doğrulanmalıdır. Firewall aracı güncellendiğinde Tailscale kurallarıyla sıra değişebilir. Her sürüm ve kural değişikliğinden sonra hem izinli akış hem de engellenmesi gereken erişim test edilmelidir.

Çıkarılan Dersler

Kontrol Listesi