Debian Bonding FortiGate HA Failover Rehberi: LACP Tuzağı ve Doğru Çözüm

Sisteminizdeki bir sunucuyu iki ayrı firewall üzerinden yedekleyip sırtınızı yasladığınız oldu mu? Ben Debian 12 bir sunucuda Debian bonding FortiGate HA yapısını kurarken tam olarak bu özgüvenle işe başladım. Yapı basit görünüyordu: Biri master, diğeri backup çalışan iki ayrı FortiGate cihazı vardı. Sunucu tarafında eno1 ve eno2 arayüzlerini bond0 altında topladım ve konfigürasyonu uyguladım:

auto bond0
iface bond0 inet static
        address 10.156.61.10
        netmask 255.255.255.0
        gateway 10.156.61.1
        slaves eno1 eno2
        bond-mode 802.3ad
        bond-miimon 100

Görünürde her şey yolundaydı. Sunucuya erişiliyor, trafik akıyor, pingler sorunsuz gidiyordu. Ta ki ilk FortiGate HA failover testini yapana kadar. Master cihaz devre dışı kalıp trafik backup cihazına geçtiği anda sunucu ağdan tamamen izole oldu.

1. Yanılsama: “Her Yere LACP (802.3ad) Kullanılabilir”

Sysadmin refleksidir, bonding denince akla ilk 802.3ad (LACP) gelir. Hem bant genişliğini toplar hem de yedeklilik sağlar diye düşünülür. Ancak bu durum her senaryoda geçerli değil.

LACP’nin çok temel bir şartı var: Bond’a bağlı tüm fiziksel portların aynı mantıksal cihaza (örneğin tek bir switch’e, stacking yapılmış bir switch grubuna veya MLAG çiftine) bağlı olması gerekir.

LACP protokolü, karşı taraftan gelen LACPDU paketlerindeki System ID ve Key bilgilerini okur. Karşıda iki bağımsız FortiGate olduğu için sunucuya gelen System ID’ler farklıydı. Bu konuda detaylı bilgi için Kernel.org Linux Bonding Dokümantasyonu kaynağını inceleyebilirsiniz. Bu durumda Linux bond sürücüsü portları tek bir grupta düzgünce toplayamaz.

Pratikte ne yaşandı?

• Trafik şans eseri tek bir port üzerinden aktı.
• Master FortiGate devreden çıkıp backup’a geçildiğinde, bond sürücüsü yeniden LACP el sıkışması yapmaya çalıştı.
• Bu süreç uzadı, ortamda LACP bekleyen ama alamayan portlar kaldı ve sunucuya erişim tamamen koptu.

Üstelik konfigürasyondaki bond-miimon 100 parametresi burada hiçbir işe yaramadı. Çünkü miimon sadece kablonun elektrik taşıyıp taşımadığına bakar. LACP anlaşamamış olsa bile kablo takılıysa miimon için hat sağlıklı görünür.

2. Deneme: Active-Backup Moduna Geçiş

LACP’nin iki farklı cihaza gitmeyeceğini anlayınca modu active-backup olarak değiştirdim:

bond-mode active-backup
bond-primary eno1
bond-miimon 100

LACP el sıkışması derdi kalmadığı için pasif port kenarda bekler, bir sorun olursa devreye girer diye düşündüm. Fakat test sırasında failover yaptım ve erişim yine kesildi.

Nedeni yine bond-miimon özelliğinde yatıyordu.

FortiGate tarafında HA failover olduğunda, eski master cihaz fiziksel olarak kapanmaz. Portları hâlâ açık kalır, elektrik taşır ve link UP görünür. Cihaz sadece trafiği yönlendirmeyi bırakır.

Linux bond sürücüsü miimon ile baktığında kablonun takılı olduğunu gördüğü için eno1 portunu aktif tutmaya devam etti. Trafiği gönderdi ama karşı tarafta o trafiği işleyecek bir cihaz yoktu.

3. Debian Bonding FortiGate HA Yapısında Gerçek Çözüm: ARP Tabanlı İzleme

Fiziksel kablonun durumuna değil, trafiğin gerçekten akıp akmadığına bakmak gerekiyordu. Yani Katman 3 seviyesinde bir kontrol şarttı.

Çözümü Linux bonding sürücüsünün ARP Monitoring özelliğinde buldum:

auto bond0
iface bond0 inet static
        address 10.156.61.10
        netmask 255.255.255.0
        gateway 10.156.61.1
        slaves eno1 eno2
        bond-mode active-backup
        bond-primary eno1
        bond-arp-interval 1000
        bond-arp-ip-target 10.156.61.1
        bond-arp-validate active
        bond-num-grat-arp 5

Parametrelerin Rolü

• bond-arp-interval 1000: Sunucu her 1 saniyede bir ARP sorgusu atarak hedefin canlılığını kontrol eder.
• bond-arp-ip-target 10.156.61.1: Sorgunun gönderileceği hedef IP adresi. Bu senaryoda FortiGate’lerin ortak Sanal IP’si olan gateway adresi.
• bond-arp-validate active: Sadece yedekte bekleyen arayüzü değil, aktif kullanılan arayüzü de sürekli doğrular. Cevap kesilirse hattın düştüğünü anlar.
• bond-num-grat-arp 5: Failover anında ağdaki cihazların MAC/ARP tablolarını hızlıca güncellemesi için gönderilen paket sayısı. Bu değeri 5 yaparak ARP tablolarının anında güncellenmesini sağladım.

Bu ayarlarla sunucu artık “Kablo takılı mı?” diye değil, “Gateway bana cevap veriyor mu?” diye sormaya başladı.

FortiGate Tarafındaki Değişiklik

Debian tarafında LACP’yi bırakıp active-backup yapısına geçince FortiGate tarafını da uyumlu hale getirmek gerekiyordu.

FortiGate üzerindeki portlar hâlâ bir LACP/Aggregate grubunun parçası olarak yapılandırılmışsa, Debian’dan gelen standart paketler sorun çıkarabilirdi. Resmi Fortinet Dokümantasyon Portalı rehberlerinde de belirtildiği üzere, bu tür bağımsız geçişlerde LACP yapılandırması kaldırılmalıdır. Bu yüzden FortiGate tarafındaki aggregate yapıyı kaldırıp ilgili portları bağımsız (standalone) hale getirdim.

Test ve Doğrulama

Ayarları uyguladıktan sonra konsoldan durumu izledim:

cat /proc/net/bonding/bond0

• Master FortiGate kapatıldığında: eno1 üzerinden ARP cevabı gelmediği an sürücü durumu fark etti ve eno2 aktif oldu.
• Master geri geldiğinde: bond-primary eno1 tanımlı olduğu için, eno1 tekrar ARP cevabı almaya başladığı an trafik güvenli şekilde ana hatta döndü.

Kesintisiz ve sorunsuz bir geçiş elde ettim.

Çıkarılan Dersler

1. Topolojiyi bilmeden bonding modu seçilmez: Portlar iki farklı cihaza gidiyorsa ve ortada MLAG veya Stack gibi bir yapı yoksa LACP kullanılmamalıdır.
2. Miimon her durumu kapsamaz: Fiziksel hattın açık olması, trafiğin aktığı anlamına gelmez. Cihaz açık ama trafiği iletmiyor olabilir.
3. HA yapılarında ARP monitoring daha güvenilirdir: Gateway IP adresini hedef göstererek yapılan ARP doğrulaması, firewall geçişlerinde en kararlı çalışan yöntemdir.