Cloudflare'a geçiş sonrası bazı kritik alt alan adı servislerim neden beklenmedik şekilde davranıyor?

0

Ana web sitemi ve birkaç alt alan adımı Cloudflare üzerinden yönetmeye başladım. Temel amacım güvenlik ve performans iyileştirmesiydi. Ana sitem sorunsuz çalışsa da, özellikle bir alt alan adımda barındırdığım özel bir API servisim ve WebSocket tabanlı anlık bildirim sistemim garip davranmaya başladı. API isteklerinde bazen orijinal istemci IP adresini alamıyorum, bazen de doğrudan bağlantı kurması gereken servisler Cloudflare'ın IP'si üzerinden geliyor gibi görünüyor ve bu da kimlik doğrulama hatalarına yol açıyor. Sunucu tarafındaki güvenlik duvarı loglarımda da sürekli Cloudflare IP'leri görüyorum, gerçek kullanıcı IP'leri yerine. Hatta bazen, bu servislerime dışarıdan erişim tamamen kesiliyor. Cloudflare paneli üzerinden DNS kayıtlarımı ve proxy durumunu kontrol ettim ama sonuç değişmedi. Acaba Cloudflare'ın proxy ayarları bu tür özel servisler için farklı bir yapılandırma mı gerektiriyor, yoksa sunucumda Cloudflare'ın arkasındaki IP'leri doğru bir şekilde yönetmek için yapmam gereken ek bir ayar mı var? Örneğin, Cloudflare WAF veya Hız Sınırlama (Rate Limiting) kurallarım meşru kullanıcıları neden engelliyor ve 'Error 1020' hatası alıyorlar? (Kaynakta belirtildiği gibi) gibi bir durum mu söz konusu diye düşündüm ama hata kodları farklı. Daha önce Cloudflare'a geçiş yaptıktan sonra siteme erişilemiyor ve 'Error 521: Web server is down' hatası alıyorum, ne yapmalıyım? (Kaynakta belirtildiği gibi) gibi bir bağlantı sorunu da yaşamamıştım. Bu durum, API servisimin doğru çalışması ve log kayıtlarımın şeffaf olması açısından kritik.

Cevaplar (2)

0

Cloudflare'a geçiş sonrası belirli alt alan adı servislerinde, özellikle API ve WebSocket tabanlı sistemlerde yaşanan beklenmedik davranışlar, genellikle Cloudflare'ın proxy mekanizması ile sunucu tarafındaki IP işleme ayarlarının uyumsuzluğundan kaynaklanan yaygın bir teknik vakadır. Orijinal istemci IP adreslerinin kaybolması veya Cloudflare IP'lerinin loglarda görünmesi, bu senkronizasyon eksikliğinin doğrudan bir sonucudur. Sunucu güvenlik duvarı loglarında sadece Cloudflare IP'lerini görmek, istemci kimlik doğrulama süreçlerini ve gerçek trafik analizi yeteneğini olumsuz etkiler.

Ancak bu durum, Cloudflare'ın sunduğu esnek yapılandırma seçenekleri ve sunucu tarafında yapılacak doğru ayarlamalar ile kesinlikle çözüme kavuşturulabilir. Mevcut Cloudflare altyapısı ve sunucu yazılımları, 2026 yılı güncelliğiyle bu tür entegrasyonları desteklemektedir.

Cloudflare, varsayılan olarak gelen trafiği kendi IP'leri üzerinden proxy'ler ve orijinal istemci IP'sini HTTP başlıkları (örn. 'CF-Connecting-IP', 'X-Forwarded-For', 'X-Real-IP') aracılığıyla iletir. Sunucun bu başlıkları doğru şekilde okumadığında veya servislerin doğrudan bağlantı beklediğinde sorunlar ortaya çıkar. Ayrıca, Cloudflare'ın güvenlik ve performans optimizasyon kuralları (WAF, Hız Sınırlama) yanlış yapılandırıldığında meşru trafiği de engelleyebilir, bu da dışarıdan erişim kesintilerine yol açabilir.

Adım Adım çözüm

  1. Alt Alan Adı DNS Proxy Durumunu Kontrol Et: API ve WebSocket gibi doğrudan, şeffaf bağlantı gerektiren servisler için, ilgili alt alan adının Cloudflare DNS kayıtlarındaki proxy durumunu ('turuncu bulut' simgesi) 'DNS Only' ('gri bulut' simgesi) olarak değiştirmelisin. Bu, trafiğin Cloudflare proxy'sini atlayarak doğrudan sunucuna yönlendirilmesini sağlar ve orijinal IP adreslerinin korunmasına yardımcı olur.
  2. Gerçek İstemci IP'sini Sunucuda Yapılandır: Eğer alt alan adını Cloudflare proxy'si arkasında tutmaya devam etmek istiyorsan (güvenlik ve performans faydaları için), sunucu tarafında Cloudflare'ın gerçek istemci IP başlıklarını doğru şekilde okuyacak bir yapılandırma yapmalısın. Örneğin, nginx kullanıyorsan aşağıdaki gibi bir ayar ekleyebilirsin:
    Set_real_ip_from 173.245.48.0/20; # Cloudflare IPv4 aralıkları
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 104.16.0.0/12;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 131.0.72.0/22;
    set_real_ip_from 2400:cb00::/32; # Cloudflare IPv6 aralıkları
    set_real_ip_from 2606:4700::/32;
    set_real_ip_from 2803:f800::/32;
    set_real_ip_from 2405:b500::/32;
    set_real_ip_from 2405:8100::/32;
    set_real_ip_from 2a06:98c0::/29;
    set_real_ip_from 2c0f:f248::/32;
    real_ip_header CF-Connecting-IP; # Cloudflare'ın gönderdiği başlık
    # Alternatif olarak: real_ip_header X-Forwarded-For;
    
    Bu yapılandırma, Nginx'in Cloudflare'dan gelen gerçek istemci IP'sini tanımasını sağlar. Diğer web sunucuları (Apache vb.) için de benzer modüller veya yapılandırmalar mevcuttur.
  3. WebSocket Desteğini Etkinleştir: WebSocket tabanlı servislerin sorunsuz çalışması için Cloudflare panelinde 'Network' bölümündeki 'WebSocket' ayarlarını kontrol et ve etkin olduğundan emin ol. Cloudflare, WebSocket trafiğini proxy'leyebilir ancak bu özelliğin aktif olması kritik öneme sahiptir.
  4. WAF ve Hız Sınırlama Kurallarını Gözden Geçir: Cloudflare WAF veya Hız Sınırlama (Rate Limiting) kurallarının API ve WebSocket trafiğini yanlışlıkla engellemediğinden emin ol. Bu kuralları kontrol ederek, belirli IP adreslerini, IP aralıklarını veya URL yollarını beyaz listeye alabilir, veya spesifik WAF kurallarını geçici olarak devre dışı bırakarak sorunun kaynağını izole edebilirsin.
  5. Origin Pull IP Beyaz Listesi: Sunucunun güvenlik duvarında, Cloudflare'ın resmi IP aralıklarını (IPv4 ve IPv6) beyaz listeye eklediğinden emin ol. Bu, Cloudflare'dan gelen meşru trafiğin sunucu tarafından engellenmemesini sağlar. Cloudflare'ın güncel IP aralıkları listesini resmi dokümantasyonundan düzenli olarak kontrol etmelisin.
0

Arkadaş çok güzel özetlemiş, harfiyen katılıyorum bu adımlara. Özellikle API ve WebSocket gibi trafiğin direkt gelmesi gereken yerlerde 'DNS Only' yapmak çoğu zaman en temiz çözüm oluyor. Ben de benzer bir sorun yaşamıştım, sunucudaki IP tanıma ayarlarıyla uğraşmak yerine direkt bulutu griye çekince sorun anında çözülmüştü.

Ek olarak, eğer illa proxy arkasında tutacaksan, sunucu tarafında Cloudflare'dan gelen HTTP başlıklarını (özellikle 'CF-Connecting-IP') doğru okuduğundan emin ol. Bir de, bu tür kritik API'lerde Cloudflare'ın 'Caching' ayarlarını da kontrol etmekte fayda var. Bazen istemeden API yanıtlarını önbelleğe alıp garip durumlara yol açabiliyor. Caching Level'ı 'No Query String' veya 'Standard' yerine 'Bypass' yapabilirsin o alt alan adı için.
@SinyorWM bu konuyu Şu başlıkta tartışmıştı, WAF ve Rate Limiting'in de nasıl kafa karıştırıcı olabileceğini iyi bilir.

Kullanıcılar