HAProxy Enterprise 3.4: UDP kuralları ve reload’suz backend yönetimi

HAProxy Technologies, HAProxy Enterprise 3.4 sürümünü yayımladı. Sürümle UDP load balancing datagram bazlı kurallarla programlanabilir hale geliyor ve backend’ler Runtime API veya Data Plane API üzerinden reload olmadan oluşturulup silinebiliyor. WAF’ta inspection limitleri ayarlanabiliyor. Bot management ise Altcha ve Cap ile self-hosted CAPTCHA desteği alıyor.

HAProxy Enterprise nedir ve nerede kullanılır?

HAProxy Enterprise, açık kaynak HAProxy load balancer’ı üzerine kurulu ticari bir trafik yönetimi ürünüdür. TCP, UDP ve HTTP trafiğini dağıtır; WAF, bot management ve rate limiting gibi güvenlik modüllerini aynı yapılandırma dilinde toplar. Kurumlar uygulamalarının önünde reverse proxy ve load balancer olarak kullanır. Bilinen alternatifleri arasında NGINX Plus ve F5 BIG-IP yer alır.

HAProxy Enterprise 3.4’te UDP artık programlanabilir

DNS, RADIUS, NTP ve syslog genelde kimsenin bakmadığı katmanda duruyor. Bu servislerden biri takıldığında host ayakta kalabiliyor. Port kontrolü yeşil görünüyor, trafik bozuk sunucuya gitmeye devam ediyor.

HAProxy Enterprise 3.4 bu açığı protokolü bilen health check’lerle kapatıyor. Yeni udp-request content kuralları her datagram üzerinde çalışıyor: filtreleme, server seçimi, değişken atama, takip ve rate limiting. track anahtar kelimesi UDP için stick table sayaçlarını getiriyor.

DNS örneğinde udp-check send-binary boş bir probe yerine 32 byte’lık gerçek bir A kaydı sorgusu yolluyor. udp-check expect rbinary 0002 ise yanıtın başındaki transaction ID’yi eşliyor. Burada ince bir nokta var: DNS sunucusu SERVFAIL veya NXDOMAIN dönse de aynı ID’yi geri yollar. Bu kontrol sunucunun yanıt verdiğini kanıtlıyor, çözümlemenin doğru çalıştığını kanıtlamıyor. Upstream’e çıkamayan bir resolver’ı da sağlıklı sayabilir. Yanıt içeriğini de doğrulamak istiyorsanız beklenen byte dizisini buna göre genişletin.

Örnekteki rate limit, 10.20.120.0/24 ve 10.20.130.0/24 ağlarından gelen ve beş saniyede onu aşan client’ları düşürüyor. UDP’de kaynak adres sahtelenebildiği için kaynak bazlı sayaç tek başına bir koruma katmanı sayılmaz. Bunu hatalı yapılandırılmış client’lara ve hedefli kötüye kullanıma karşı bir fren olarak düşünün.

Reload olmadan backend yayınlamak

Yeni backend eklemek için yapılandırmayı değiştirip reload etmek gerekiyordu. 3.4 ile backend’ler runtime’da oluşturuluyor, güncelleniyor ve siliniyor; mode tcp backend’ler de kapsamda. Özellik açık kaynak HAProxy 3.4’ten geliyor, yani community sürümünü kullanıyorsanız da yararlanabilirsiniz.

Tenant başına backend açan platformlarda ve her pull request için ortam kuran CI pipeline’larında reload sayısı ciddi biçimde düşer. Uzun süreli bağlantı taşıyan servislerde her reload eski process’lerin bir süre yaşaması demekti; bu yük ortadan kalkıyor.

Runtime’da açılan backend’lerin restart sonrasında korunup korunmadığı belli değil. IaC tanımlarınızı tek doğru kaynak olarak tutun ve staging’de bir restart sonrası backend listesini karşılaştırın.

crt-store artık sertifikaları ve JWE anahtar materyalini uzak bir kaynaktan çekip yeniliyor. JWT doğrulama anahtarları issuer’ın takvimine göre döndüğü için elle rotasyon unutulduğunda production’a eski anahtar kalıyordu. Bu adım otomatikleşiyor.

WAF limitleri ve ayrı log hedefi

Intelligent WAF Engine limitleri global olarak, WAF profili bazında veya tek bir kural içinde ayarlanabiliyor. Bu limitler argüman sayısını, argüman adı uzunluğunu, incelenen içerik miktarını ve okunan JSON argüman sayısını sınırlıyor. Aynı instance üzerinde sıkı bir API profili ile hafif bir statik site profilini yan yana tutabilirsiniz. Varsayılanlar değişmiyor; ayarlara dokunmazsanız davranış aynı kalıyor.

Log’larda iki değişiklik var. WAF log’ları CBOR adında binary bir formatta yazılabiliyor ve başka bir hedefe yollanabiliyor. SIEM’e yalnızca WAF olaylarını göndermek kolaylaşıyor, fakat binary format log pipeline’ınızın CBOR çözebilmesini gerektiriyor. Geçmeden önce SIEM parser’ınızın bu formatı okuduğunu doğrulayın.

XML request body incelemesi deneysel olarak işaretli. XML kabul eden eski SOAP endpoint’leriniz varsa önce yalnızca log üreten bir profilde açın, engellemeye sonra geçin.

Bot management için Altcha ve Cap desteği CAPTCHA’yı kendi altyapınızda tutuyor. Challenge sonuçları access log’a düşüyor, böylece politika ayarını zaten topladığınız log’lara bakarak yapabilirsiniz.

Operasyon ekibini ilgilendiren küçük değişiklikler

• VRRP durumu JSON olarak okunabiliyor. Failover script’lerinizde metin parse etmeyi bırakabilirsiniz.
• Data plane native OpenTelemetry ile trace, log ve metric yayıyor.
• GSLB artık TXT, CAA, NAPTR, RDATA ve PTR kayıtlarını ve bir cold-check modunu destekliyor.
• FIPS modunda AWS-LC ile derlenmiş build’ler geliyor.
• OVA image’larında RADIUS, LDAP/LDAPS, Active Directory, Kerberos, OIDC ve SAML ilk açılıştan hazır.

HAProxy Enterprise 3.4 için geçiş sırası

En düşük riskli adım OpenTelemetry ve JSON VRRP durumunu devreye almak; trafiği etkilemiyorlar. Ardından UDP health check’lerini önce en az kullanılan resolver veya syslog havuzunda açın. WAF limitlerini ve CBOR log’u log pipeline’ı hazır olduktan sonra etkinleştirin. Runtime backend yönetimini, restart davranışını staging’de doğruladıktan sonra otomasyona bağlayın. Yükseltme adımları için HAProxy’nin HAProxy Enterprise 3.4 yükseltme talimatlarını izleyin.