Dedicated Server Network Konfigürasyonu Nasıl Yapılır?

Dedicated Server Network Konfigürasyonu, bir sunucunun hangi public IP ile cevap vereceğini, varsayılan çıkış rotasının nereye gideceğini, DNS çözümlemesinin nasıl çalışacağını ve firewall kurallarının trafiği nasıl etkileyeceğini düzenleyen iştir. Yeni kurulumda hedef sadece ağın çalışması değildir; SSH erişimini kesmeden statik IP, gateway, subnet, gerekirse ikinci IP ve güvenli port erişimini aynı anda doğru bağlamaktır. Bu konu özellikle dedicated sunucuyu ilk kez canlıya alan, sağlayıcı panelinden IP bloklarını teslim alan veya mevcut yönlendirmeyi başka bir arayüze taşıyan kullanıcılar için önemlidir. En güvenli başlangıç, önce mevcut yapılandırmayı yedeklemek, sonra tek bir değişkeni adım adım uygulamak, her aşamada ip a, ip route ve ping ile dış erişimi test etmektir. Aşağıdaki akış, dağıtıma göre panel ya da komut farkı olsa da, kalıcı ve geri alınabilir bir kurulum düzeni kurmanı sağlar.

Kurulum öncesi: sağlayıcıdan gelen değerleri ve kurtarma yolunu toparla

Kuruluma başlamadan önce üç şey net olmalı: sunucunun hangi IP bloğunu kullanacağı, ağ değişikliği sırasında içeri nasıl geri dönebileceğin ve hangi servislerin bu değişiklikten etkileneceği. Eğer üretim sisteminde çalışıyorsan değişikliği mümkünse bakım penceresinde yap ve panel konsolu, IPMI, VNC ya da rescue erişimini açık tut. SSH ile bağlı bir sunucuda yanlış gateway veya firewall kuralı, oturumu anında koparabilir; bu yüzden değişikliği uzak oturum yerine konsol üzerinden geri alabilecek durumda olman gerekir.

• Public IP, subnet mask, gateway ve varsa ikinci IP bloğunu not et.
• DNS sunucularını ve gerekiyorsa PTR/rDNS değişiklik sürecini ayrı tut.
• Mevcut ağ dosyasını, geçerli firewall kuralını ve hostname bilgisini yedekle.
• Dağıtımın netplan, NetworkManager, ifupdown veya panel tabanlı ağ ekranı kullanıp kullanmadığını doğrula.

Dedicated Server Network Konfigürasyonu: statik IP ve rota nasıl kurulur?

Aşağıdaki örnek, Ubuntu netplan kullanan bir Linux dedicated server içindir. Dağıtımına göre dosya adı ve servis adı değişebilir; nmcli, ifupdown veya panel içi ağ ekranı kullanan sistemlerde aynı mantık geçerlidir, sadece uygulama yolu değişir. Önce mevcut arayüz adını gör:

ip link
ip a
ip route

Arayüz adı çoğu zaman eth0, ens3 veya benzeri görünür. Sağlayıcının verdiği değerlerle dosyayı düzenle:

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: no
      addresses:
        - 203.0.113.10/24
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

addresses sunucunun cevap vereceği IP’yi belirler. routes içindeki varsayılan rota, dış ağa çıkış kapısıdır. nameservers kısmı çalışmazsa IP ile bağlantı kurulsa bile alan adları çözülemez. Değişiklikten sonra önce sudo netplan try ile dene; sistem belirli süre içinde onay verilmezse eski duruma dönebilir. Her şey doğru görünürse sudo netplan apply kullan ve SSH oturumunu kapatmadan ayrı bir pencereden doğrula.

İlk yapılandırmada hangi ayar neyi değiştirir?

• dhcp4: no otomatik IP dağıtımını kapatır; dedicated sunucuda çoğu zaman statik kurulum için gerekir.
• addresses sunucu IP’sini ve varsa blok içindeki ek adresleri tanımlar.
• routes dış dünyaya çıkış için gereken varsayılan yolu belirler.
• nameservers alan adı çözümlemesini etkiler; servis erişimi çalışırken isim çözümleme bozuk olabilir.
• mtu yalnız gerçekten ihtiyaç varsa elle değiştirilmeli; rastgele düşürmek her zaman fayda sağlamaz.

İkinci bir IP bloğu kullanıyorsan onu da aynı arayüze eklemen gerekir; fakat üretimde önce tek IP ile doğrulama yapmak daha güvenlidir. Birden fazla IP’yi aynı anda açmak, sorun çıktığında hangi satırın hata verdiğini anlamayı zorlaştırır. Bu yüzden ilk denemede tek bir adres, tek bir rota ve tek bir DNS çiftiyle başlamak çoğu ortamda daha güvenli sonuç verir.

DNS, hostname ve PTR ayrımı

DNS, alan adının sunucuna çözülmesidir; PTR ya da rDNS ise IP adresinin geri döndüğü addır. Bunlar aynı şey değildir ve biri çalışırken diğeri bozuk olabilir. Web sitesi, panel ya da mail servisi kuruyorsan DNS kaydı ile PTR talebini karıştırma. Web trafiği için öncelik IP’nin doğru cevap vermesi ve alan adının bu IP’ye yönlenmesidir; PTR ise özellikle mail tarafında itibarlı teslimat için önem taşır.

Firewall ve port erişimini ağ konfigürasyonuna uyumlu hale getir

IP doğru olsa bile firewall fazla sıkıysa sunucu dışarıdan erişilemez. En azından yönetim portunu ve gerçekten kullandığın servis portlarını açık bırak, kalanını kapalı tut. UFW ya da firewalld kullanıyor olabilirsin; servis adı dağıtıma göre değişir, bu yüzden önce etkin güvenlik duvarını doğrula. Gerekirse systemctl list-units --type=service çıktısında ilgili servisi ara. Kural değişikliğinden sonra yalnız portun açık olması yetmez; portun gerçekten dinlediğini de kontrol et.

ss -tulpn
sudo ufw status verbose

Beklenen durum, yalnız ihtiyaç duyulan portların listelenmesi ve 22/tcp üzerinde SSH erişiminin korunmasıdır. Uzak oturumu kapatmadan önce yeni kuralın mevcut bağlantıyı bozmadığını doğrula. Eğer erişimi yanlışlıkla daraltırsan konsol erişimi geri dönüş noktasıdır.

Doğrulama: ağ yapılandırması başarıyla tamamlandı mı?

Kurulumun başarılı sayılması için tek bir komut çıktısı yetmez. Önce arayüzün doğru IP’yi aldığını, sonra varsayılan rotanın geldiğini, ardından dış IP ve alan adı testlerinin çalıştığını görmelisin. Bu sırayı bozma; çünkü ping testi sonucu tek başına sorunun IP’den mi, DNS’den mi yoksa firewall’dan mı kaynaklandığını söylemez.

ip a
ip route
ping -c 3 1.1.1.1
ping -c 3 google.com

Beklenen durumşudur: ip a içinde doğru IP görünür, ip route içinde default route vardır, IP’ye ping döner ve alan adına ping atınca isim çözülür. IP’ye ping dönüyor ama alan adına ping dönmüyorsa sorun çoğu zaman DNS tarafındadır. Hem IP hem alan adı başarısızsa gateway, firewall veya sağlayıcı tarafındaki ağ tanımı kontrol edilir.

Bağlantı koparsa geri alma yolunu nasıl uygularsın?

Canlı sistemde ağ değişikliği yapıyorsan geri alma planı zorunludur. En pratik yöntem, değişiklikten önce mevcut dosyayı kopyalamak ve yeni yapılandırmayı önce deneme modunda uygulamaktır. Netplan kullanıyorsan netplan try zaten bu nedenle işe yarar; onay verilmezse eski duruma döner. Farklı bir panel kullanıyorsan, eski IP ve gateway değerlerini not edip konsoldan geri yükle. Eğer SSH tamamen kesildiyse, önce panik yapmadan konsol erişimine geç; daha sonra yanlış satırı tek tek geri al.

• Önce eski yapılandırmayı geri yükle, sonra servisi yeniden uygula.
• Aynı anda IP, gateway ve firewall’ı değiştirme; sorun ayıklama zorlaşır.
• Geri alma sonrası tekrar ip route ve ping testi yap.

Bu akış, erişimi kaybetmeden ağ ayarı değiştirmek için en güvenli yoldur; ancak sağlayıcı paneli veya dağıtım aracının isimleri farklı olabilir. Bu yüzden gerçek servis adını ve ağ dosyası yolunu kendi ortamında doğrulamak gerekir.

Günlük kullanımda takip edilmesi gereken ağ sinyalleri

Kurulum tamamlandıktan sonra iş bitmez. Dış erişim, reboot sonrası IP’nin sabit kalması, firewall kuralının kalıcılığı ve DNS/PTR uyumu düzenli kontrol edilmelidir. Özellikle mail trafiği, reverse lookup’a duyarlı olduğu için rDNS tarafı ayrı önem taşır. Bir web sunucusunda ise asıl kontrol noktaları IP erişimi, HTTPS portu ve alan adı çözümlemesidir. Ağ tarafında sıra dışı paket kaybı, sık kopma veya yavaş yükleme görürsen MTU ve sağlayıcı rotası yeniden incelenir; bu noktada rastgele değer düşürmek yerine ölçüm yaparak ilerlemek gerekir.

Son kontrol listesi

• Sağlayıcının verdiği IP, subnet ve gateway değerlerini doğru girdin mi?
• Arayüz adı doğru seçildi mi?
• ip route içinde default rota görünüyor mu?
• ping ile IP ve alan adı testi geçiyor mu?
• SSH bağlantısı kesilmeden yeni ayar onaylandı mı?
• Firewall yalnız gerekli portları mı açık bırakıyor?
• Geri alma için eski dosya ve konsol erişimi hazır mı?

Bu adımlar tamamlandıysa Dedicated Server Network Konfigürasyonu canlı kullanım için yeterince güvenli bir temel üzerinde kurulmuş olur. Yine de sağlayıcı paneli, işletim sistemi ve servis modeli değişebileceği için son onayı her zaman kendi ortamında test etmek gerekir.