API sunucumu Cloudflare Tunnel arkasına alıp 443'ü internete kapatmalı mıyım?
Soru
AWS EC2 üzerinde API sunucumu Laravel Octane'in FrankenPHP sürücüsüyle servis ediyorum. Aklıma şöyle bir kurgu geldi: Cloudflare'den bir tunnel oluşturup uygulama sunucusuna yönlendirsem ve uygulama localhost:8080'de çalışsa, API sunucusunda 443 hiç internete çıkmamış, SSL yönetimi de API sunucusunda olmamış olur. Bu ne kadar doğru olur, dezavantajları ne olur? Mevcut kurulumum şöyle: Deployment için DeployerPHP kullanıyorum. Trafik Cloudflare → Caddy → App şeklinde akıyor. SSL sertifikasını Cloudflare Origin ile alıp app sunucusunda Caddy konfigürasyonu üzerinden okutuyorum; Cloudflare tarafında SSL "Full (strict)" modunda. Laravel Octane, Caddy ile birlikte bir supervisor süreci olarak 0.0.0.0:443'te çalışıyor (FrankenPHP sürücüsü, max-requests=500, admin-port=2019).
Cevap
Kısa cevap: Evet, teknik olarak sağlam bir desen — ama ben olsam sizin yerinizde mevcut kurulumunuzda kalırdım.
Kısa cevap
Cloudflare’in Zero Trust tarafı da private bir origin’i internete hiç açmadan tünel üzerinden yayınlamayı zaten bu şekilde öneriyor. Sizin senaryonuzda uygulama 127.0.0.1:8080’de çalışır, cloudflared tüneli isteği oraya taşır; 443 hiçbir zaman internete çıkmamış olur ve SSL yönetimi tamamen Cloudflare’e devredilir. Yine de “kurdum, gerisi gelir” diyebileceğiniz bir şey değil — bilmeniz ve kabul etmeniz gereken birkaç nokta var. Cloudflare’e ne kadarını devrettiğinizin diğer yüzünü, edge tarafındaki cache ve invalidation kararlarını konuştuğumuz Workers KV kaydında ele almıştım.
Neden
- Tek yol Cloudflare olur. Tünel açıldığında origin’e tek giriş kapısı Cloudflare’dir; bir CF kesintisinde devreye girecek bir fallback’in olmaz. Bu bağımlılığı bilerek almalısınız.
- Cloudflare’in zaman aşımı sınırları tünelde de geçerli. Edge’deki request timeout tünelden geçen isteklere de uygulanır; tünel ayrıca kendi origin-taraflı zaman aşımlarını (connectTimeout, tlsTimeout, keepAliveTimeout) ekler. Uzun süren işleri senkron tutmayın, queue’ya alın.
- Gerçek istemci IP’si bir katman daha uzaklaşır. Loopback’e inen bir istekte kaynağı yalnızca proxy başlıklarından okuyabilirsiniz; bu da uygulama tarafında ek bir güven ayarı gerektirir.
Ne yapmalı
- Süreci düzgün yönetin. Tünel istemcisini (
cloudflared) systemd altındaautorestartaçık şekilde çalıştırın. Aynı tünel token’ı ile iki replica koşturarak kesintisizliği artırabilirsiniz — ama bu artık bir ölçekleme konusu, başlangıçta gerekmez. - Uygulamayı asla
0.0.0.0’a bind etmeyin. Tünel modelinde uygulamanın yalnızca loopback’ten (127.0.0.1:8080) erişilebilir olması gerekir; dışarıya açık bir port kalmamalı. Şu anki supervisor konfigürasyonundaki--host=0.0.0.0 --port=443tam da bu yüzden değişmeli. - Trusted proxy’leri mutlaka ayarlayın. Laravel’in
TrustProxiesayarını yapmazsanız tüm istekler loopback’ten geliyormuş gibi görünür; gerçek istemci IP’sini kaybedersiniz; rate limit’ler ve loglar bozulur.
Sonuç: Tek yol bağımlılığını ve kesintisizliği Cloudflare’in HA’sına emanet etmeyi göze alıyorsanız, tünel en temiz çözüm. Ama ben olsam sizin mevcut Cloudflare → Caddy → App kurulumunuzda kalıp, origin’i bir Security Group kuralıyla yalnızca Cloudflare IP aralıklarına kilitler ve buna authenticated origin pulls eklerdim — bu, 443’ü efektif olarak dışarıya kapatırken tek-yol bağımlılığına girmediğiniz için daha esnek olur.
İlgili Yazılar
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.