itsrda

Cloudflare Tunnel ile İç Servisi Port Açmadan Güvenle Yayınlamak

Modem üzerinde port yönlendirmesi yapmadan, ofisteki veya evdeki bir web uygulamasını Cloudflare Tunnel ile internete açmanın ve Cloudflare Access ile kimlik doğrulaması eklemenin pratik anlatımı.

İçeride çalışan bir web uygulamasına dışarıdan erişmek istediğinizde klasik yol, modemde bir port yönlendirmesi açmaktır. Bu yöntemin üç sorunu vardır: sabit IP veya dinamik DNS gerekir, servis tüm internete açılır ve TLS sertifikasını kendiniz yönetmeniz gerekir. Cloudflare Tunnel bu üç sorunu tersine çevirir: iç ağdaki küçük bir program (cloudflared) Cloudflare'e dışarıya doğru bir bağlantı kurar ve trafik bu tünelden gelir. Modemde açık port gerekmez.

Nasıl çalışır?

  1. İç ağdaki makinede cloudflared çalışır ve Cloudflare'in uç sunucularına giden, kalıcı şifreli bağlantılar açar.
  2. Bir alan adı (ör. panel.ornek.com) bu tünele yönlendirilir.
  3. Ziyaretçi bu adrese geldiğinde istek Cloudflare'e ulaşır, tünel üzerinden iç servise iletilir.

İç servis yalnızca localhost üzerinde dinleyebilir; ağdaki hiçbir port internete bakmaz. Alan adınızın DNS'inin Cloudflare üzerinde yönetiliyor olması gerekir.

Kurulum özeti

Cloudflare Zero Trust panelinde Networks → Tunnels bölümünden yeni bir tünel oluşturun. Panel, işletim sisteminize uygun kurulum komutunu verir. Debian tabanlı bir sistemde (Raspberry Pi dahil) genellikle şu iki adımdan oluşur: cloudflared paketini kurmak ve panelin verdiği jetonla servisi kaydetmek.

sudo cloudflared service install <PANELDE-GORUNEN-JETON>
systemctl status cloudflared --no-pager

Bu komut tüneli bir systemd servisi olarak kaydeder; cihaz yeniden başlayınca tünel de kendiliğinden döner. Ardından panelde Public Hostname ekleyin:

  • Alt alan adı: panel, etki alanı: ornek.com
  • Servis türü: HTTP, adres: localhost:5000

Birkaç saniye sonra https://panel.ornek.com adresi uygulamanıza açılır ve sertifika Cloudflare tarafından sağlanır. Raspberry Pi 3 gibi ARM cihazlar için arm veya arm64 paketini seçmeniz gerekir.

Tek başına yeterli değil: kimlik doğrulama

Tünel yalnızca yolu güvenli hale getirir; uygulamanın kendisine kimin girebileceğini söylemez. Uygulamanın kendi giriş sayfası zayıf bir parola ile korunuyorsa, saldırganlar yine de o sayfaya ulaşabilir ve deneme saldırısı yapabilir.

Burada Cloudflare Access devreye girer. Zero Trust panelinde bir "Self-hosted application" tanımlar ve hangi e-posta adreslerinin geçebileceğini belirten bir politika yazarsınız. Kullanıcı siteye gelmeden önce Cloudflare'in giriş ekranında (tek kullanımlık e-posta kodu veya Google hesabı gibi) kimliğini doğrular; uygulamanız bu aşamadan geçmemiş hiçbir isteği görmez.

Önerilen politika mantığı:

  • Allow: yalnızca belirli e-posta adresleri veya yetkili bir alan adı.
  • Hiçbir kural eşleşmezse varsayılan olarak erişim reddedilir.
  • Oturum süresini kısa tutun (ör. 8-24 saat).

Cloudflare'in ücretsiz planı küçük ekipler için Access'i belirli bir kullanıcı sayısına kadar içerir; güncel limit için kendi fiyatlandırma sayfasına bakın.

Uygulama tarafında yapılacaklar

  • Uygulamayı 127.0.0.1'e bağlayın, 0.0.0.0'a değil. Böylece yerel ağdaki diğer cihazlar da doğrudan erişemez.
  • Uygulamanın kendi giriş sistemini kapatmayın; Access ek bir katmandır, yerine geçmez. Parolalar karma (hash) olarak saklanmalı, hatalı denemeler sınırlandırılmalıdır.
  • Uygulama gerçek istemci IP'sini görmek istiyorsa CF-Connecting-IP başlığını kullanın; bu başlığa yalnızca isteğin gerçekten Cloudflare'den geldiğinden eminseniz güvenin.
  • Yönetim ekranları gibi hassas yolları ayrı bir Access uygulamasıyla daha sıkı politikaya bağlayabilirsiniz.

Sık karşılaşılan sorunlar

Belirti Neden Çözüm
502 Bad Gateway İç servis çalışmıyor veya adres yanlış curl http://localhost:5000 ile yerelde deneyin
Tünel "inactive" cloudflared servisi durmuş systemctl status cloudflared, journalctl -u cloudflared
Sonsuz yönlendirme Uygulama HTTPS'i zorluyor Uygulamada X-Forwarded-Proto başlığını dikkate alın
Yükleme çok yavaş Pi'nin ağ veya işlemcisi sınırda Boyutlu dosyaları tüneldan geçirmeyin

Ne zaman tünel uygun değil?

Cloudflare üzerinden akan trafiğin Cloudflare tarafından işlendiğini unutmayın. Çok hassas veriler için bu bir risk değerlendirmesi gerektirir. Ayrıca büyük dosya aktarımı ve video akışı hizmet şartlarına ve planınıza bağlı kısıtlara tabidir. Yalnızca bir kaç kişinin eriştiği iç araçlar içinse, tünel ve Access birlikte basit ve güçlü bir çözümdür.

Servisi systemd ile kalıcı hale getirmeyi henüz yapmadıysanız önce Flask servis yazımıza göz atın; ardından güvenlik katmanı olarak SSH sertleştirme adımlarını uygulayın.

Adım adım: tüneli kurup doğrulamak

Tünelin mantığı, sunucudan dışarıya kalıcı bir bağlantı açmasıdır; bu yüzden modemde port yönlendirmesi gerekmez. Genel akış: (1) alan adınızı Cloudflare'e ekleyin; (2) sunucuya cloudflared istemcisini kurup hesabınıza bağlayın; (3) bir tünel oluşturun ve adını verin; (4) bir yapılandırma dosyasında hangi alt alan adının hangi yerel adrese gideceğini yazın; (5) DNS kaydını tünele yönlendirin; (6) tüneli bir systemd servisi olarak çalıştırın.

Yapılandırma dosyası kabaca şöyle görünür:

tunnel: TUNEL-KIMLIGI
credentials-file: /etc/cloudflared/TUNEL-KIMLIGI.json
ingress:
  - hostname: panel.ornek.com
    service: http://localhost:8000
  - service: http_status:404

Son satır önemlidir: eşleşmeyen her istek 404 alır, yani tünel yanlışlıkla başka bir şeyi yayınlamaz. Servis haline getirdikten sonra systemctl status cloudflared ile çalıştığını, tarayıcıdan alt alan adını açarak da yayını doğrulayın. Panelin kendisini de servis olarak çalıştırmayı Flask systemd rehberinde anlattık.

Güvenlik katmanlarını tamamlamak

Tünel, sunucunuzun gerçek adresini ve açık portlarını gizler; ama sayfayı bulan herkesin giriş ekranını görmesini engellemez. Üç ek katman önerilir:

  1. Uygulama girişi: Güçlü parola, hatalı giriş sınırı, CSRF koruması (Flask güvenli giriş).
  2. Erişim politikası: Cloudflare'in erişim özelliğiyle yalnızca belirli e-posta adreslerinin ya da kimliklerin giriş sayfasına ulaşmasına izin verebilirsiniz. Bu, uygulama açığı bulunsa bile saldırganı kapıda durdurur.
  3. Yerel güvenlik duvarı: Uygulama portu yalnızca localhost'tan erişilebilir olmalı; dış arayüze dinletmeyin (UFW rehberi).

Gerçek bir otel panelinde bu üç katmanı birlikte kullanıyoruz; bunların nasıl çalıştığını personel paneli güvenlik katmanları notunda anlattık.

Sorun giderme

  • 502 / 1033 hatası: Genellikle tünel çalışıyor ama yerel uygulama durmuştur. curl http://localhost:8000 ile uygulamanın yanıt verdiğini kontrol edin.
  • Tünel bağlanıyor ama alan adı açılmıyor: DNS kaydının tünele (CNAME) gittiğini ve ingress içindeki hostname ile birebir uyduğunu doğrulayın.
  • Her yeniden başlatmada kopuyor: Servis enable edilmemiştir.
  • Gerçek istemci adresi hep aynı görünüyor: Uygulama, istemci adresini doğrulanmış başlıktan okumalı; sahte başlığa güvenmeyin ve yalnızca güvenilir ara katmandan gelen başlığı kabul edin.
  • Yükleme boyutu hataları: Büyük dosya gönderen formlarda Cloudflare'in istek boyutu sınırlarına takılabilirsiniz.
  • Günlükler: journalctl -u cloudflared -n 100 bağlantı sorunlarını gösterir (journalctl rehberi).

Sık sorulan sorular

Tünel ücretsiz mi? Temel tünel özelliği ücretsiz planda kullanılabilir; koşullar zamanla değişebileceği için güncel plan sayfasına bakın.

Tüm trafiğim Cloudflare üzerinden mi geçiyor? Evet, tünel üzerinden yayınlanan uygulamanın trafiği Cloudflare altyapısından geçer. Kişisel veri içeren sistemlerde bu durumu aydınlatma metninizde ve değerlendirmenizde göz önünde bulundurun (KVKK notları).

Tünel çökerse ne olur? Dışarıdan erişim kesilir, yerel ağdan erişim sürer. Servisin Restart=always ile çalışmasını ve bir izleme ile uyarı almayı sağlayın (servis izleme).

Hızı etkiler mi? Biraz gecikme ekler; panel gibi hafif uygulamalarda fark edilmez. Hattınızı ölçmek için hız testi aracına bakın.

Not: Komutları üretim ortamında çalıştırmadan önce yedek alın ve önce test ortamında deneyin. Bir adım sizde farklı davranıyorsa bize yazın, rehberi güncelleyelim.