Netplan ile Policy-Based Routing ve Yedek Hat Tasarımı

Birden fazla uplink kullanan Linux sunucularda varsayılan rota tek başına yeterli değildir. Yönetim trafiğinin ayrı çıkması, replikasyon akışının ikinci hat üzerinden gitmesi veya belirli kaynak ağların farklı gateway kullanması gerektiğinde policy-based routing devreye girer. Ubuntu tabanlı sunucularda bunu elle ip rule yazarak değil, Netplan üzerinden kalıcı ve okunabilir biçimde kurmak daha sağlıklıdır.

Hangi problem çözülüyor?

Tek NIC mantığında gelen ve giden trafik aynı yol üzerinden akar. Fakat çift uplink senaryosunda şunlar ortaya çıkar:

• Yanlış arayüzden çıkan cevap paketleri
• Asimetrik yönlendirme nedeniyle bozulmuş oturumlar
• Failover anında yönetim erişiminin kaybı
• Replikasyon trafiğinin üretim hattını sıkıştırması

Policy-based routing, paketlerin sadece hedefe göre değil; kaynak IP, tablo ve kural önceliğine göre yönlendirilmesini sağlar.

Örnek senaryo

Bu rehberde şu kurguyu ele alıyorum:

• ens18: üretim ağı, varsayılan trafik
• ens19: replikasyon ve yedek erişim ağı
• 10.20.0.10/24: uygulama IP’si
• 172.16.30.10/24: yönetim veya replikasyon IP’si

Amaç; 172.16.30.10 kaynağından çıkan trafiği ikinci gateway üzerinden zorlamak, birincil rota dururken bile kaynak simetrisini korumaktır.

Netplan yapılandırması

Önce özel routing table tanımı kullanacağız. Ubuntu’da tablo numarasını dosyada doğrudan verebiliriz:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - 10.20.0.10/24
      routes:
        - to: default
          via: 10.20.0.1
    ens19:
      addresses:
        - 172.16.30.10/24
      routes:
        - to: 172.16.30.0/24
          via: 172.16.30.1
          table: 200
      routing-policy:
        - from: 172.16.30.10/32
          table: 200

Bu tanımın kritik noktası routing-policy bölümüdür. Böylece 172.16.30.10 kaynağından çıkan trafik ana tabloyu değil, tablo 200 içindeki rotaları kullanır.

Yedek hat için varsayılan rota ekleme

İkinci uplink uzak erişim veya site-to-site yedek hat olarak kullanılacaksa yapı şöyle genişler:

    ens19:
      addresses:
        - 172.16.30.10/24
      routes:
        - to: default
          via: 172.16.30.1
          table: 200
          metric: 50
      routing-policy:
        - from: 172.16.30.10/32
          table: 200
          priority: 100

Buradaki metric, aynı tablo içindeki rota tercih sırası içindir; tablo seçimini ise routing-policy belirler. Bu ayrımı karıştırmak, policy-based routing kurulumlarında en sık yapılan hatalardan biridir.

Uygulama ve doğrulama adımları

Dosyayı örneğin /etc/netplan/99-multi-uplink.yaml gibi gerçek hedefe yerleştirdikten sonra şu sırayı izleyin:

sudo netplan generate
sudo netplan try
ip rule show
ip route show table main
ip route show table 200
ip route get 8.8.8.8 from 172.16.30.10

Özellikle son komut, paketin beklenen gateway üzerinden gidip gitmediğini açıkça gösterir.

Failover mantığı nasıl düşünülmeli?

Policy-based routing tek başına sağlık kontrolü yapmaz. Gerçek failover istiyorsanız:

• keepalived veya benzeri araçla gateway erişimini izleyin
• route değişimini script veya networkd-dispatcher ile tetikleyin
• uygulama timeout’larını yeni topolojiye göre gözden geçirin

Sunucu tarafında rota değişse bile upstream firewall veya NAT kurgusu ikinci hattı tanımıyorsa failover yalnızca kâğıt üzerinde kalır. Bu yüzden ağ tasarımını uçtan uca doğrulamak gerekir.

Sık karşılaşılan hata senaryoları

• rp_filter nedeniyle ters yol denetiminin paketleri düşürmesi
• Policy kuralının yanlış kaynak IP’ye bağlanması
• Tablo içinde dönüş rotasının eksik kalması
• DNS veya yönetim servisi gibi kritik trafiğin yanlış hatta taşınması

Bu tip hatalarda ilk bakılacak komutlar ip rule, ip route get, journalctl -u systemd-networkd ve gerekirse tcpdump -i ens19 olmalıdır.

Sonuç

Netplan ile policy-based routing ve yedek hat tasarımı, çoklu uplink kullanan Linux sunucularda kontrolü varsayılan rotadan geri almanızı sağlar. Doğru tablo, kural önceliği ve doğrulama alışkanlığıyla hem yönetim trafiğini hem kritik veri akışlarını daha öngörülebilir biçimde ayırabilirsiniz. Özellikle kurumsal altyapılarda bu disiplin, ağ esnekliğini ciddi ölçüde artırır.