Blog

Cloudflare özel kaynak hizmetleri artık genel kullanıma açık. Bu adımla birlikte, şirket içi ağda çalışan bir uygulamayı sunucunun genel IP adresini dışarı vermeden proxy katmanı üzerinden yayınlamak mümkün hale geliyor. Mantık oldukça yalın: özel bir IP adresine işaret eden proxied bir DNS kaydı oluşturuyorsunuz ve trafik, hâlihazırda kurulu olan ağ bağlantınız üzerinden kaynağa ulaşıyor. Böylece web uygulaması güvenlik duvarı, önbellekleme, bot yönetimi, hız sınırlama ve Workers gibi yetenekler, herkese açık kaynaklarda olduğu gibi özel kaynaklarda da devreye giriyor.

Bu gelişme, özellikle son birkaç yılda hızla çoğalan iç servisler açısından önemli. Dahili API’ler, yapay zeka ajanlarının arka uçları, MCP sunucuları ve operasyonel araçların büyük bölümü internetten erişilecek şekilde tasarlanmadı; ancak bu servislerin iş ortaklarından, müşterilerden veya otomasyon ajanlarından gelen istekleri de kabul etmesi gerekiyor. Önceden bu dengeyi kurmak için ya genel bir IP açılıyor, ya güvenlik duvarında port deliği bırakılıyor ya da kaynağın yanında ayrı bir tünel bileşeni çalıştırılıyordu. Yeni yetenek, bu üç zorunluluğu büyük ölçüde ortadan kaldırıyor.

Özel kaynak tam olarak ne anlama geliyor?

Barındırma dünyasında “özel kaynak” ifadesi, dışarıdan doğrudan yönlendirilemeyen bir IP adresi üzerinde çalışan sunucuyu tanımlar. Bu adresler genellikle şu bloklardan gelir:

• RFC 1918 kapsamındaki klasik iç ağ adresleri (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• RFC 6598 taşıyıcı sınıf NAT (CGNAT) aralığı (100.64.0.0/10)
• RFC 4193 benzersiz yerel IPv6 adresleri (fc00::/7)

Bu aralıklardaki bir sunucu, internetten doğrudan erişilemez; dolayısıyla klasik anlamda DDoS koruması, WAF veya CDN önbelleği gibi katmanları önüne koymak da kolay değildi. Özel kaynak yönlendirmesi, tam bu noktada devreye girerek ağ topolojisini değiştirmeden uygulama katmanı güvenliğini mümkün kılıyor.

Genel kullanıma açılan yetenekler

Kapalı beta döneminde yalnızca davetle erişilebilen özellik, artık çok daha geniş bir kullanıcı kitlesine hitap ediyor. Proxied bir A veya AAAA kaydı özel bir IP’ye yönlendirildiğinde, aşağıdaki bileşenler herkese açık kaynaklardaki davranışın aynısını sergiliyor:

• Web uygulaması güvenlik duvarı ve yönetilen kural setleri
• Bot yönetimi ve otomatik trafik sınıflandırması
• Hız sınırlama (rate limiting) politikaları
• Uç noktada içerik önbellekleme
• Yeniden yazma ve dönüştürme kuralları
• Workers ile çalışan sunucusuz mantık

Bunların pratik anlamı şu: iç uygulamanız artık dış dünyaya açık olan bir uygulamayla aynı güvenlik ve performans araçlarına sahip. Örneğin önbellek katmanını açarak sık sorgulanan dahili API yanıtlarını uçta tutabilir, bot trafiğini ayıklayabilir veya yapay zeka destekli WAF kuralları ile anormal istekleri daha kaynağa ulaşmadan durdurabilirsiniz.

Trafik akışı adım adım nasıl işliyor?

Kurulum sırasında izlenen yol, alışılmış bir DNS kaydı oluşturmaktan çok farklı değil. Süreç kabaca şöyle ilerliyor:

1. Alan adı yönetim panelinde kaynağınız için bir A veya AAAA kaydı oluşturuyorsunuz.
2. Kaydın değerine sunucunun özel IP adresini yazıyorsunuz.
3. Proxy seçeneğini etkinleştiriyorsunuz; yani kayıt artık doğrudan çözümlenmiyor, trafik sağlayıcının ağına yönleniyor.
4. Desteklenen özel aralıklar için özel ağ yönlendirmesi otomatik olarak devreye giriyor. Bu aralıklarda ayar kapatılamıyor; API üzerinden kapatma denemesi hata ile sonuçlanıyor.
5. Kaynak genel bir IP taşıyor ancak yalnızca özel ağ üzerinden erişilebiliyorsa, ilgili seçeneği elle açmanız gerekiyor.

İsteğin geri kalan yaşam döngüsü değişmiyor: TLS sonlandırma, kural motoru, güvenlik duvarı ve önbellek sağlayıcının ağında çalışmaya devam ediyor. Edge tarafı, isteğin nereye gideceğini belirlemek için kaynak envanterine danışıyor ve dönen yanıttaki meta bilgi, hedefe özel ağ yolu üzerinden gidilmesi gerektiğini söylüyor.

API tarafında görünüm

Dağıtımlarını otomasyonla yöneten ekipler için özel yönlendirme, standart bir DNS kaydının üzerine eklenen tek bir alandan ibaret. Tipik bir istek gövdesi şu şekilde görünüyor:

POST /zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "panel.example.com",
  "content": "10.20.0.15",
  "ttl": 120,
  "proxied": true,
  "private_routing": true
}

Buradaki private_routing alanı, kaydın özel ağ üzerinden çözümleneceğini bildiriyor. Altyapıyı kod olarak yönetiyorsanız, bu tek satırlık ekleme mevcut dağıtım şablonlarınıza kolayca entegre edilebilir.

Bağlantı seçenekleri: WAN ve Mesh karşılaştırması

Kaynağa ulaşmak için iki farklı bağlantı yaklaşımı bulunuyor. Hangisinin seçileceği, ağınızın mevcut mimarisine ve kaç kaynağı aynı anda yayınlamak istediğinize bağlı.

Kriter	WAN yaklaşımı	Mesh yaklaşımı
Kaynakta ek yazılım	Gerekmez	Özel ağ içinde bir bağlayıcı çalışır
Hizmet verilen kaynak sayısı	Mevcut ağ bağlantısına bağlı	Tek bağlayıcı birden fazla kaynağa hizmet verebilir
Uygun olduğu senaryo	Kurumsal ağ ve şube bağlantıları zaten kurgulanmışsa	Dağınık, çok sayıda küçük kaynağın olduğu ortamlar
Yönetim yükü	Ağ tarafında merkezi	Bağlayıcı yaşam döngüsünün izlenmesi gerekir

Her iki durumda da ortak nokta aynı: kaynağın genel IP almasına veya gelen trafik için güvenlik duvarında istisna tanımlanmasına gerek kalmıyor.

Sınırlamalar ve dikkat edilmesi gerekenler

Genel kullanıma açılmış olsa da yetenek henüz her açıdan tam değil. Planlama yaparken şu kısıtları hesaba katmak gerekiyor:

• Akıllı yönlendirme desteklenmiyor: Trafik yolunu optimize eden akıllı yönlendirme özelliği özel kaynaklarda devre dışı.
• Sabit CDN çıkış IP’leri yok: Kaynağınızda IP tabanlı izin listesi tutuyorsanız, mevcut yapılandırmanızı gözden geçirmeniz gerekebilir.
• Sağlık kontrolleri ek ürün gerektiriyor: Kaynak sağlık denetimi için yük dengeleme bileşeninin etkin olması şart.
• Otomatik ayar kapatılamıyor: Standart özel aralıklarda yönlendirme zorunlu olarak açık kalıyor.

Bu maddeler, özellikle karmaşık yük dengeleme topolojileri kuran ekipler için tasarım aşamasında dikkate alınması gereken noktalar. Basit ve orta ölçekli kurulumlarda ise etki genellikle sınırlı kalıyor.

Güvenlik açısından ne değişiyor?

En büyük kazanım, saldırı yüzeyinin daralması. Gelen trafik için güvenlik duvarında port açmamak, yanlış yapılandırılmış bir kuralın aylarca fark edilmeden açık kalması riskini ortadan kaldırıyor. Kaynağın IP adresi hiçbir zaman dışarıdan çözümlenemediği için hedef odaklı tarama ve doğrudan IP üzerinden yapılan denemeler de büyük ölçüde anlamsızlaşıyor.

İkinci kazanım, uygulama katmanı korumalarının iç servislere de yayılması. DDoS trafiği kaynağa ulaşmadan edge tarafında emiliyor, kötü niyetli botlar eleniyor ve hız sınırlama ile kaba kuvvet denemeleri yavaşlatılıyor. Kimlik doğrulama tarafında ise mevcut sıfır güven politikalarıyla birlikte çalıştırıldığında, hem ağ hem de uygulama düzeyinde katmanlı bir model elde ediliyor.

Üçüncü nokta gözlemlenebilirlik. Trafik sağlayıcının ağından geçtiği için istekler, kural eşleşmeleri ve engelleme olayları tek bir yerde toplanabiliyor. İç uygulamaların loglarını ayrı ayrı toplamaya çalışmak yerine merkezi bir görünüm elde ediliyor.

Hangi senaryolarda işe yarıyor?

Özel kaynak yönlendirmesinin en belirgin kullanım alanları şunlar:

• Dahili API’lerin seçili iş ortaklarına açılması: Servis, iç ağda kalırken yalnızca yetkili taraflar erişebiliyor.
• Yapay zeka ajanı arka uçları: Model sunucuları ve araç katmanları, dışarıya açık bir uç nokta olmadan istek kabul edebiliyor. Yapay zeka ajanları internetin ikinci okuyucusu haline geldikçe bu ihtiyaç daha da belirginleşiyor.
• MCP sunucuları ve entegrasyon katmanları: Harici asistanların iç araçlara güvenli biçimde erişmesi gereken durumlar.
• Yönetim panelleri: VPN zorunluluğunu azaltırken erişimi kural tabanlı hale getirmek.
• Test ve ön üretim ortamları: Müşteri geri bildirimi için paylaşılması gereken ancak herkese açık olmaması istenen kurulumlar.

Kendi sunucusunda uygulama barındıran ekipler için de tablo değişmiyor. İster VPS hosting üzerinde çalışan bir servis, ister fiziksel bir sunucu olsun; önemli olan kaynağın adres yapısı, bulunduğu yer değil. Paylaşımlı ortamlarda çalışan ve WordPress hosting paketleriyle yayınlanan sitelerde ise bu ayara genellikle ihtiyaç duyulmuyor; çünkü bu siteler zaten herkese açık bir kaynak olarak tasarlanıyor.

Geçiş için pratik kontrol listesi

Mevcut bir iç uygulamayı bu modele taşımayı düşünüyorsanız aşağıdaki sıra işinizi kolaylaştırır:

1. Envanter çıkarın: Hangi servisler dış erişime ihtiyaç duyuyor, hangileri yalnızca iç kullanımda kalmalı?
2. Adres aralıklarını doğrulayın: Kaynak IP’lerinin otomatik yönlendirme kapsamına girip girmediğini kontrol edin.
3. Bağlantı yöntemini seçin: Mevcut kurumsal ağınız varsa WAN, dağınık kaynaklarınız varsa özel ağ içinde bir bağlayıcı daha uygun olacaktır.
4. Güvenlik politikalarını gözden geçirin: IP tabanlı izin listeleri, sağlık kontrolleri ve hız sınırlama kurallarını yeni akışa göre uyarlayın.
5. Kademeli geçiş yapın: Önce tek bir iç servisle başlayıp izleme ve logları doğruladıktan sonra diğer kaynaklara yayın.

Bu adımlar tamamlandığında, özel kaynak yönlendirmesi mevcut ağ mimarinizi bozmadan iç uygulamalarınıza merkezi güvenlik, önbellekleme ve gözlemlenebilirlik katmanı kazandırır.