WordPress Kurulumunda MySQL Kullanıcısı ve Veritabanı Yetkileri

Yeni bir WordPress kurulumunda veritabanı bağlantısını hızla doğrulamak için yönetici hesabını kullanmak cazip gelebilir. Bir kurulumda bu geçici tercih kalıcı hale gelmiş, uygulama yapılandırmasında gereğinden geniş yetkili bir hesap bırakılmıştı. Site çalışıyordu; fakat uygulama ele geçirilirse aynı sunucudaki diğer veritabanları ve yönetim işlemleri de gereksiz biçimde risk altındaydı.

21-23 Temmuz 2026 arasında ele alınan çözümde WordPress’e özel veritabanı ve servis kimliği oluşturduk. Buradaki komutlar örnek adlar kullanır; gerçek parola, sunucu adresi veya topoloji içermez. Hedef yalnızca bağlantıyı çalıştırmak değil, hesabın nereden bağlanabileceğini ve hangi nesnede hangi işi yapabileceğini anlaşılır biçimde sınırlandırmaktır.

Sorunun ortaya çıkışı

WordPress kurulum ekranı veritabanına bağlanamıyor ve ekip farklı kullanıcılarla tekrar deniyordu. Root hesabıyla bağlantı sağlanınca sorun çözülmüş sayıldı. Oysa hata uygulama kullanıcısının yanlış host tanımı, eksik grant veya farklı kimlik doğrulama yöntemi olabilirdi. Geniş yetki kullanmak kök nedeni gizledi ve güvenlik borcu yarattı. Önce bağlantı kimliğinin tam olarak nasıl eşleştiğini anlamak gerekiyordu.

MySQL kullanıcıları yalnızca kullanıcı adından değil kullanıcı ve host birleşiminden oluşur. Aynı makinedeki `localhost`, bir konteyner ağı veya uzak uygulama sunucusu farklı hesap eşleşmeleri yaratabilir. Her yerden bağlantıya izin veren geniş host tanımı kolaylık sağlar; fakat ağ ve kimlik kısıtlarını zayıflatır. Uygulamanın gerçek çalışma konumuna uygun en dar kaynak seçilmeliydi.

İlk belirtiler ve yanlış varsayımlar

“Access denied” mesajı çoğu zaman yalnızca yanlış parola olarak yorumlanır. Gerçekte kullanıcı-host eşleşmesi, grant, parola eklentisi veya bağlantı soketi farklı olabilir. Diğer belirti komut satırından bağlantı başarılıyken WordPress’in başarısız olmasıydı. Test farklı işletim sistemi kullanıcısı, farklı host adı veya TCP yerine yerel soket kullanıyorsa uygulamanın yolunu temsil etmeyebilir.

Bir başka yanlış varsayım `GRANT ALL` ifadesinin sunucu genelinde verilmesi gerektiğiydi. WordPress kendi veritabanında kurulum ve güncelleme sırasında tablo yönetimi yapar; bunun için tüm MySQL sunucusunda yönetici olmasına gerek yoktur. Yetki kapsamı `uygulama_veritabani.*` ile sınırlandırılabilir. Üretim politikası daha sıkıysa eklenti ve çekirdek güncelleme yöntemi ayrıca planlanmalıdır.

Teknik analiz

Önce veritabanı adı, karakter seti ve collation seçimi doğrulandı. Ardından uygulamanın MySQL’e hangi host üzerinden bağlandığı belirlendi. Hesap yalnızca bu kaynaktan erişecek biçimde oluşturuldu ve yetkiler ilgili veritabanıyla sınırlandı. `SHOW GRANTS` çıktısı beklenen kapsamı doğrulamak için kullanıldı. Bağlantı testi WordPress servisinin kullandığı ağ yolu ve kimlikle yapıldı.

Hata incelemesinde uygulama logları geçici ve kontrollü biçimde etkinleştirildi; üretimde kullanıcıya ayrıntılı veritabanı hatası gösterilmedi. DNS, TCP bağlantısı, TLS gereksinimi, kullanıcı-host eşleşmesi ve veritabanı seçimi sırayla kontrol edildi. Başarılı testten sonra root kimliği yapılandırmadan çıkarıldı. Kullanılmayan deneme hesapları ve geniş grant’ler envanterden temizlendi.

-- Örnek adları ve güçlü parolayı kurumun secret süreciyle değiştirin.
CREATE DATABASE wp_app
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER 'wp_service'@'localhost'
  IDENTIFIED BY '<secret-manager-tarafindan-uretilen-parola>';

GRANT ALL PRIVILEGES ON wp_app.* TO 'wp_service'@'localhost';
SHOW GRANTS FOR 'wp_service'@'localhost';

-- FLUSH PRIVILEGES, CREATE USER ve GRANT ile yapılan modern değişikliklerde gerekmez.

Uygulanan çözüm veya önerilen mimari

Her WordPress örneği için ayrı veritabanı ve ayrı servis hesabı oluşturuldu. Hesap sunucu yönetimi, başka veritabanlarına erişim veya kullanıcı oluşturma yetkisi almadı. Uygulama ile veritabanı farklı sistemlerdeyse ağ güvenlik duvarı yalnızca gerekli kaynaktan veritabanı hizmetine erişime izin verdi. Veritabanı yönetim hesabı WordPress yapılandırmasında veya otomatik dağıtım çıktısında tutulmadı.

`wp-config.php` değerleri en dar dosya izinleriyle korundu ve dağıtım sürecinde gerçek sırların kaynak kod deposuna girmemesi sağlandı. Parola üretimi, dağıtımı, rotasyonu ve acil iptali için sahip belirlendi. Rotasyon çift hesap veya kontrollü bakım penceresiyle test edildi. Yedeklerin yapılandırma ve veritabanı sırlarını içerebileceği kabul edilerek aynı erişim standardı yedek ortamına uygulandı.

Alternatifler ve karar gerekçesi

Yerel MySQL aynı sunucuda basit işletim ve düşük ağ bağımlılığı sağlar; web sunucusu olayı veritabanı hizmetini de etkileyebilir. Ayrı veya yönetilen veritabanı yedekleme, ölçek ve görev ayrımı sunabilir; ağ, TLS, maliyet ve sağlayıcı işletimi getirir. Seçim site kritikliğine ve ekip kapasitesine bağlıdır. Her iki modelde de uygulamaya özel kimlik değişmeyen ilkedir.

WordPress’in çalışma zamanında daha dar SQL yetkileriyle işletilmesi teorik olarak saldırı yüzeyini azaltabilir. Ancak çekirdek ve eklenti güncellemeleri şema değişikliği gerektirdiğinde operasyon karmaşıklaşır. Kontrollü dağıtım hattı olan kurumlar kurulum ve runtime rollerini ayırabilir; küçük yapılarda ilgili tek veritabanıyla sınırlı yetki, güçlü dosya ve güncelleme kontrolleriyle daha sürdürülebilir olabilir.

Güvenlik ve operasyonel riskler

Parolanın terminal geçmişine, ticket’a, sohbet mesajına veya kaynak depoya yazılması en yaygın risklerdendir. Örnek komut gerçek sırla doğrudan ortak oturumda çalıştırılmamalı; kurumun güvenli secret yöntemi kullanılmalıdır. Hata ayıklama çıktıları bağlantı ayrıntısı gösterebilir ve iş bitince kapatılmalıdır. Veritabanı hizmeti gereksiz yere genel ağa açılmamalıdır.

Aşırı dar yetki güncelleme sırasında kesinti, aşırı geniş yetki ise olay etkisinin büyümesine yol açar. Değişiklikler test ortamında WordPress kurulum, eklenti güncelleme, medya kullanımı ve geri yükleme senaryolarıyla doğrulanmalıdır. Kullanılmayan hesaplar kapatılmalı, başarısız oturumlar izlenmeli ve yedekten dönüş düzenli denenmelidir. Hesap silmeden önce uygulama bağımlılığı envanterden kontrol edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Bir üretim tesisinin teknik ekibinden gelen talep oldukça net görünüyordu: modelleme iş istasyonu yavaşlıyor, Görev Yöneticisi belleği yüzde yüze yakın gösteriyor ve kullanıcı 64 GB istiyordu. Böyle durumlarda donanım siparişini onaylamak kolaydır. Zor olan, yatırımın gerçekten bekleme süresini azaltacağını kanıtlamaktır. Çünkü aynı belirti; yetersiz RAM, kötü yönetilen pagefile, yoğun disk erişimi, tek çekirdeğe sıkışan hesaplama veya uygulama içindeki büyük bir proje yapısından kaynaklanabilir.

Datamine ve Micromine sınıfındaki mühendislik uygulamalarında dosya boyutu ile çalışma belleği arasında doğrusal bir ilişki beklemek yanıltıcıdır. Katmanlar, yüzeyler, geçici hesaplar ve geri alma verileri bellekte farklı davranır. Bu nedenle kullanıcı deneyimini küçümsemeden, çözümü önceden seçmeden ilerledik. Amacımız “RAM gerekmez” demek değil; 64 GB yatırımının hangi koşulda fayda sağlayacağını ve başka hangi darboğazların kalacağını görünür kılmaktı.

Sorunun ortaya çıkışı

Yavaşlık özellikle büyük saha modelinin açılması, katmanların birleştirilmesi ve çıktı üretilmesi sırasında görülüyordu. Kullanıcı aynı anda tarayıcı, ofis uygulamaları ve iki mühendislik aracını açık tutuyordu. İlk envanterde 32 GB fiziksel bellek, yönetilen bir pagefile, orta sınıf profesyonel GPU ve SSD bulunduğunu gördük. Sorunu kullanıcı alışkanlığına bağlamak yerine, tipik çalışma oturumunu ölçüm senaryosu olarak tanımladık.

İlk belirtiler ve yanlış varsayımlar

Belleğin yüzde 98 görünmesi en güçlü belirtiydi; fakat “boş RAM iyi RAM’dir” yaklaşımı Windows bellek yönetimini yanlış yorumlar. Standby cache yararlı olabilir, uygulama ayrılmış belleği hemen kullanmayabilir. Tersine düşük görünen CPU toplamı, tek çekirdeğin doygun olduğu gerçeğini gizleyebilir. Uygulamayı kapatınca hızlanma da yalnızca RAM kanıtı değildir; disk kuyruğu ve eş zamanlı işlem sayısı da aynı anda düşer.

Teknik analiz

Task Manager yanında Performance Monitor ile available memory, committed bytes, hard faults, pagefile kullanımı, disk latency, disk queue ve işlem bazlı working set değerlerini topladık. GPU belleği ve işlemci çekirdek dağılımını da izledik. Kontrollü tekrar sırasında commit limitine yaklaşma, kalıcı hard fault ve yükselen disk gecikmesi birlikte oluşuyorsa bellek baskısı güçlüdür. Yalnızca cache büyüyor, disk sakin kalıyor ve tek çekirdek doluyorsa RAM artışı sınırlı fayda verir.

# Yalnızca yerel performans sayaçlarını listeler; ayar değiştirmez.
Get-Counter -ListSet Memory
Get-Counter 'MemoryAvailable MBytes','MemoryCommitted Bytes' -SampleInterval 5 -MaxSamples 12

Uygulanan çözüm veya önerilen mimari

Ölçümler gerçek bellek baskısını doğruladığında aynı özellikte uyumlu modüllerle 64 GB pilot yükseltme önerdik. BIOS ve üretici uyumluluğu, kanal yerleşimi ve garanti koşulu önceden kontrol edildi. Pagefile kapatılmadı; sistem tarafından yönetilen yapı korundu. Aynı proje ve aynı işlem adımları yükseltme öncesi ve sonrası tekrarlandı. Açılış süresi, hesaplama süresi ve disk beklemesi karşılaştırılarak fayda kullanıcıyla birlikte doğrulandı.

Alternatifler ve karar gerekçesi

İlk alternatif proje verisini bölmek, gereksiz katmanları kapatmak ve eş zamanlı uygulamaları azaltmaktı; maliyetsizdi fakat iş akışını sınırlıyordu. Daha hızlı NVMe, paging etkisini azaltabilir ama RAM’in yerini tutmaz. CPU veya GPU yükseltmesi yalnızca ilgili sayaçlar darboğaz gösterirse anlamlıdır. Yeni iş istasyonu ise işlemci nesli, bellek tavanı ve destek ömrü birlikte yetersizse değerlendirilir. Kararı en ucuz parçaya değil, ölçülen darboğaza göre verdik.

Güvenlik ve operasyonel riskler

Donanım müdahalesi öncesi iş dosyalarının kurumsal depoda ve geçerli yedekte olduğu doğrulandı. Statik elektrik, yanlış modül, garanti etiketi ve BIOS değişikliği operasyon riskleridir. Performans kaydı alırken proje adı ve kullanıcı bilgisi rapordan çıkarıldı. Test dosyası dış destek sağlayıcısına gönderilmedi. Ayrıca pagefile’ı kapatmak veya kayıt defterinde rastgele optimizasyon yapmak gibi geri dönüşü belirsiz öneriler uygulanmadı.

Çıkarılan Dersler

Kontrol Listesi

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