Cloudflare Tunnel

Cloudflare Tunnel nedir?

Şirket içindeki bir servisi internete açmanın klasik yolu şudur: sunucuya genel bir IP verirsin, güvenlik duvarında 80 ve 443 portlarını dışarı açarsın, DNS kaydını o IP’ye yöneltirsin. Bu yöntemin üç bilinen bedeli vardır:

1. Sunucunun IP’si herkes tarafından bilinir. Cloudflare’i önüne koysan bile, IP’yi öğrenen saldırgan Cloudflare’i atlayıp doğrudan sunucuna vurabilir.
2. Gelen port açmak gerekir. Kurumsal ağlarda bu, güvenlik ekibiyle yapılacak bir görüşme ve bir değişiklik kaydı demektir.
3. Sabit ve dışarıdan erişilebilir bir IP gerekir. Dinamik IP’li veya CGNAT arkasındaki hatlarda bu yöntem hiç çalışmaz.

Cloudflare Tunnel bu üçünü birden ortadan kaldırır. Sunucuna cloudflared adında küçük bir daemon kurarsın. Bu daemon Cloudflare’e dışarı doğru kalıcı bir bağlantı açar. Kullanıcıdan gelen istek Cloudflare kenarına ulaşır, oradan bu hazır bağlantı üzerinden ters yönde sunucuna iner.

Sonuç: sunucunun internete açık hiçbir kapısı yoktur, ama servisi dünyanın her yerinden erişilebilir.

Nasıl çalışır?

cloudflared başladığında Cloudflare ağına birden fazla ayrı bağlantı kurar (varsayılan dört). Bunlar farklı Cloudflare veri merkezlerine gider; biri koparsa trafik diğerlerinden akmaya devam eder.

Bağlantı TCP ve UDP 7844 portları üzerinden, dışarı doğru açılır. Varsayılan taşıma protokolü QUIC’tir; UDP engelliyse otomatik olarak HTTP/2’ye düşer.

Bir isteğin yolculuğu:

1. Kullanıcı wiki.sirket.com adresini ister.
2. DNS, bu adı <TÜNEL-UUID>.cfargotunnel.com adresine çözer — gerçek IP’n hiçbir adımda görünmez.
3. İstek Cloudflare kenarına ulaşır. Burada WAF, Access, hız sınırlama gibi katmanlar uygulanır.
4. Kenar, o tünele ait açık bağlantılardan birini seçer ve isteği içeri gönderir.
5. cloudflared isteği ingress kurallarına bakarak yerel servise iletir (http://localhost:8080 gibi).
6. Yanıt aynı yoldan geri döner.

İki yönetim biçimi

Bu portaldaki demolarda yerel yönetilen biçimi kullanıyoruz: yapılandırma bir dosyada durduğu için adım adım gösterilebilir ve birebir kopyalanabilir.

Ne zaman kullanılır, ne zaman kullanılmaz

Uygun olduğu işler

• Şirket içi web uygulamalarını (wiki, Jenkins, Grafana, ERP) dışarı açmak
• Origin IP’sini tamamen gizleyip Cloudflare atlatma saldırılarını imkânsız kılmak
• CGNAT veya dinamik IP arkasındaki sunucuları yayınlamak
• VPN’i kaldırıp yerine uygulama bazlı erişim koymak (Access ile birlikte)
• Kubernetes cluster’ındaki servisleri LoadBalancer maliyeti olmadan yayınlamak
• SSH ve RDP erişimini internete port açmadan sağlamak

Uygun olmadığı işler

• Çok yüksek bant genişliği gerektiren aktarımlar. Tünel bir daemon üzerinden geçer; 10 Gbps’lik ham veri aktarımı için Network Interconnect veya Magic Transit daha uygundur.
• Cloudflare’in desteklemediği protokoller. Tünel HTTP, TCP ve UDP taşır ama örneğin çok gecikmeye duyarlı gerçek zamanlı protokollerde ek gecikme fark edilebilir.
• Yetkilendirme beklentisi. Tunnel kimlik doğrulaması yapmaz. Tek başına kullanıldığında yayınladığın servis herkese açıktır — Access ile birlikte kullanılmalıdır.

Somut örnekler

1. İç wiki’yi çalışanlara açmak

Şirket içinde 10.0.5.20:3000 adresinde çalışan bir wiki var. Çalışanlar evden erişmek istiyor, ama VPN yavaş.

# ~/.cloudflared/config.yml
tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  - hostname: wiki.sirket.com
    service: http://10.0.5.20:3000
  - service: http_status:404

Ardından Access politikası: yalnızca @sirket.com uzantılı e-postalar. VPN gerekmez, istemci kurulumu gerekmez.

2. Tek tünelden birden çok servis

ingress kuralları yukarıdan aşağıya değerlendirilir; ilk eşleşen kazanır. Son kural mutlaka her şeyi yakalayan bir kural olmalıdır.

ingress:
  # Yol bazlı: /api altındaki istekler farklı sunucuya
  - hostname: uygulama.sirket.com
    path: ^/api/.*
    service: http://10.0.5.31:8080

  - hostname: uygulama.sirket.com
    service: http://10.0.5.30:3000

  - hostname: grafana.sirket.com
    service: http://localhost:3000

  # Kendinden imzalı sertifikası olan iç servis
  - hostname: eski-sistem.sirket.com
    service: https://10.0.5.40:8443
    originRequest:
      noTLSVerify: true

  # Zorunlu son kural
  - service: http_status:404

Kuralları yayına almadan doğrula:

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://uygulama.sirket.com/api/kullanicilar

İkinci komut, o URL’nin hangi kurala düşeceğini söyler — çok kurallı yapılandırmalarda zaman kazandırır.

3. SSH erişimini port açmadan sağlamak

ingress:
  - hostname: ssh.sirket.com
    service: ssh://localhost:22
  - service: http_status:404

Kullanıcı tarafında ~/.ssh/config:

Host ssh.sirket.com
  ProxyCommand cloudflared access ssh --hostname %h

Sunucunun 22 portu internete kapalı kalır; erişim Access politikasına bağlanır ve her oturum loglanır.

4. Yüksek erişilebilirlik

Aynı tüneli iki ayrı sunucuda çalıştır. Cloudflare gelen trafiği açık bağlantılar arasında dağıtır; birinde bakım yaparken servis kesintiye uğramaz.

# Her iki sunucuda da aynı tünel kimliğiyle
cloudflared tunnel run sirket-ic-servisler

Demo: iç servisi port açmadan yayınlamak

Kuracağımız mimari:

Kullanıcı  →  Cloudflare Edge  →  (giden bağlantı, TCP/UDP 7844)
                                        ↓
                            cloudflared (on-prem sunucu)
                                        ↓
                              iç servis :8080

Güvenlik duvarında hiçbir gelen kural değiştirmiyoruz.

Adım 1 — cloudflared kurulumu

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
  | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' \
  | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared

curl -fsSl https://pkg.cloudflare.com/cloudflared.repo | sudo tee /etc/yum.repos.d/cloudflared.repo
sudo yum update
sudo yum install cloudflared

docker run -d --name cloudflared --restart unless-stopped \
  cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <TOKEN>

brew install cloudflared

Sürümü doğrula:

cloudflared --version

Adım 2 — Cloudflare hesabına bağlan

cloudflared tunnel login

Tarayıcı açılır, alan adını seçersin. Sonuçta ~/.cloudflared/cert.pem oluşur. Sunucuda tarayıcı yoksa komutun verdiği URL’yi kendi makinende aç.

Adım 3 — Tüneli oluştur

cloudflared tunnel create sirket-ic-servisler

Çıktıda tünelin UUID’si ve kimlik dosyasının yolu yazar. Bu dosya tünelin özel anahtarıdır — Git’e koyma, paylaşma.

cloudflared tunnel list

Adım 4 — Yapılandırma dosyası

# ~/.cloudflared/config.yml
tunnel: <TÜNEL-UUID>
credentials-file: /root/.cloudflared/<TÜNEL-UUID>.json

ingress:
  - hostname: icservis.alanadin.com
    service: http://localhost:8080
  - service: http_status:404

cloudflared tunnel ingress validate

Adım 5 — DNS kaydını oluştur

cloudflared tunnel route dns sirket-ic-servisler icservis.alanadin.com

Bu komut, Cloudflare DNS’inde icservis.alanadin.com için <UUID>.cfargotunnel.com adresine giden proxy’li bir CNAME kaydı açar.

Adım 6 — Çalıştır ve doğrula

Önce ön planda, çıktıyı görerek:

cloudflared tunnel run sirket-ic-servisler

Başka bir terminalden:

curl -sI https://icservis.alanadin.com | head -5
curl -s https://icservis.alanadin.com/cdn-cgi/trace | grep -E '^(colo|loc)='

Adım 7 — Sistem servisi yap

sudo cloudflared service install
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared
journalctl -u cloudflared -f

Adım 8 — Erişimi kilitle

Bu adım isteğe bağlı değildir. Tünel kurulduğunda icservis.alanadin.com herkese açıktır.

Cloudflare paneli → Zero Trust → Access → Applications → Add an application → Self-hosted:

• Application domain: icservis.alanadin.com
• Policy: Allow · Emails ending in @sirket.com

Ölçüm: öncesi ve sonrası

Yukarıdaki adımlar Ubuntu 24.04 üzerinde cloudflared 2026.8.3 ile gerçekten uygulandı. Sonuç:

En dikkat çekici satır sonuncusu: uygulamaya tek satır kod yazmadan, önüne kurumsal kimlik doğrulaması kondu.

Yan bulgu: Türkiye trafiği nereye düşüyor

Doğrulama sırasında cdn-cgi/trace çıktısı şunu verdi:

colo=FRA
loc=TR

Yani istek Türkiye’den çıktı ama İstanbul (IST) yerine Frankfurt’ta karşılandı. Aynı ölçümü bu portalın kendi sunucusunda tekrarladığımızda Milano (MXP) çıktı. İki farklı ölçüm, iki farklı şehir, hiçbirinde IST yok.

Bu, Cloudflare’in İstanbul’da noktası olmadığı anlamına gelmez — vardır. Ama Türkiye’den gelen trafiğin oraya düşeceğinin garantisi yoktur; operatörün peering yapılandırması belirleyicidir. Gecikme hesabı yaparken varsayım yerine ölçüm kullan:

curl -s https://alanadin.com/cdn-cgi/trace | grep -E '^(colo|loc)='

Fiyatlandırma

Cloudflare Tunnel’ın kendisi ücretsizdir. Bu, Cloudflare’in 15 Nisan 2021’de yayımladığı “Free Tunnels for Everyone” duyurusuyla resmîleşti: “Any organization can use the secure, outbound-only connection feature of the product at no cost.” Ürün o tarihe kadar Argo Tunnel adını taşıyordu; ücretli olan Argo Smart Routing ayrı bir eklenti olarak kaldı.

Tünel sayısı, eşzamanlı bağlantı sayısı veya aktarılan bant genişliği için ücret alınmaz. Ücretli hale gelen şey, tünelin üzerine koyduğun katmanlardır:

Lisanslama ve hukuki çerçeve

cloudflared açık kaynaktır. Daemon Apache 2.0 lisansıyla GitHub’da yayımlanır. Kodu inceleyebilir, derleyebilir, kurumsal imaj deposuna alabilirsin — güvenlik incelemesinden geçirmesi gereken kurumlar için önemli bir noktadır.

Hizmet tarafı tescillidir. Tünelin diğer ucundaki Cloudflare ağı ve kontrol düzlemi açık kaynak değildir; kullanım Cloudflare Hizmet Şartlarına tabidir.

Veri akışı. Trafik Cloudflare ağı üzerinden geçer ve kenarda TLS sonlandırılır. Bu, Cloudflare’in isteği açık biçimde işlediği anlamına gelir — WAF ve önbellekleme zaten bunu gerektirir. Bunun istenmediği durumlarda uçtan uca şifreli taşıma için Spectrum veya Keyless SSL değerlendirilir.

KVKK açısından. Tünelden geçen kişisel veri yurt dışındaki Cloudflare sunucularında işlenmiş olur. Kurumsal kullanımda Veri İşleme Ek Sözleşmesi ve alt işleyici listesi incelenmelidir. İşlemenin belirli coğrafyalarla sınırlanması için Data Localization Suite adlı ayrı ücretlendirilen eklenti bulunur.

Sık yapılan hatalar

Access politikasını atlamak. Tünel kurulur kurulmaz servis internete açılır. En sık ve en pahalı hata budur.

Son ingress kuralını unutmak. ingress listesi mutlaka hostname’i olmayan bir yakalayıcı kuralla bitmelidir (service: http_status:404). Yoksa cloudflared başlamaz.

Servis kurulumunda yapılandırmayı taşımamak. cloudflared service install /etc/cloudflared/config.yml okur, ~/.cloudflared/config.yml değil. Elle çalışırken sorunsuz olan kurulum, servise alınınca bozulur.

Kimlik dosyasını depoya koymak. <UUID>.json tünelin özel anahtarıdır. Sızarsa başkası senin tünelini taklit edebilir. .gitignore’a ekle, sunucuda chmod 600 yap.

Eski A kaydını silmemek. Tünele geçtikten sonra sunucunun gerçek IP’sine işaret eden eski DNS kayıtları durursa, origin IP’si hâlâ keşfedilebilir ve tünelin sağladığı gizlilik ortadan kalkar.

Gelen portları kapatmamak. Tünel kurulduktan sonra güvenlik duvarında 80/443 gelen kurallarını kaldır. Aksi halde saldırgan Cloudflare’i atlayıp doğrudan sunucuya ulaşabilir.