İçeriğe geç
Muhammet Şafak
en
Soran: Gazi Cevaplandı:

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, bu sağlam bir desen. Cloudflare’in Zero Trust tarafı da private bir origin’i internete hiç açmadan tünel üzerinden yayınlamayı zaten bu şekilde öneriyor. Senin senaryonda 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ğin bir şey değil — bilmen ve kabul etmen gereken birkaç nokta var.

Kabul etmen gerekenler:

  1. 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.
  2. Süreci düzgün yönet. Tünel istemcisini (cloudflared) systemd altında autorestart açık şekilde çalıştır. Aynı tünel token’ı ile iki replica koşturarak kesintisizliği artırabilirsin — ama bu artık bir ölçekleme konusu, başlangıçta gerekmez.
  3. Uygulamayı asla 0.0.0.0’a bind etme. 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ündeki --host=0.0.0.0 --port=443 tam da bu yüzden değişmeli.
  4. Cloudflare’in zaman aşımı ve limitleri tünelde de geçerli. Edge’deki request timeout ve boyut limitleri tünelden geçen isteklere de uygulanır; uzun süren işleri senkron tutma, queue’ya al.
  5. Trusted proxy’leri mutlaka ayarla. Laravel’in TrustProxies ayarını yapmazsan tüm istekler loopback’ten geliyormuş gibi görünür; gerçek istemci IP’sini kaybedersin, 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, tünel en temiz çözüm. Ama ben olsam senin mevcut Cloudflare → Caddy → App kurulumunda 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ğin için daha esnek olur.

İlgili Yazılar

Etiketler: #altyapı#cloudflare#laravel
Paylaş:

Yorumlar

Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.

Diğer Sorular

Tüm sorular
Bora

Fintek API'ı için Canary mi, Blue-Green deployment mı?

Rutin sürümlerde Canary'yi varsayılan yap (en küçük blast radius), instant rollback istediğin büyük cutover'lar için Blue-Green'i sakla. Asıl kilit nokta veritabanı: her iki strateji de geriye uyumlu (expand/contract) şema değişikliği şart koşar.

#ci-cd#deploy#dayanıklılık

Sitede Ara

Yazı, proje ve sayfalarda arama yapmak için yazmaya başlayın.

Esc ile kapat Pagefind ile güçlendirildi