Kısa cevap: Cloudflare'a geçerken iki ayrı karar verirsiniz. Birincisi her DNS kaydının proxy durumu: turuncu bulut açıkken trafik Cloudflare üzerinden akar, gri bulutta kayıt yalnızca DNS olarak çözümlenir. İkincisi hesabın SSL modu ve doğru hedef Full (strict) olmalıdır. Flexible modu bırakmak iki sorun üretir: sunucu bacağı şifresiz kalır ve sunucunuz zaten HTTP'yi HTTPS'e yönlendiriyorsa sonsuz yönlendirme döngüsü oluşur. Ayrıca MX kayıtları ve posta alt adları proxy'lenemez, gri kalmak zorundadır; turuncuya alınırsa e-posta teslimi bozulur.
Turuncu bulut, gri bulut: proxy ne yapıyor
Cloudflare panelinde her kaydın yanında bir bulut simgesi durur ve bu simge, kaydın hangi işi yaptığını belirler. Turuncu bulut, yani proxy açık olduğunda ziyaretçi doğrudan sunucunuza değil Cloudflare'a bağlanır. Trafik Cloudflare üzerinden aktığı için sunucunuzun gerçek IP adresi gizlenir, önbellek ve web uygulama güvenlik duvarı devreye girer, saldırı trafiği sunucunuza ulaşmadan filtrelenebilir.
Gri bulut, yani proxy kapalı olduğunda Cloudflare arada durmaz. Kayıt yalnızca DNS olarak çözümlenir: soran taraf cevabı alır ve doğrudan sizin sunucunuza gider. Önbellek, güvenlik duvarı ve IP gizleme devre dışıdır. Bu bir eksiklik değildir; bazı kayıtlar için zorunlu olan durum budur.
Buradaki en önemli kural e-posta ile ilgilidir. MX kayıtları proxy'lenemez ve posta sunucusuna işaret eden alt adların da gri kalması gerekir. Proxy yalnızca web trafiği için anlamlıdır; posta teslimi aynı yoldan geçmez. Bir posta alt adını turuncuya almak, dışarıdan gelen iletilerin sunucunuza ulaşmasını engeller. Kayıt türlerinin hangisinin ne işe yaradığını DNS kayıt türleri yazısında tek tek ele alıyoruz.
Beş SSL modu ve ne istedikleri
SSL modu, bağlantının iki bacağını ayrı ayrı belirler: ziyaretçi ile Cloudflare arasındaki bacak ve Cloudflare ile sizin sunucunuz arasındaki bacak. Panelde tek bir seçim yapıyor gibi görünür ama sonuç bu iki bacağın birleşimidir.
| Mod | Ziyaretçi bacağı | Sunucu bacağı | Sunucudan istediği | Riski |
|---|---|---|---|---|
| Off | Düz HTTP | Düz HTTP | Hiçbir şey | Hiç şifreleme yok; kullanılmaz |
| Flexible | HTTPS | HTTP | Hiçbir şey; sunucu TLS desteklemese de çalışır | Sunucu bacağı şifresiz; sunucu HTTPS'e yönlendiriyorsa sonsuz döngü |
| Full | HTTPS | HTTPS, sertifika doğrulanmaz | HTTPS konuşması; sertifikanın geçerli olması şart değil | Sunucu bacağında ortadaki adam riski kalır |
| Full (strict) | HTTPS | HTTPS, sertifika doğrulanır | Genel bir otoriteden ya da Cloudflare Origin CA'dan geçerli sertifika | Önerilen mod; sertifika süresi kaçırılırsa site hata verir |
| Strict (SSL-Only Origin Pull) | HTTP ya da HTTPS | Her zaman doğrulamalı HTTPS | Geçerli sertifika; ziyaretçi HTTP ile gelse bile | Sunucu bacağı hiçbir koşulda şifresiz kalmaz |
Tablonun özeti şudur: hedef Full (strict). Sertifikayı ücretsiz bir otoriteden alabilirsiniz; Cloudflare kendi Origin CA sertifikasını da sunar ve bu sertifika yalnızca Cloudflare ile sunucunuz arasındaki bacak için yeterlidir. Sunucu tarafında sertifika kurulumunu SSL kurulumu ve karışık içerik yazısında ele alıyoruz.
Flexible neden sonsuz döngü üretir
Bu, Cloudflare'a yeni geçenlerin karşılaştığı bir numaralı arızadır ve tarayıcıda ERR_TOO_MANY_REDIRECTS olarak görünür. Mekanizması şöyle işler: ziyaretçi HTTPS ile Cloudflare'a gelir. Flexible modda Cloudflare sunucuya HTTP ile bağlanır. Sunucunuzda zaten “HTTP gelirse HTTPS'e yönlendir” kuralı vardır, bu yüzden sunucu bir yönlendirme cevabı döner. Yönlendirme Cloudflare üzerinden ziyaretçiye gider, ziyaretçi yine HTTPS ile Cloudflare'a gelir, Cloudflare yine sunucuya HTTP ile bağlanır. Halka kapanmıştır ve tarayıcı belirli sayıda atlamadan sonra vazgeçer.
Sorunun çözümü yönlendirme kuralını silmek değil, SSL modunu düzeltmektir. Sunucuya geçerli bir sertifika kurup modu Full (strict) yaptığınızda Cloudflare sunucuya HTTPS ile bağlanır, sunucunun yönlendirme kuralı hiç tetiklenmez ve halka kırılır. Flexible'ı bırakmanın ikinci bedeli de şudur: tarayıcı adres çubuğunda kilit gösterir ama Cloudflare ile sunucunuz arasındaki bacak şifresizdir, yani koruma yarımdır.
Adım adım: güvenli Cloudflare geçişi
- Mevcut kayıtları tarayın ve satır satır doğrulayın. Cloudflare bölgeyi otomatik tarar ama bulamadığı kayıt olabilir. Kendi dökümünüzle karşılaştırın: MX, SPF ve DKIM TXT kayıtları, mülk doğrulama dizgileri, eski alt adlar. Eksik satırı elle ekleyin.
- Yalnızca web kayıtlarını turuncuya alın. Kök kayıt ve
wwwturuncu olabilir. Posta sunucusuna işaret eden alt adlar ve MX kayıtlarının hedefleri gri kalmalıdır. Her satırı tek tek gözden geçirmeden isim sunucularını değiştirmeyin. - Sunucuya geçerli bir sertifika kurun. Genel bir otoriteden alınmış sertifika ya da Cloudflare Origin CA sertifikası kullanabilirsiniz. Bu adım atlanırsa Full (strict) moda geçemezsiniz ve Flexible'da kalmaya mahkûm olursunuz.
- SSL modunu Full (strict) yapın. Geçişten önce değil, sertifika sunucuda hazır olduktan sonra. Modu değiştirdikten sonra siteyi hem HTTP hem HTTPS adresinden açıp kontrol edin.
- Yönlendirme kurallarını tek bir yerde toplayın. HTTPS ve
wwwtekilleştirme kuralı ya sunucuda ya Cloudflare tarafında dursun, ikisinde birden değil. İki yerde kural olduğunda yönlendirmeler zincirlenir ve her istek gereksiz atlama yapar. Bu konuyu www mi, www'suz mu yazısında ayrıntılandırıyoruz. - Sunucunun gerçek IP adresine giden eski kayıtları temizleyin. Proxy'nin IP gizleme faydası, bölgede gri kalmış ve aynı sunucuyu gösteren eski bir kayıt varsa boşa çıkar. Kullanılmayan alt adları silin, kullanılanları ya turuncuya alın ya da başka bir adrese taşıyın.
- Sunucu kayıtlarında ziyaretçi IP adresini düzeltin. Proxy açıkken sunucunuza gelen bağlantıların kaynak adresi Cloudflare'a aittir. Günlüklerde ve IP tabanlı kurallarda gerçek ziyaretçiyi görmek için Cloudflare'ın ilettiği
CF-Connecting-IPbaşlığı okunur. Bu düzeltilmezse bütün trafik birkaç adresten geliyormuş gibi görünür ve kaba kuvvet korumaları yanlış çalışır. - İsim sunucularını değiştirin ve e-postayı test edin. Her şey hazır olduktan sonra kayıt kuruluşu panelinde NS satırlarını Cloudflare'ın verdiği değerlerle değiştirin. Yayılma başladıktan sonra kendinize dışarıdan bir deneme iletisi gönderip e-postanın aktığını doğrulayın.
Hangi kayıt turuncu, hangisi gri
Aşağıdaki örnekte alan adı ornekfirma.com ve parantez içindeki değerler YER TUTUCUDUR. Bulut durumları gerçek karara karşılık gelir.
; TURUNCU BULUT, yalnizca web trafigi @ A (sunucunun IPv4 adresi) proxy: acik www CNAME ornekfirma.com. proxy: acik ; GRI BULUT, e-posta ve dogrulama satirlari @ MX 1 smtp.google.com. proxy: uygulanamaz mail A (posta sunucusunun IP adresi) proxy: kapali @ TXT "v=spf1 include:_spf.google.com ~all" _dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@ornekfirma.com" ; SUNUCU KAYITLARINDA ZIYARETCI ADRESI CF-Connecting-IP: (ziyaretcinin gercek IP adresi) X-Forwarded-For: (ziyaretci adresi), (varsa araci vekil sunucular)
Son iki satır DNS kaydı değil, sunucunuza ulaşan isteğin başlıklarıdır. CF-Connecting-IP tek bir adres taşır ve günlük kaydı için en güvenilir olanıdır. X-Forwarded-For ise araya giren vekil sunucuların adreslerini de virgülle ayrılmış biçimde tutabilir.
Yaygın hatalar
- SSL modunu Flexible bırakmak. Kilit simgesi göründüğü için iş bitmiş sanılır. Oysa Cloudflare ile sunucunuz arasındaki bacak şifresiz akar ve sunucuda bir HTTPS yönlendirmesi varsa site sonsuz döngüye girer. Doğru hedef Full (strict).
- MX kaydını ya da posta alt adını proxy'lemek. MX kayıtları proxy'lenemez; posta sunucusunu gösteren alt adı turuncuya almak ise dışarıdan gelen iletilerin teslimini bozar. Posta ile ilgili her satır gri kalır.
- Aynı yönlendirmeyi iki yerde yazmak. Sunucuda bir HTTPS yönlendirmesi, Cloudflare tarafında da bir kural varsa istekler gereksiz atlamalar yapar; kötü kurgulanmışsa doğrudan döngü oluşur. Kural tek yerde durur.
- Sunucunun gerçek IP adresini gösteren eski kaydı silmemek. Yıllar önce açılmış ve aynı sunucuyu gösteren gri bir alt ad, proxy'nin sağladığı IP gizlemesini tamamen işlevsiz bırakır. Saldırgan siteyi atlayıp doğrudan sunucuya gider.
- Sertifikayı sunucuda hiç kurmadan Full seçmek. Full modu sertifikayı doğrulamaz ama sunucunun HTTPS konuşmasını ister. Sunucuda HTTPS hiç yapılandırılmamışsa bu mod da çalışmaz; eksiği kapatmak için önce sertifika kurulur.
- Günlükleri düzeltmeden bırakmak. Proxy açıkken bütün bağlantılar Cloudflare adreslerinden geliyormuş gibi görünür. Ziyaretçi adresine dayanan kaba kuvvet korumaları, oran sınırlamaları ve istatistikler yanlış sonuç verir.
- Geçişi protokol değişikliğiyle aynı güne sıkıştırmak. Cloudflare'a geçmek ile siteyi HTTP'den HTTPS'e almak iki ayrı iştir; aynı gün yapıldığında hangi ayarın hangi arızayı ürettiği anlaşılmaz. Protokol tarafını HTTP'den HTTPS'e taşınma yazısında ele alıyoruz.
Ne zaman uzmana bırakmalı
Tek sayfalık bir siteyi Cloudflare'a almak kısa bir iştir. Zorlaşan durumlar şunlar: aynı alan adı üzerinde kurumsal e-posta çalışıyorsa, bölgede kimin ne zaman eklediği bilinmeyen alt adlar varsa, site bir ödeme sağlayıcısının IP kısıtlamasına bağlıysa, sunucuda daha önce yazılmış birden fazla yönlendirme kuralı varsa ya da site şu anda Flexible modda döngü hatası veriyorsa.
Böyle bir yapıyı sökmeden ölçmek gerekir: hangi kaydın hangi hizmete baktığı, yönlendirmelerin kaç atlama yaptığı ve sertifikanın hangi bacakta eksik kaldığı tek tek çıkarılır. Bu çalışmayı teknik denetim hizmetimiz kapsamında yapıyoruz; sonrasında kurulum ve bakım tarafı için web sitesi ve e-ticaret sayfasına bakabilir ya da iletişim sayfasından yazabilirsiniz.
Devamını okumak için
Kayıt türlerinin tamamı için DNS kayıt türleri, adresleri tekilleştirmek için www mi, www'suz mu, sertifika ve karışık içerik için SSL kurulumu ve karışık içerik, protokol taşınması için HTTP'den HTTPS'e taşınma yazısına bakın. Tüm başlıklar blog sayfamızda, çalışma alanlarımız ana sayfamızda.