Cloudflare Workers ile Edge’de JSON API Oluşturma ve JWT Doğrulama (Adım Adım)

Edge tarafında API fikri neden bu kadar popüler?

Klasik yaklaşımda bir JSON API’yi bir sunucuda (VPS, container, PaaS) çalıştırır, ölçekleme ve gecikme sorunlarını ayrı ayrı yönetirsiniz. Cloudflare Workers ise kodunuzu kullanıcıya daha yakın “edge” noktalarında çalıştırarak düşük gecikme, otomatik ölçeklenme ve yönetim kolaylığı sunar. Bu yazıda, güncel ve ileri seviye bir senaryo olarak Cloudflare Workers ile minimal bir JSON API kuracak, ardından JWT doğrulama ekleyerek endpoint’leri koruma altına alacağız.

Ön koşullar

Bu öğretici için bir Cloudflare hesabı, Node.js (tercihen LTS) ve Cloudflare’ın CLI aracı Wrangler gerekli. Ayrıca JWT üretmek için bir kimlik sağlayıcı (Auth0, Firebase, Keycloak vb.) kullanabilirsiniz; ancak burada doğrulama kısmını Workers üzerinde ele alacağız. Amaç, “Authorization: Bearer ...” başlığıyla gelen token’ı doğrulayıp yetkisiz istekleri reddetmek.

1) Projeyi oluşturma (Wrangler)

Yerel ortamda yeni bir Worker projesi başlatın. Wrangler, TypeScript ve modern Worker runtime’ı ile hızlı bir iskelet oluşturur. Terminalde proje klasörünü oluşturduktan sonra geliştirme sunucusunu ayağa kaldırarak endpoint’leri test edebilirsiniz. Buradaki kritik nokta: Worker kodu Node.js sunucusu gibi “stateful” değildir; tasarımınızı stateless düşünmek daha doğru sonuç verir.

2) JSON API: Basit bir route yapısı

Workers ortamında istekleri fetch handler’ı ile karşılarız. Birkaç route ile başlayalım: /health (servis kontrolü), /api/profile (JWT gerektiren örnek endpoint). Aşağıdaki örnek, JSON cevapları standartlaştırmak için küçük yardımcı fonksiyonlar kullanır.

Örnek Worker kodu (TypeScript mantığı):

Not: Kod örneğini kendi projenize göre uyarlayın; özellikle JWT doğrulama için kullanacağınız public key veya JWKS adresi değişecektir.

Route mantığı: /health herkese açık, /api/profile ise Bearer token ister. Token doğrulanırsa örnek bir profil JSON’u döner.

3) JWT doğrulama: HS256 yerine RS256/JWKS yaklaşımı

Güncel pratikte JWT doğrulamada iki ana yol var: paylaşılan gizli anahtar (HS256) veya asimetrik anahtar (RS256/ES256). Üretim ortamında, özellikle üçüncü parti kimlik sağlayıcıları ile, JWKS (JSON Web Key Set) üzerinden public key çekip doğrulama yapmak daha sürdürülebilir bir yöntemdir. Böylece anahtar rotasyonu kimlik sağlayıcı tarafında yönetilir ve Worker sadece güncel anahtarı kullanır.

Workers içinde JWKS kullanırken iki konu önem kazanır: cache ve performans. Her istekte JWKS çekmek gecikmeyi artırır. Bu yüzden JWKS yanıtını belirli bir süre cache’lemek gerekir. Cloudflare Workers, Cache API ile bu işi oldukça pratik hale getirir. Alternatif olarak KV ya da D1 gibi çözümler de kullanılabilir, fakat JWKS için Cache API genellikle yeterlidir.

4) Güvenlik kontrol listesi (pratik öneriler)

Audience (aud) ve issuer (iss) doğrulaması yapın. Sadece imza doğrulamak yetmez; token’ın kimin için üretildiğini ve hangi otorite tarafından imzalandığını da kontrol etmek gerekir. Ayrıca token süresi için exp kontrolü zorunludur. Saat kayması ihtimaline karşı küçük bir tolerans (clock skew) eklemek sahada hataları azaltır.

CORS konusu da sık atlanır. API’niz tarayıcıdan çağrılacaksa doğru origin’leri whitelist ederek “*” kullanımını sınırlayın. Workers, preflight (OPTIONS) isteklerini yönetmek için idealdir. Ek olarak rate limit için Cloudflare’ın WAF ve Rate Limiting özellikleri veya uygulama seviyesinde basit limit mekanizmaları kullanılabilir.

5) Deploy ve test

Geliştirme tamamlanınca Wrangler ile deploy alırsınız. Ardından uç noktaları curl veya Postman ile test edin. İlk test olarak /health çağrısının 200 dönmesi beklenir. Sonra /api/profile’a token olmadan istek atarak 401 aldığınızı doğrulayın. Son adımda geçerli bir JWT ile çağrı yapıp JSON yanıtı alın. Hata durumlarında özellikle Authorization header formatı (Bearer boşluk) ve token’ın doğru issuer/audience değerleri kontrol edilmelidir.

Sık karşılaşılan hatalar ve çözüm ipuçları

“Invalid signature”: Yanlış public key, yanlış JWKS endpoint’i veya token’ın farklı bir kid ile imzalanması. JWKS’ten doğru anahtarı seçtiğinizden emin olun. “Token expired”: exp geçmiş olabilir; sistem saatini ve clock skew toleransını gözden geçirin. CORS hataları: OPTIONS isteklerine 200 dönmeyi ve gerekli Access-Control-Allow-* başlıklarını eklemeyi unutmayın.

Sonuç: Neyi kazandınız?

Bu rehberle Cloudflare Workers üzerinde edge’de çalışan, gecikmesi düşük ve otomatik ölçeklenen bir JSON API kurmanın mantığını kurdunuz. Üstüne JWT doğrulama ekleyerek gerçek hayattaki “korumalı endpoint” ihtiyacını da çözdünüz. Buradan sonra loglama için Workers Analytics, veri katmanı için D1/KV, daha gelişmiş yetkilendirme için role-based kontrol ve rate limiting gibi adımlarla mimariyi büyütebilirsiniz.

Docker Compose ile Yerel LLM (Ollama) Kurulumu ve Open WebUI Üzerinden ChatGPT Benzeri Arayüz

Yerelde LLM Çalıştırmak Neden Gündemde?

Bulut tabanlı yapay zekâ servisleri pratik olsa da, veri gizliliği, maliyet ve gecikme (latency) gibi konular birçok kişiyi yerel (local) çözümlere yönlendiriyor. Son dönemde öne çıkan yaklaşımlardan biri, LLM modellerini bilgisayarında veya ev sunucunda çalıştırıp, web arayüzü üzerinden sohbet edebilmek. Bu yazıda, Ollama ile yerel model çalıştırmayı ve Open WebUI ile tarayıcıdan kullanmayı Docker Compose üzerinden adım adım kuracağız. Hedefimiz: birkaç komutla, sürdürülebilir ve güncellenebilir bir kurulum yapmak.

Ön Koşullar ve Sistem Notları

Kurulum Linux tabanlı bir sistemde (Ubuntu/Debian gibi) en sorunsuz şekilde ilerler. macOS ve Windows üzerinde de Docker ile yapılabilir; ancak GPU kullanımı (özellikle NVIDIA) için Linux tarafı daha stabil. Minimumda 8 GB RAM ile küçük modeller çalıştırılabilir; 16 GB ve üzeri daha rahat olur. GPU’nuz varsa performans belirgin şekilde artar. Gerekenler: Docker, Docker Compose ve internete erişim (modeli ilk kez indirirken).

Mimari: Ollama + Open WebUI Nasıl Çalışır?

Ollama, LLM modellerini indirip yerelde servis eden bir katman gibi düşünülebilir. Siz “modeli indir, çalıştır” dersiniz; o da arka tarafta bir API üzerinden yanıt üretir. Open WebUI ise bu API’ye bağlanan modern bir web arayüzüdür. Böylece tarayıcıdan sohbet edebilir, model seçebilir, geçmiş konuşmaları saklayabilir ve temel ayarları yönetebilirsiniz. İkisini Docker Compose ile yönetmek, güncelleme ve taşınabilirlik açısından büyük kolaylık sağlar.

Adım 1: Docker Compose Dosyasını Oluşturma

Önce bir klasör açın ve içine docker-compose.yml dosyası oluşturun. Örnek içerik aşağıdaki gibi olabilir. Bu yapı iki servisi çalıştırır: Ollama ve Open WebUI. Open WebUI, Ollama’nın API’sine bağlanır ve 3000 portundan yayın yapar.

docker-compose.yml:

version: "3.8"
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama

  openwebui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: openwebui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama
    volumes:
      - openwebui:/app/backend/data

volumes:
  ollama:
  openwebui:

Not: Bu örnek temel kurulumdur. NVIDIA GPU ile hızlandırma isterseniz Docker’ın GPU runtime ayarlarını ayrıca yapılandırmanız gerekebilir. CPU ile de çalışır; sadece daha yavaş yanıt alırsınız.

Adım 2: Servisleri Ayağa Kaldırma

Compose dosyasının bulunduğu klasörde şu komutu çalıştırın:

docker compose up -d

Ardından konteynerlerin durumunu kontrol edin:

docker ps

Her şey yolundaysa tarayıcıdan http://localhost:3000 adresine gidin. İlk açılışta Open WebUI sizden bir kullanıcı oluşturmanızı isteyebilir; bu normaldir.

Adım 3: Model İndirme ve İlk Çalıştırma

Ollama tarafında bir model indirmek için iki yol var: Open WebUI içinden model çekmek veya terminalden indirmek. Terminal üzerinden daha kontrol edilebilir olduğu için şu komutla başlayabilirsiniz:

docker exec -it ollama ollama pull llama3.1

Model adı zamanla değişebilir; Ollama’nın desteklediği güncel isimleri kontrol etmek gerekebilir. İndirme bittiğinde Open WebUI’ye dönün. Model seçimi bölümünde indirdiğiniz modeli görüp sohbet başlatabilirsiniz. İlk yanıtlar biraz yavaş gelebilir; modelin “ısınması” ve CPU/GPU durumuna göre performans değişir.

İpuçları: Performans, Depolama ve Güvenlik

Depolama: Modeller büyük yer kaplar. Compose dosyasında tanımlı volume’lar sayesinde konteyner silinse bile modelleriniz kalır. Disk alanınızı izlemek için düzenli kontrol edin.

Performans: Daha küçük bir model seçmek (ör. daha düşük parametreli sürümler) yanıt süresini ciddi biçimde iyileştirir. Ayrıca aynı anda çok uzun bağlam (context) kullanmak RAM tüketimini artırır.

Güvenlik: Kurulumu ev ağı dışına açacaksanız (port yönlendirme gibi), mutlaka ters proxy + HTTPS ve kimlik doğrulama kullanın. Varsayılan şekilde yerelde kullanmak daha güvenlidir.

Sık Karşılaşılan Sorunlar

Open WebUI model görmüyor: OLLAMA_BASE_URL değişkeninin doğru olduğundan emin olun. Compose içinde servis adı “ollama” ise URL de “http://ollama:11434” olmalı. Ayrıca konteynerlerin aynı network’te olması gerekir; Compose bunu varsayılan olarak sağlar.

Yanıtlar çok yavaş: CPU ile çalışıyorsanız bu normal olabilir. Daha küçük model deneyin, arka planda çalışan uygulamaları azaltın. GPU kurulumuna geçmek ciddi fark yaratır.

Port çakışması: 3000 veya 11434 portu başka bir uygulama tarafından kullanılıyorsa, compose dosyasında sol taraftaki portu değiştirin (ör. “3001:8080”).

Sonuç

Docker Compose ile Ollama ve Open WebUI kurmak, yerel LLM dünyasına hızlı bir giriş sunuyor. Kurulum hem taşınabilir hem de güncellemesi kolay: yeni sürümler için genellikle docker compose pull ve docker compose up -d yeterli. En önemlisi, sohbet veriniz ve model kullanımı sizin kontrolünüzde kalıyor. Eğer hedefiniz gizlilik odaklı bir “yerel yapay zekâ asistanı” ise bu ikili, güncel ve pratik bir başlangıç noktası.

Docker’da Rootless Mod ile Güvenli Konteyner Çalıştırma: Adım Adım Kurulum ve İpuçları

Rootless Docker Nedir ve Neden Önemlidir?

Konteyner teknolojileri üretim ortamlarında standart hâline gelirken, güvenlik tarafında hâlâ sık yapılan bir hata var: Docker’ı kök kullanıcı (root) yetkileriyle çalıştırmak. Varsayılan Docker kurulumunda dockerd servisi root ayrıcalıklarıyla çalışır ve Docker grubuna eklediğiniz kullanıcılar fiilen root’a yakın yetkiler kazanır. Bu, yanlış yapılandırılmış bir konteyner veya zayıf bir imaj üzerinden sistemin tamamına sıçrama riskini artırır.

İşte burada Rootless Docker devreye girer. Rootless mod, Docker daemon’ını ve konteynerleri root olmadan çalıştırır. Böylece olası bir güvenlik açığında saldırganın erişimi kullanıcı alanıyla sınırlı kalır. Özellikle çok kullanıcılı sunucularda, CI/CD ajanlarında veya geliştiricilerin kendi makinelerinde güvenliği artırmak için oldukça iyi bir yaklaşımdır.

Kimler Rootless Docker Kullanmalı?

Rootless mod her senaryoya birebir uymaz; ancak pek çok kullanımda ciddi avantaj sağlar. Paylaşımlı geliştirme sunucuları, kurumsal dizüstüler, “konteyner çalıştırıyorum ama root yetkisi istemiyorum” yaklaşımı olan ekipler ve saldırı yüzeyini küçültmek isteyenler için idealdir. Öte yandan bazı ağ senaryolarında (örneğin düşük portlara doğrudan bind etmek) ekstra ayar gerekir. Bu yazıda temel kurulumun yanında pratik kısıtları ve çözüm yollarını da ele alacağım.

Ön Koşullar (Linux)

Rootless Docker en sorunsuz şekilde modern Linux dağıtımlarında çalışır. Bu rehberde Ubuntu/Debian çizgisini baz alıyorum; ancak Fedora/Arch tarafında da mantık aynı. Gerekli olanlar: güncel bir Docker kurulumu, kullanıcı bazlı servisleri yönetmek için systemd (çoğu dağıtımda var) ve kullanıcı namespace’lerinin düzgün ayarlanması.

Öncelikle Docker’ın kurulu olduğunu doğrulayın. Kurulu değilse dağıtımınızın resmi yönergelerini izleyin. Rootless mod için ayrıca Docker’ın sunduğu kurulum betiğini kullanacağız.

Adım Adım Rootless Docker Kurulumu

1) Kullanıcı namespace eşlemelerini kontrol edin
Rootless çalışabilmek için sistemde subuid ve subgid atamaları gerekir. Çoğu sistemde otomatik gelir; ancak kontrol etmekte fayda var. Aşağıdaki dosyalarda kullanıcı adınıza ait satır olmalı:

/etc/subuid ve /etc/subgid içinde kullanıcı adınızın karşısında bir aralık görmelisiniz (ör. kullanici:100000:65536). Yoksa yönetici yetkisiyle bu aralığı tanımlamak gerekir.

2) Rootless kurulum betiğini çalıştırın
Docker, rootless kurulumu kolaylaştıran bir betik sunar. Terminalde kendi kullanıcınızla şu komutu çalıştırın:

dockerd-rootless-setuptool.sh install

Kurulum sonunda size iki kritik bilgi verir: Docker soketinin yolu ve ortam değişkenleri. Genellikle DOCKER_HOST için kullanıcı dizini altında bir socket yolu tanımlanır.

3) Ortam değişkenlerini kalıcı hâle getirin
Terminal her açıldığında rootless daemon’a bağlanmak için genelde şu satır gerekir:

export DOCKER_HOST=unix:///run/user/1000/docker.sock

Kendi kullanıcı ID’nize göre yol değişebilir. Bunu ~/.bashrc veya ~/.zshrc dosyanıza ekleyin. Ardından yeni bir terminal açıp docker ps ile test edin.

4) Servisi kullanıcı olarak başlatın
Systemd kullanan sistemlerde rootless Docker genellikle kullanıcı servisi olarak yönetilir. Kurulum betiği çoğu zaman bunu ayarlar. Elle kontrol etmek isterseniz:

systemctl --user status docker

Servis aktif değilse başlatıp etkinleştirebilirsiniz:

systemctl --user enable --now docker

Sık Karşılaşılan Kısıtlar ve Pratik Çözümler

1) 1024 altı portlara bind etme
Rootless modda düşük portlara (80, 443 gibi) doğrudan bind etmek kısıtlıdır. Çözüm olarak 8080/8443 gibi yüksek portları kullanabilir, ters vekil (reverse proxy) ile yönlendirebilir veya sistemde ilgili capability ayarlarıyla çalışabilirsiniz. Üretimde en temiz yaklaşım genellikle Nginx/Traefik gibi bir ters vekilin 80/443’ü dinlemesi ve konteynerlere yüksek porttan trafik iletmesidir.

2) Ağ performansı ve uyumluluk
Rootless, ağ tarafında çoğunlukla kullanıcı alanı çözümlerine dayanır. Bu, bazı ortamlarda küçük bir performans maliyeti veya farklı davranışlar doğurabilir. Ancak geliştirici makinelerinde ve birçok CI işinde bu fark pratikte sorun yaratmaz.

3) Dosya izinleri ve bind mount
Konteyner içine bağladığınız (bind mount) dizinlerde izin problemleri görebilirsiniz. Rootless mod, host tarafındaki kullanıcı izinleriyle daha “doğal” çalışır; yine de UID/GID uyumsuzluğu olan imajlarda ek ayar gerekebilir. Bu noktada user direktifini kullanmak, uygulamayı konteyner içinde root yerine belirli bir kullanıcıyla çalıştırmak ve volume izinlerini netleştirmek işleri kolaylaştırır.

Güvenlik İçin Ek İpuçları

Rootless kullanıyor olsanız bile güvenlik katmanlarını çoğaltmak iyi bir alışkanlıktır. İmajları mümkünse resmi kaynaklardan çekin, gereksiz paketleri içermeyen minimal imajları tercih edin, gizli anahtarları imaj içine gömmeyin. Konteyner çalıştırırken read-only dosya sistemi, sınırlı yetkiler ve kaynak kotaları gibi seçenekler de saldırı yüzeyini küçültür.

Son olarak, rootless Docker’ı “tek başına her şeyi çözen” bir sihir gibi görmek yerine, doğru senaryoda güçlü bir güvenlik hamlesi olarak değerlendirin. Özellikle paylaşımlı sistemlerde, geliştirici ortamlarında ve otomasyon sunucularında rootless yaklaşımı çoğu zaman daha rahat uyumanızı sağlar.

Sonuç

Rootless Docker, konteyner ekosisteminde güvenliği pratik biçimde artıran modern bir yöntem. Kurulumu birkaç adımda tamamlanıyor; en önemli nokta kullanıcı namespace eşlemeleri ve doğru DOCKER_HOST ayarı. Eğer bugüne kadar Docker’ı “Docker grubuna al, tamam” mantığıyla kullanıyorsanız, rootless moda geçmek özellikle güvenlik hassasiyeti olan ortamlarda ciddi bir iyileştirme sunar.

Proxmox Ubuntu Master Template Hazırlık Rehberi V2

Proxmox Ubuntu Master Template Hazırlık Rehberi V2

Bu rehberde, Proxmox üzerinde saniyeler içinde yeni makineler oluşturabilmek için optimize edilmiş, her şeyiyle hazır bir Ubuntu Altın Şablon (Master Template) oluşturmayı öğreneceğiz.

1. Sistem Güncelleme ve Temel Araçlar

Sistemi güncel tutmak ve yönetim araçlarını yüklemek ilk adımımız:

# Sistem güncelleme
sudo apt update && sudo apt upgrade -y

# Temel araçları (İsviçre Çakısı) yükle
sudo apt install -y curl wget vim net-tools htop tree unzip git software-properties-common bash-completion

2. Bağlantı ve Güvenlik Ayarları

SSH erişimini garantilemek ve Firewall engellerini kaldırmak için:

# SSH kurulumu ve aktif edilmesi
sudo apt install openssh-server -y
sudo systemctl enable --now ssh

# UFW Güvenlik Duvarını kapatma ve maskeleme
sudo ufw disable
sudo systemctl mask ufw

3. Proxmox Entegrasyonu ve Saat Ayarı

Proxmox paneli üzerinden makineyi yönetebilmek için QEMU Guest Agent kritiktir:

# QEMU Guest Agent kurulumu
sudo apt install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

# Zaman dilimi ayarı (Türkiye)
sudo timedatectl set-timezone Europe/Istanbul

4. Kritik Adım: Machine-ID Sıfırlama

Klonlanan makinelerin ağda aynı IP'yi alıp çakışmaması için benzersiz kimliği temizliyoruz:

sudo truncate -s 0 /etc/machine-id
sudo rm /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id

5. Final: Mühürleme ve Template Dönüşümü

Makineyi kapatıp şablona dönüştürmeden önceki son temizlik:

# Temizlik ve Kapatma
sudo apt autoremove -y && sudo apt clean
history -c && history -w
sudo poweroff

Son Adım: Proxmox arayüzünde makineye sağ tıklayın ve "Convert to Template" seçeneğini seçin. Artık bu şablondan "Linked Clone" oluşturarak saniyeler içinde yeni Ubuntu sunucuları ayağa kaldırabilirsiniz!

Son olarak yeni bir makine ayağa kaldırıldığında yapılması gereken adımlar sadece bunlardır: 

Hostname'in değiştirilmesi : sudo hostnamectl set-hostname newname

Yeni IP adresinin verilmesi: sudo vi /etc/netplan/50-cloud-init.yaml

sudo netplan apply

Kontrol amaçlı: cat /etc/machine-id veya sadece hostnamectl çalıştırılır.

TPM 2.0 ile Windows 11’de BitLocker Kurulumu: USB Olmadan Kurtarma Anahtarı ve Güvenli Yedekleme Rehberi

BitLocker nedir ve neden şimdi daha önemli?

Dizüstü bilgisayarlar kayboluyor, SSD’ler sökülüp başka bir cihaza takılabiliyor ve fidye yazılımları kurumsal olmayan kullanıcılara kadar indi. Bu tabloda “dosya şifreleme” artık lüks değil, temel güvenlik katmanı. Windows 11 ile birlikte TPM 2.0 şartının yaygınlaşması da BitLocker’ı daha erişilebilir hâle getirdi. BitLocker; diskinizi (özellikle sistem sürücüsünü) tam disk şifreleme ile korur, böylece cihazınız ele geçirilse bile içindeki veriler okunamaz.

Bu yazıda, Windows 11’de TPM 2.0 destekli bir cihazda BitLocker’ı USB anahtar gerektirmeden kurmayı, kurtarma anahtarını doğru şekilde saklamayı ve olası kilitlenme senaryolarına karşı hazırlık yapmayı adım adım anlatacağım. Anlatım, hem bireysel kullanıcılar hem de küçük ofis/uzaktan çalışanlar için pratik olacak şekilde tasarlandı.

Ön koşullar: TPM, sürüm ve dosya sistemi kontrolü

1) Windows sürümü: BitLocker, Windows 11 Pro, Enterprise ve Education sürümlerinde yerleşik gelir. Home sürümünde cihaz şifreleme (Device Encryption) bulunabilir ama BitLocker yönetimi aynı değildir. Ayarlar > Sistem > Hakkında bölümünden sürümünüzü kontrol edin.

2) TPM 2.0 kontrolü: Win + R tuşlarına basın, tpm.msc yazıp çalıştırın. “TPM kullanıma hazır” ve sürüm kısmında 2.0 görmelisiniz. Eğer görünmüyorsa BIOS/UEFI’de TPM (Intel PTT / AMD fTPM) kapalı olabilir.

3) Disk düzeni: BitLocker sistem sürücüsünde en sorunsuz şekilde GPT + UEFI kurulumlarda çalışır. Yine de MBR/Legacy senaryolarda da kullanılabilir; ancak modern cihazlarda UEFI açık olduğu için genellikle sorun çıkmaz. Dosya sistemi çoğunlukla NTFS olmalıdır.

BitLocker’ı etkinleştirme: Denetim Masası yöntemi

Adım 1: Başlat menüsünde “BitLocker” aratın ve BitLocker Sürücü Şifrelemesini Yönet seçeneğini açın. Alternatif: Denetim Masası > Sistem ve Güvenlik > BitLocker Sürücü Şifreleme.

Adım 2: Sistem sürücüsü (genelde C:) yanında BitLocker’ı Aç seçeneğine tıklayın. TPM uygunsa Windows, açılışta ekstra bir USB anahtar istemeden şifreleme yapabilir. Bazı kurulumlarda “BitLocker kurtarma anahtarı oluşturuluyor” ekranı görürsünüz; bu normaldir.

Adım 3 (Kurtarma anahtarı): En kritik kısım burası. Size 48 haneli bir Kurtarma Anahtarı (Recovery Key) verilir. Bunu saklamak için genellikle şu seçenekler sunulur: Microsoft hesabına kaydet, dosyaya kaydet veya yazdır. Güvenli bir yaklaşım olarak iki farklı yöntem kullanın: 1) Microsoft hesabına kaydedin, 2) offline bir yerde yazılı kopya tutun. Dosyaya kaydetme seçeneğini kullanacaksanız, aynı bilgisayarın C: sürücüsüne kaydetmeyin; harici disk veya güvenli kurumsal depolama tercih edin.

Adım 4 (Şifreleme modu): “Kullanılan disk alanını şifrele” seçeneği yeni bilgisayarlarda daha hızlıdır; “Tüm sürücüyü şifrele” ise uzun sürer ama daha kapsamlıdır (özellikle önceden kullanılmış disklerde). Ev kullanıcıları için genellikle Kullanılan alan yeterlidir; ikinci el/kurumsal senaryoda Tüm sürücü daha güvenlidir.

Adım 5 (Şifreleme algoritması): Windows 11’de çoğunlukla XTS-AES önerilir. Varsayılan değerleri değiştirmediğinizde genellikle iyi bir denge sağlanır. “Bu sürücüyü başka Windows sürümleriyle kullanacağım” gibi özel bir ihtiyacınız yoksa önerilen ayarlarla devam edin.

Adım 6: “BitLocker sistem denetimi çalıştırılsın” seçeneğini açık bırakın ve yeniden başlatın. Cihaz açılıp kapanırken kısa bir doğrulama yapar. Ardından arka planda şifreleme başlar; performans etkisi SSD’li sistemlerde çoğu zaman hissedilmez.

Komut satırıyla doğrulama: manage-bde ile kontrol

Kurulum sonrası durum kontrolü için Yönetici olarak Komut İstemi açıp şu komutu kullanabilirsiniz: manage-bde -status. Burada “Conversion Status” kısmında şifreleme yüzdesini, “Protection Status” kısmında korumanın aktif olup olmadığını görürsünüz. Bu kontrol, özellikle kurumsal cihazlarda “BitLocker açık mı?” sorusuna net cevap verir.

Kurtarma anahtarını kaybetmemek için pratik öneriler

BitLocker’ın en sık yaşanan problemi “şifreleme” değil, kurtarma anahtarının kaybolmasıdır. BIOS güncellemesi, TPM sıfırlaması, anakart değişimi, bazı UEFI ayarları veya beklenmeyen boot sorunları kurtarma ekranını tetikleyebilir. Bu yüzden şu üç kuralı uygulayın: (1) Kurtarma anahtarını en az iki farklı yerde saklayın, (2) Anahtarı aynı cihaz üzerinde tutmayın, (3) Kurumsal ortamdaysanız Azure AD/AD DS politikalarıyla merkezi yedekleme kullanın.

Microsoft hesabına kaydettiyseniz, hesabınıza giriş yaparak cihazınızın kurtarma anahtarlarını görebilirsiniz. Kurum hesabı kullanılıyorsa, BT yöneticiniz anahtarı envanterde tutuyor olabilir. Bu adımı atlamayın; BitLocker “iyi çalıştığı için” görünmezdir, ama kurtarma anında tek can simidi bu anahtardır.

Performans ve günlük kullanım: Kısa bir değerlendirme

Modern işlemcilerde donanımsal hızlandırma sayesinde BitLocker, günlük kullanımda ciddi bir yavaşlama yaratmaz. En çok hissedilen etki, çok büyük dosya kopyalamalarında ve ilk şifreleme sürecinde olabilir. SSD’li Windows 11 cihazlarda çoğu kullanıcı için fark edilebilir bir gecikme yaşanmaz. Asıl kazanç ise cihaz kaybı, hırsızlık veya disk sökülmesi gibi senaryolarda verinin okunamaz kalmasıdır.

Sonuç olarak TPM 2.0’lı bir Windows 11 cihazda BitLocker kurmak, birkaç dakikalık ayarla yıllarca sürecek bir güvenlik katmanı ekler. En önemli adım, kurtarma anahtarını doğru saklamaktır. Kurulumu tamamladıktan sonra manage-bde ile durum kontrolü yapın ve anahtarınızı iki kanalda yedeklediğinizden emin olun.

Evde DNS Üzerinden Reklam ve İzleyici Engelleme: Pi-hole’u Docker ile 30 Dakikada Kurma Rehberi

Pi-hole Nedir ve Neden DNS Seviyesinde Engelleme?

Reklam engelleyiciler genellikle tarayıcı eklentisi olarak çalışır ve sadece o tarayıcıyı etkiler. Pi-hole ise DNS seviyesinde filtreleme yaparak ev ağınızdaki telefon, tablet, akıllı TV, oyun konsolu gibi tüm cihazlarda reklam ve takip alanlarını engelleyebilir. Yani bir uygulamanın içine gömülü reklam çağrıları da, tarayıcı dışındaki izleme servisleri de büyük ölçüde kesilir. Bu yaklaşım, özellikle “her cihazda tek tek eklenti kurmakla uğraşmak istemiyorum” diyenler için oldukça temiz bir çözümdür.

Bu rehberde Pi-hole’u bir Raspberry Pi zorunluluğu olmadan, herhangi bir Linux makinede (mini PC, NAS, eski laptop veya bir VPS değil; tercihen ev içi cihaz) Docker ile kuracağız. Docker sayesinde güncelleme, yedekleme ve taşınabilirlik daha kolay olur. Ayrıca sistemi bozma riskini de azaltır.

Kurulum Öncesi Gereksinimler

Başlamadan önce aşağıdakilere sahip olmanız işinizi kolaylaştırır: Docker ve Docker Compose kurulu bir Linux cihazı, yerel ağda sabit IP (ya router’dan DHCP rezervasyonu ya da cihazda statik IP), ve modem/router arayüzüne erişim. Pi-hole’un stabil çalışması için cihazın mümkün olduğunca 7/24 açık kalması önerilir. Eğer sık kapatıyorsanız, DNS çözümleme sorunları yaşamamak için router’da ikinci bir DNS (örneğin 1.1.1.1) yedek olarak tanımlanabilir; fakat bu, bazı istemcilerin engeli aşmasına neden olabilir.

Docker Compose ile Pi-hole Kurulumu

Önce Pi-hole için bir klasör oluşturun ve içine bir docker-compose.yml dosyası hazırlayın. Klasör yapısı olarak yapılandırma ve DNS servisinin kalıcı verisini saklayacağız. Örnek bir yaklaşım: /opt/pihole altında çalışmak.

1) Klasörleri oluşturun (örnek):

/opt/pihole/etc-pihole ve /opt/pihole/etc-dnsmasq.d klasörlerini oluşturun. Bu klasörler Pi-hole ayarlarının yeniden başlatmalarda kaybolmamasını sağlar.

2) docker-compose.yml içeriği (kendi ağınıza göre uyarlayın):

Önemli: Aşağıdaki ayarlarda TZ zaman dilimi, WEBPASSWORD yönetim paneli şifresi ve volume yolları kritik. Router’ınızın DNS portu 53’ü engellemediğinden emin olun.

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    hostname: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      - TZ=Europe/Istanbul
      - WEBPASSWORD=GucluBirSifreBelirleyin
    volumes:
      - "/opt/pihole/etc-pihole:/etc/pihole"
      - "/opt/pihole/etc-dnsmasq.d:/etc/dnsmasq.d"
    restart: unless-stopped

3) Servisi ayağa kaldırın:

Klasörün içinde docker compose up -d komutunu çalıştırın. Ardından tarayıcıdan http://CIHAZ_IP_ADRESI/admin adresine giderek yönetim panelini açın. Şifrenizi compose dosyasındaki WEBPASSWORD ile belirlediyseniz doğrudan giriş yapabilirsiniz.

Router’da DNS Ayarı: Tüm Ağı Pi-hole’a Yönlendirme

Pi-hole’u “gerçekten etkili” yapan adım, DNS’i cihaz bazında değil ağ genelinde yönlendirmektir. Bunun için modem/router arayüzünde DHCP DNS alanına Pi-hole’un IP adresini girin. Bazı modemlerde “Primary DNS” ve “Secondary DNS” alanları vardır. Maksimum engelleme için ikisini de Pi-hole yapmak ideal olsa da, kesinti toleransı istiyorsanız ikincil DNS’i farklı bir sağlayıcıya vermek zorunda kalabilirsiniz. Bu durumda bazı istemciler ikinci DNS’i kullanarak reklamları çözümleyebilir; bunu azaltmanın yolu router’da dış DNS isteklerini kural ile engelleyip sadece Pi-hole’a izin vermektir (gelişmiş cihazlarda mümkün).

Performans, Gizlilik ve İnce Ayar Önerileri

Kurulumdan sonra yönetim panelinde Query Log bölümünü inceleyin. Burada hangi alan adlarının en çok istek aldığını görürsünüz. Bazı uygulamalar beklenmedik şekilde çok sayıda izleme domain’ine istek atar; Pi-hole bunları görünür kıldığı için aynı zamanda iyi bir “ağ sağlığı” aracıdır.

Engelleme listeleri (adlist) Pi-hole’un bel kemiğidir. Varsayılan listeler çoğu kullanıcı için yeterli olur; fakat daha agresif listeler eklerseniz bazı sitelerde giriş, video oynatma veya yorum bölümleri bozulabilir. Bu noktada Whitelist kullanmak gerekir. Tavsiyem, önce birkaç gün standart ayarlarla izleyip sorun yaşadığınız domain’leri tek tek beyaz listeye almaktır. Böylece “her şeyi engelleyeyim” yaklaşımının getirdiği kırılmaları minimize edersiniz.

İleri seviye bir adım olarak Pi-hole’un yukarı akış DNS’ini (Upstream DNS) seçerken DoH/DoT düşünebilirsiniz. Pi-hole tek başına DoH sunmaz; ancak Unbound gibi yerel bir recursive resolver ile birleştirildiğinde hem gizlilik hem de hız tarafında kazanımlar elde edilir. Yine de başlangıç için Cloudflare, Quad9 veya Google DNS gibi sağlayıcılar yeterli olabilir; önemli olan trafik ve log kontrolünün Pi-hole panelinde toplanmasıdır.

Artılar, Eksiler ve Sonuç

Artılar: Tüm cihazlarda tek noktadan reklam/izleyici engelleme, düşük kaynak tüketimi, kolay yönetim paneli, ağ trafiğine dair görünürlük. Eksiler: DNS altyapınız Pi-hole’a bağımlı hale gelir; cihaz kapanırsa ağda çözümleme sorunları yaşanabilir. Ayrıca bazı bankacılık veya medya servisleri zaman zaman engellemeye takılabilir ve beyaz liste gerekebilir.

Genel olarak Pi-hole’u Docker ile kurmak, ev ağında “sessizce” büyük fark yaratan modern bir iyileştirme. Doğru IP planlaması ve router ayarıyla, 30 dakikada kurulup uzun süre dokunmadan çalışabilen bir çözüm elde edersiniz. Eğer evde çok sayıda cihaz varsa ve özellikle mobil uygulamalardaki izleyiciler can sıkıyorsa, Pi-hole kesinlikle denemeye değer.

Windows 11’de WSL2 ile Docker Desktop’sız Container Çalıştırma (Podman ile İleri Seviye Rehber)

Docker Desktop’sız bir konteyner ortamı mümkün mü?

Windows 11 kullanırken konteyner çalıştırmanın “varsayılan” yolu çoğu kişi için Docker Desktop oluyor. Ancak lisanslama tercihleri, kaynak tüketimi ya da daha yalın bir kurulum isteği nedeniyle alternatif arayanların sayısı arttı. Bu yazıda, WSL2 üzerinde Podman kurarak Docker Desktop olmadan konteyner çalıştırmayı adım adım anlatacağım. Yöntem; geliştiriciler, DevOps meraklıları ve yerel ortamda hızlı test yapanlar için güncel, pratik ve ileri seviye sayılabilecek bir çözüm sunuyor.

Ön koşullar: WSL2 ve Linux dağıtımı

Podman’ı Windows’a doğrudan kurup kullanmak yerine, en stabil deneyimi WSL2 içindeki Linux ortamında alırsınız. Windows 11’de WSL2 genellikle hazır gelir; yine de kontrol etmek için PowerShell’i yönetici olarak açıp aşağıdaki komutu kullanabilirsiniz:

wsl --install

Bu komut, varsayılan bir dağıtım kurabilir. Alternatif olarak Microsoft Store’dan Ubuntu 22.04/24.04 gibi bir sürüm seçmek daha kontrollü olur. Kurulumdan sonra dağıtımı açıp kullanıcı oluşturun ve sistemi güncelleyin:

sudo apt update && sudo apt upgrade -y

Podman kurulumu (Ubuntu)

Ubuntu üzerinde Podman kurulumu oldukça basittir. Depo paketleri çoğu senaryoda yeterli olur:

sudo apt install -y podman

Kurulum tamamlandıktan sonra sürümü doğrulayın:

podman --version

Podman’ın önemli farkı şudur: Docker’daki gibi tek bir “daemon”a bağlı olmak zorunda değildir. Bu yaklaşım hem güvenlik hem de mimari sadelik açısından avantaj sağlar. WSL2 üzerinde de bu sadelik hissedilir.

Rootless çalışma ve temel ayarlar

Podman varsayılan olarak rootless (kök yetkisiz) çalışmaya uygundur. Bu, özellikle yerel geliştirme makinesinde iyi bir güvenlik alışkanlığıdır. Rootless ağ ve port yönlendirme konularında bazı kısıtlar olabilir; güncel Podman sürümleri bunu büyük ölçüde kolaylaştırsa da yine de mantığını bilmek önemlidir.

İlk deneme için basit bir “hello world” çalıştırın:

podman run --rm docker.io/library/hello-world

İmaj çekme (pull) sırasında Docker Hub kullanıyorsanız “docker.io/...” şeklinde açık yazmak, ileride registry karmaşasını azaltır. İsterseniz kısa yol olarak şöyle de çalışır:

podman run --rm hello-world

Docker komutlarına alışkın olanlar için: Podman Docker uyumluluğu

Podman, Docker CLI’ye benzer komutları destekler. Hatta çoğu ekipte geçişi kolaylaştırmak için bir “alias” yaklaşımı kullanılır. Örneğin terminal profilinize şu satırı ekleyebilirsiniz:

alias docker=podman

Bu sayede docker run gibi alışık olduğunuz komutlar, arka planda Podman ile çalışır. Tabii ki bu bir alışkanlık konusu; ben özellikle eğitim ve üretim öncesi testlerde komutun gerçekten Podman olduğunu açık tutmayı tercih ediyorum.

Podman ile web servisi çalıştırma (port yayınlama örneği)

Basit bir Nginx konteyneri çalıştırıp Windows’tan tarayıcıyla erişmek iyi bir testtir. WSL2, Windows ile ağ köprüsü kurabildiği için genellikle sorunsuz çalışır:

podman run -d --name webtest -p 8080:80 docker.io/library/nginx:latest

Ardından Windows’ta tarayıcıdan http://localhost:8080 adresini deneyin. Eğer erişimde sorun yaşarsanız, WSL2’nin bazen IP/localhost yönlendirmesinde farklı davrandığını unutmayın. Bu durumda WSL içinden ip addr ile dağıtımın IP’sini kontrol edip o IP üzerinden erişmeyi deneyebilirsiniz.

Podman Compose: Docker Compose alternatifi

Çoklu servis senaryolarında Compose benzeri bir araca ihtiyaç doğar. Podman ekosisteminde bunun karşılığı çoğu zaman podman-compose olur. Ubuntu’da şu şekilde kurabilirsiniz:

sudo apt install -y podman-compose

Ardından proje klasörünüzdeki docker-compose.yml (adı böyle kalabilir) dosyasını şu komutla çalıştırabilirsiniz:

podman-compose up -d

Her Compose dosyası birebir uyumlu olmayabilir; özellikle ağ sürücüleri, volume sürücüleri veya bazı özel Docker özellikleri kullanılıyorsa küçük uyarlamalar gerekebilir. Yine de tipik web+db gibi senaryolarda oldukça tatmin edici sonuç verir.

İmaj yönetimi ve temizlik: Disk alanını kontrol altında tutma

Konteyner dünyasında zamanla biriken imaj katmanları disk tüketimini artırır. Podman’da temel temizlik için şu komutlar işinizi görür:

podman images

podman ps -a

podman system prune -a

Özellikle WSL2 disk imajı büyüyebildiği için arada bir “prune” yapmak iyi bir alışkanlık. Ancak system prune -a kullanılmayan imajları da sileceğinden, sık kullandığınız baz imajların tekrar indirileceğini hesaba katın.

Ne zaman Podman, ne zaman Docker Desktop?

Podman’ın WSL2 üzerinde Docker Desktop’sız çalışması; hafiflik, esneklik ve açık bir mimari isteyenler için güçlü bir seçenek. Buna karşın bazı ekipler Docker Desktop’ın GUI araçlarını, Kubernetes entegrasyonunu veya kurumsal standartlarını tercih edebilir. Benim önerim şu: Yerel geliştirmede hızlı, sade ve script odaklı bir akış istiyorsanız Podman’ı mutlaka deneyin; kurumsal ekip standartlarınız Docker Desktop ise yine de Podman’ı alternatif olarak elinizin altında tutun.

Bu rehberdeki adımlarla Windows 11 üzerinde WSL2 tabanlı, güncel ve ileri seviye sayılabilecek bir konteyner geliştirme ortamını Docker Desktop olmadan kurmuş oldunuz. Bir sonraki adım olarak, CI süreçlerinizde Podman ile imaj build edip registry’ye push etmeyi ve rootless güvenlik ayarlarını derinleştirmeyi düşünebilirsiniz.

Proxmox ve Ubuntu Laboratuvar Kurulum Rehberi (Uçtan Uca)

A'dan Z'ye Proxmox & Ubuntu Sanallaştırma Laboratuvarı

Bu rehber, fiziksel sunucunun Wi-Fi ile internete bağlanmasından, izole ağ yapılandırmasına ve sanal makinelerin benzersizleştirilmesine kadar tüm teknik adımları içerir.

1. Proxmox Host: Wi-Fi ve İnternet Erişimi (CLI)

Sunucuyu kablosuz ağ üzerinden internete çıkarmak için Shell üzerinden uygulanan adımlar:

# Wi-Fi araçlarını yükle ve şifreyi yapılandır
apt install wpasupplicant
wpa_passphrase "SSID_ADINIZ" "SIFRENIZ" >> /etc/wpa_supplicant/wpa_supplicant.conf

# Arayüzü ayağa kaldır ve IP al
ip link set wlp4s0 up
dhclient wlp4s0

2. Proxmox Sanal Ağ ve NAT Yapılandırması

Sanal makinelerin internete çıkabilmesi için 10.10.10.0/24 bloğunun `vmbr1` üzerinden tanımlanması:

# nano /etc/network/interfaces dosyasına ekle:
auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0

İnternet Paylaşımı (NAT) Komutları:

• IP Forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward
• NAT Kuralı: iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o wlp4s0 -j MASQUERADE

3. 1 TB Disk Yönetimi (LVM-Thin CLI)

wipefs -a /dev/sdb
pvcreate /dev/sdb
vgcreate depo1tb /dev/sdb
lvcreate -L 920G -T depo1tb/thinpool_depo
pvesm add lvmthin DEPO_ALANI --vgname depo1tb --thinpool thinpool_depo --content rootdir,images

4. Ubuntu Master Template Hazırlığı

Şablon oluşturmadan önce ana makinede yapılan erişim ayarları:

• SSH Enable: sudo apt install openssh-server -y && sudo systemctl enable --now ssh
• Ubuntu Firewall Disable: sudo ufw disable
• Proxmox Firewall Off: VM Donanım -> Network -> Firewall: Off

5. Klon Sonrası Benzersizleştirme (Kritik)

Klonlanan makinede çakışmaları önlemek için terminalden uygulanan adımlar:

# 1. Hostname Değiştir
sudo hostnamectl set-hostname yeni-sunucu

# 2. IP Güncelle (Netplan)
sudo nano /etc/netplan/00-installer-config.yaml (IP: 10.10.10.11)
sudo netplan apply

# 3. Machine-ID Sıfırla ve Yeniden Başlat
echo "" | sudo tee /etc/machine-id && sudo systemd-machine-id-setup && sudo reboot

6. Dış Erişim (Windows Route)

Kendi bilgisayarınızdan 10.10.10.x ağına ulaşmak için Windows CMD (Yönetici) üzerinden:

route add 10.10.10.0 mask 255.255.255.0 192.168.1.50

Laboratuvar Altyapısı Tamamlandı. Zabbix Kurulumuna Hazır!

Cloudflare Zero Trust ile Uzak Erişimde VPN’siz Güvenli Tünel: Tailscale Alternatifi mi?

VPN yorgunluğuna modern bir alternatif

Uzaktan çalışma kalıcılaştıkça, ofis ağına erişim için klasik VPN kurulumları birçok ekipte “gerekli ama can sıkan” bir rutine dönüştü. Sertifika yenilemeleri, port yönlendirme, split-tunnel karmaşası, performans düşüşü ve mobil cihazlarda kopmalar… Bu noktada Cloudflare Zero Trust, özellikle küçük ekiplerden ileri seviye homelab kullanıcılarına kadar geniş bir kitle için “VPN’siz güvenli erişim” fikrini pratik hale getiriyor. Bu yazıda, Cloudflare’ın WARP ve Tunnel yaklaşımını adım adım kurulum mantığıyla ele alacak; hangi senaryolarda Tailscale benzeri çözümlere alternatif olabileceğini inceleyeceğiz.

Zero Trust mimarisi neyi değiştiriyor?

Geleneksel VPN’de cihaz “ağın içine” girer; yetki kontrolü çoğu zaman ağ segmenti ve firewall kurallarıyla yapılır. Zero Trust yaklaşımı ise “önce doğrula, sonra en az ayrıcalıkla eriştir” felsefesine dayanır. Cloudflare tarafında bu; kullanıcı kimliği (SSO/OTP), cihaz durumu, uygulama bazlı erişim ve kayıtlı politikalarla yönetilir. Yani hedef, tüm ağa tünel açmak değil; ihtiyaç duyulan uygulamaya güvenli bir şekilde eriştirmektir. Özellikle admin panelleri, dahili dashboard’lar, Git sunucuları, staging ortamları veya NAS arayüzleri gibi “internet’e açmak istemediğiniz” servisler için bu yaklaşım oldukça temiz çalışır.

Ön hazırlık: Hesap, alan adı ve temel kavramlar

Başlamak için bir Cloudflare hesabına ve mümkünse Cloudflare’a yönlendirilmiş bir alan adına ihtiyacınız var. Şu iki kavramı netleştirelim: Cloudflare Tunnel, içerideki bir sunucudan Cloudflare’a “dışarı doğru” güvenli bir bağlantı başlatır; böylece ev/iş yerindeki NAT arkasında kalan servisleri port açmadan yayınlayabilirsiniz. Access ise bu yayına kimlerin, hangi koşullarda erişeceğini belirler. Kullanıcı tarafında ise WARP istemcisi, cihazın trafiğini belirli politikalara göre Cloudflare ağı üzerinden yönetmenizi sağlar (her zaman şart değil, birazdan anlatacağım).

Adım adım: Cloudflare Tunnel ile içerideki servisi yayınlama

Kurulumun en kritik noktası, içeride erişmek istediğiniz servisin (ör. 192.168.1.10:3000 üzerindeki bir dashboard) dışarıdan port açmadan erişilebilir hale gelmesidir. Bunun için içerideki makineye cloudflared ajanını kurarsınız. Kurulum komutu işletim sistemine göre değişse de mantık sabittir: Cloudflare panelinde bir “Tunnel” oluşturulur, size verilen kimlik bilgileriyle ajan yetkilendirilir ve bir yönlendirme kuralı tanımlanır.

Ardından “Public Hostname” kısmında örneğin dash.ornekalanadi.com gibi bir alt alan adı belirleyip, hedefi http://localhost:3000 veya yerel IP:port şeklinde tanımlarsınız. Burada önemli bir avantaj var: Port açmadığınız için saldırı yüzeyiniz ciddi şekilde azalır; ayrıca IP’niz değişse bile tünel içeriden çıktığı için erişim bozulmaz. Ev internetinde CGNAT kullananlar için bu, tek başına büyük bir kazanım.

Kimlik doğrulama: Access politikalarıyla “kim girebilir?” sorusunu çözmek

Tunnel tek başına servisi yayınlar; güvenlik tarafı ise Access ile tamamlanır. Cloudflare Zero Trust panelinde “Access → Applications” bölümünden az önce yayınladığınız host için bir uygulama tanımlarsınız. Sonrasında bir politika eklersiniz: örneğin sadece belirli e-posta alan adlarından (@sirket.com) gelen kullanıcılar girsin; ya da sadece tek tek tanımladığınız e-posta adresleri izinli olsun.

Daha ileri senaryoda SSO (Google Workspace, Microsoft Entra ID vb.) entegre edip MFA zorunlu kılabilirsiniz. Böylece servis internete “açık” görünse bile, gerçek erişim bir kimlik katmanının arkasında kalır. Üstelik bu, uygulamanızın kendi login sisteminden bağımsız bir ek güvenlik perdesi oluşturur.

WARP istemcisi ne zaman gerekli?

Birçok kişi WARP’ı “VPN gibi” düşünür; aslında WARP çoğu zaman uç cihaz politikasını işletmek için kullanılır. Eğer hedefiniz sadece web tabanlı bir arayüze (HTTP/HTTPS) erişmekse, Tunnel + Access çoğu senaryoda yeterlidir ve kullanıcılar tarayıcı üzerinden doğrulanarak erişir. Ancak SMB/RDP/SSH gibi tarayıcı dışı protokoller veya özel IP aralıklarına erişim gibi durumlarda WARP + Private Network kurgusu devreye girer. Bu sayede cihaz, Cloudflare üzerinden iç ağdaki belirli IP aralıklarına güvenli biçimde yönlendirilir.

Performans, güvenlik ve pratik kullanım değerlendirmesi

Performans tarafında en büyük değişken, Cloudflare POP noktalarına olan yakınlığınız ve içerideki uplink kalitenizdir. Web panelleri ve API erişimleri genellikle akıcı çalışır. Güvenlikte ise port açmamak, kaba kuvvet denemelerini ve servis keşfini azaltır; Access katmanı da kimlik doğrulamayı standartlaştırır. Günlük pratikte en sevdiğim taraf, yeni bir servis eklemenin “bir DNS kaydı + bir Access politikası” mantığıyla hızlıca yapılabilmesidir.

Peki Tailscale ile kıyas? Tailscale daha çok “cihazdan cihaza özel ağ” hissini çok iyi verir; Cloudflare Zero Trust ise “uygulama bazlı yayın ve kontrol” konusunda güçlüdür. Eğer hedefiniz ekip içi dahili web uygulamalarını güvenli sunmak ve merkezi erişim politikası yönetmekse Cloudflare yaklaşımı daha derli toplu olabilir. Tam tersine, cihazlar arası esnek dosya paylaşımı, mesh ağ kolaylığı ve geniş protokol çeşitliliği arıyorsanız Tailscale hâlâ çok iddialı.

Sonuç: Kimler denemeli?

Evinde NAS arayüzünü, Home Assistant’ı, bir monitoring panelini veya şirket içinde staging ortamını internet’e “açmadan” uzaktan erişmek isteyen herkes Cloudflare Zero Trust’ı denemeli. Özellikle port yönlendirme yapmadan ve MFA ile güvenliği artırarak ilerlemek isteyenler için modern bir çözüm sunuyor. İlk kurulumda kavramlar biraz yeni gelebilir; fakat bir kez oturduğunda, VPN’e dönüş ihtiyacı ciddi ölçüde azalıyor.