Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve İnce Ayar Rehberi

Docker Desktop olmadan neden Docker?

Windows 11 kullanırken Docker ile çalışmanın en popüler yolu Docker Desktop kurmak. Ancak kurumsal lisans kısıtları, kaynak tüketimi veya “arka planda sürekli servis” yaklaşımını sevmeme gibi sebeplerle daha hafif ve kontrol edilebilir bir seçenek arayanların sayısı artıyor. Bu yazıda, WSL2 üzerinde Docker Engine kurarak Docker Desktop olmadan konteyner çalıştırmayı adım adım anlatacağım. Ayrıca performans, ağ erişimi ve sık görülen hatalar için pratik ince ayarları da ekleyeceğim.

Ön koşullar

Bu rehber Windows 11 ve WSL2 mantığını temel alır. İhtiyacınız olanlar: Windows 11, yönetici yetkisi, WSL2 etkinleştirilmiş bir Linux dağıtımı (Ubuntu önerilir) ve PowerShell/Windows Terminal. WSL sürümünüzü kontrol etmek için PowerShell’de wsl -l -v komutunu kullanabilirsiniz. Dağıtımınızın “VERSION” değeri 2 değilse, wsl --set-version Ubuntu 2 ile dönüştürebilirsiniz.

1) WSL2 üzerinde Docker Engine kurulumu

Ubuntu’yu açın ve önce sistem paketlerini güncelleyin:

sudo apt update && sudo apt upgrade -y

Docker’ın resmi deposunu eklemek için gerekli paketleri kurun:

sudo apt install -y ca-certificates curl gnupg

Docker GPG anahtarını ekleyin ve depo kaydını oluşturun:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Ardından Docker Engine ve temel bileşenleri kurun:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

2) Servis yönetimi: systemd ve Docker’ın başlatılması

Güncel WSL sürümlerinde systemd desteği mevcut. Etkinleştirirseniz Docker’ı normal Linux gibi servis olarak yönetebilirsiniz. Ubuntu içinde şu dosyayı düzenleyin:

sudo nano /etc/wsl.conf

İçine şunu ekleyin:

[boot]
systemd=true

Sonra Windows tarafında WSL’i yeniden başlatın (PowerShell):

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatın:

sudo systemctl enable --now docker

Kontrol:

docker version
docker info

3) sudo yazmadan Docker kullanmak (güvenli kullanım notuyla)

Sürekli sudo yazmak istemiyorsanız kullanıcıyı docker grubuna ekleyebilirsiniz:

sudo usermod -aG docker $USER

Oturumu kapatıp açın veya WSL’i yeniden başlatın. Not: Docker grubu pratik ama güçlü yetkilere sahiptir; paylaşımlı makinelerde dikkatli olun.

4) Hızlı test: nginx konteyneri çalıştırma

Kurulumun doğru olduğunu görmek için küçük bir test iyi olur:

docker run --rm -d --name web -p 8080:80 nginx:alpine

Ardından tarayıcıda http://localhost:8080 adresini açın. WSL2 ağ katmanı sayesinde port yönlendirme genellikle sorunsuz çalışır. İşiniz bitince durdurun:

docker stop web

5) İnce ayar: disk performansı ve proje konumu

WSL2 + Docker kullanımında en kritik konu dosya sistemi performansıdır. Projenizi Windows dosya sisteminde (ör. /mnt/c/...) tutup konteyner içinde bind mount yaparsanız, yoğun I/O işlemlerinde yavaşlık görebilirsiniz. Daha iyi performans için kaynak kodunu WSL Linux dosya sisteminde (ör. /home/kullanici/proje) konumlandırın. Editör olarak VS Code kullanıyorsanız Remote - WSL eklentisiyle bu akış oldukça rahattır.

6) Sık karşılaşılan sorunlar ve çözümler

“Cannot connect to the Docker daemon” hatası alıyorsanız çoğunlukla servis çalışmıyordur: sudo systemctl status docker ile kontrol edin, gerekirse sudo systemctl restart docker deneyin. Systemd aktif değilse, önce /etc/wsl.conf ayarını doğrulayın ve wsl --shutdown ile tamamen kapatıp açın.

Port çakışması yaşarsanız (ör. 8080 doluysa) farklı bir port seçin: -p 8081:80. Ayrıca bazı güvenlik yazılımları veya şirket VPN’leri localhost portlarını etkileyebilir; sorun yaşarsanız geçici olarak kapatıp test etmek mantıklı olur.

Kaynak tüketimi için WSL’e limit koyabilirsiniz. Windows kullanıcı dizininizde .wslconfig dosyası oluşturup bellek/CPU sınırı vermek, özellikle uzun süre açık kalan geliştirme makinelerinde sistemi rahatlatır. Örneğin 4 GB RAM ve 4 çekirdek sınırı çoğu orta ölçekli iş için yeterlidir.

Sonuç

Docker Desktop olmadan Docker kullanmak, özellikle “hafif ve kontrol edilebilir” bir geliştirme ortamı isteyenler için güçlü bir alternatif. WSL2 üzerinde Docker Engine kurduğunuzda hem Linux ekosisteminin doğallığını korur hem de Windows tarafındaki iş akışınızı bozmadan konteynerlerle çalışabilirsiniz. Doğru proje konumu seçimi ve systemd ile servis yönetimi gibi küçük dokunuşlar, deneyimi ciddi biçimde iyileştirir.

Claude 3, GPT-4o ve Llama 3 ile RAG (Retrieval-Augmented Generation) Kurulumu: Üretim Odaklı Adım Adım Rehber

RAG Nedir ve Neden 2026’da Hâlâ En İyi Yaklaşımlardan Biri?

Büyük dil modelleri (LLM) tek başına güçlü olsa da, her zaman güncel veriye erişemez ve kurumsal dokümanlarınız gibi özel içerikleri “doğrudan” bilemez. RAG (Retrieval-Augmented Generation), modeli harici bir bilgi kaynağıyla besleyerek bu açığı kapatır: Önce doğru doküman parçaları (chunk) aranır, sonra bu parçalar modele bağlam olarak verilerek yanıt ürettirilir. Böylece halüsinasyon riski düşer, cevaplar kaynaklı ve izlenebilir hâle gelir, ayrıca model güncellemeden veri güncellenebilir.

Bu yazıda, ileri seviye ama uygulanabilir bir RAG mimarisini ele alacağız: parça stratejisi, embedding seçimi, vektör veritabanı, filtreleme, yeniden sıralama (reranking) ve üretim tarafında prompt tasarımı. Hedefimiz “demo” değil, üretim ortamına yakın bir kurulum mantığı vermek.

Mimari Genel Bakış: 5 Katmanlı RAG

Sağlam bir RAG sistemi genellikle 5 bileşenden oluşur: (1) Veri hazırlama (temizleme, bölümleme), (2) Embedding (vektörleştirme), (3) Vektör indeks (arama), (4) Yeniden sıralama (en alakalı parçaları seçme), (5) Üretim (LLM ile yanıt oluşturma). Bu yapı, “LLM’ye her şeyi verelim” yaklaşımından daha az maliyetli ve daha tutarlıdır.

1) Veri Hazırlama: Chunk Stratejisi ve Metadata

RAG kalitesi, çoğu zaman modelden önce chunk stratejinizle belirlenir. PDF’lerden, wiki sayfalarından veya ticket kayıtlarından gelen içerik düzensiz olabilir. Pratikte iyi çalışan yaklaşım: 500–900 token arası chunk boyutu ve 70–150 token overlap kullanmaktır. Çok küçük chunk, bağlamı parçalar; çok büyük chunk ise arama isabetini düşürür.

Her chunk’a mutlaka metadata ekleyin: kaynak doküman adı, URL (dahili olabilir), bölüm başlığı, tarih, erişim yetkisi, ürün/servis etiketi gibi alanlar. Üretimde asıl farkı yaratan kısım burasıdır; çünkü sonradan “sadece X ürününe ait, son 6 ayın dokümanlarını tara” gibi filtreleri metadata ile yaparsınız.

2) Embedding Seçimi: Doğru Vektör Doğru Sonuç

Embedding modeli, metni sayısal vektöre dönüştürür ve benzerlik aramasının temelini oluşturur. Türkçe içerikte embedding kalitesi kritiktir. Seçerken şu kriterlere bakın: çok dilli başarı, uzun metin performansı, maliyet ve gecikme. Kurumsal senaryoda aynı anda hem İngilizce hem Türkçe doküman varsa, çok dilli embedding genellikle daha güvenli tercihtir.

Ek bir ipucu: Embedding üretirken metni “ham” basmak yerine, başlık + bölüm + içerik şeklinde birleştirmek arama isabetini artırır. Örneğin: “Başlık: … | Bölüm: … | Metin: …” gibi küçük bir şablon, özellikle benzer kavramların çok geçtiği dokümanlarda yardımcı olur.

3) Vektör Veritabanı ve İndeks Ayarları

Vektör veritabanı seçiminde popüler seçenekler arasında FAISS (self-host), Milvus, Qdrant, Weaviate ve bulut tabanlı servisler bulunur. Üretimde dikkat edilmesi gerekenler: HNSW gibi indeks türleri, filtreli arama performansı, replikasyon/backup ve erişim kontrolüdür.

HNSW tabanlı aramada temel ayar mantığı şöyledir: daha yüksek doğruluk için arama parametreleri yükselir ama gecikme artar. Bu yüzden arama katmanını iki fazlı düşünmek iyi çalışır: önce hızlı bir aday havuzu (ör. top-50) çıkarın, sonra daha pahalı bir reranking ile top-5/top-8’e düşürün.

4) Reranking: “En Yakın” Parça Her Zaman “En Alakalı” Değildir

Embedding benzerliği, semantik yakınlığı yakalar ama her zaman kullanıcı sorusuna en alakalı parçayı seçmeyebilir. Özellikle teknik dokümanlarda aynı terimler farklı bağlamlarda geçebilir. Burada reranker devreye girer: Soru ile aday chunk’ları daha “dikkatli” karşılaştırıp yeniden sıralar.

Üretimde yaygın ve etkili bir desen: top-50 vektör araması → top-10 rerank → top-4 bağlam. Reranking maliyetli olabilir; bu yüzden sadece gerekli olduğunda açmak için basit bir eşik kullanabilirsiniz (örneğin, en iyi sonucun benzerlik skoru düşükse rerank uygula).

5) Üretim (LLM) Katmanı: Prompt Tasarımı ve Kaynak Gösterme

RAG’in “G” kısmı, yani generation tarafı, çoğu zaman yanlış anlaşılır: LLM’den mucize beklemek yerine ona disiplin kazandırmak gerekir. İyi çalışan prompt ilkeleri: (1) Modeli sadece verilen bağlamla cevap vermeye zorlamak, (2) Yetersiz bağlam varsa “bilmiyorum” demesini istemek, (3) Cevabı madde madde ve adım adım ürettirmek, (4) Mümkünse kaynak chunk referansı döndürmek.

Kısa bir örnek yönerge mantığı: “Aşağıdaki bağlam parçalarını kullan. Bağlam dışında tahmin yürütme. Yanıtın sonunda ‘Kullanılan Kaynaklar’ altında parça kimliklerini yaz.” Bu yaklaşım, özellikle denetim ve uyumluluk isteyen ekiplerde RAG’i güvenilir kılar.

Kalite Ölçümü: RAG’i “Hissetmek” Yerine Test Etmek

RAG sistemleri, “birkaç soru sorup iyi gibi” diyerek üretime alınmamalı. Basit ama etkili bir yöntem: 30–100 adet gerçek kullanıcı sorusunu toplayın, her soru için “beklenen kaynak doküman” düşünün ve şu metrikleri izleyin: retrieval recall (doğru kaynak top-k içinde mi), answer faithfulness (cevap bağlamla tutarlı mı), latency (uçtan uca gecikme) ve maliyet. Bu ölçümlerle chunk boyutu, top-k, reranking aç/kapa ve prompt ayarlarını kontrollü biçimde optimize edebilirsiniz.

Üretim İçin Pratik İpuçları (Sık Yapılan Hatalar)

1) Yetkilendirme yok sayılmasın: Kullanıcının görmemesi gereken dokümanı retrieval katmanında filtrelemezseniz, LLM yanlışlıkla sızdırabilir. Metadata’ya erişim seviyeleri ekleyin ve arama sorgusuna mutlaka uygulayın.

2) “Tek indeks her şeye yeter” yanılgısı: Destek kayıtları, teknik kılavuzlar ve release notları aynı dilde olsa bile farklı karakterdedir. Bazen iki ayrı koleksiyon/indeks, tek dev koleksiyondan daha iyi sonuç verir.

3) Güncelleme akışı planlayın: Dokümanlar değiştikçe embedding’lerin güncellenmesi gerekir. En azından günlük incremental indeksleme ve silinen içerik için “tombstone” mantığı kurun.

4) Caching kullanın: Sık sorulan sorular ve popüler retrieval sonuçları için cache, maliyeti ciddi düşürür. Ayrıca aynı sorunun farklı yazımları için basit bir normalizasyon (küçük harf, noktalama temizliği) bile kazanç sağlar.

Sonuç: RAG’i Bir “Özellik” Değil, Bir Sistem Olarak Kurun

RAG, doğru kurgulandığında LLM’leri kurumsal bilgiyle güvenli şekilde birleştirmenin en pratik yoludur. Başarı; modelden çok, chunk stratejisi, metadata disiplini, filtreleme, reranking ve ölçüm altyapısının birlikte çalışmasına bağlıdır. Bu yazıdaki adımları temel alıp kendi verinize göre ayarladığınızda, hem daha doğru yanıtlar alır hem de maliyeti ve gecikmeyi kontrol edebilirsiniz.

Docker ile Yerel LLM Çalıştırma: Ollama Kurulumu, Model Yönetimi ve API ile Entegrasyon

Yerelde yapay zekâ neden bu kadar popüler oldu?

Bulut tabanlı yapay zekâ servisleri hızlı ve pratik; ancak maliyet, gecikme, veri gizliliği ve entegrasyon esnekliği gibi başlıklarda her zaman ideal değiller. Özellikle hassas verilerle çalışan ekipler için yerelde (lokalde) çalışan büyük dil modelleri (LLM) ciddi bir avantaj sağlıyor. Son dönemde bu ihtiyacı en pratik şekilde karşılayan araçlardan biri de Ollama. Bu yazıda, Ollama’yı Docker ile kurup yerelde model çalıştırmayı, model yönetimini ve basit bir API kullanımını adım adım ele alıyorum.

Ollama nedir, ne işimize yarar?

Ollama, LLM’leri bilgisayarınızda çalıştırmayı kolaylaştıran bir çalışma zamanı ve model yönetim katmanı gibi düşünebilirsiniz. “Modeli indir, çalıştır, API üzerinden çağır” akışını sadeleştirir. Birçok model ailesini desteklemesi ve komut satırı üzerinden hızlı bir deneyim sunması sayesinde geliştiriciler arasında hızla yayıldı. Ayrıca yerel bir HTTP API sunduğu için, kendi uygulamanızdan bu modeli sanki bir servis gibi tüketebilirsiniz.

Kurulum ön koşulları

Bu rehberde Docker tabanlı bir kurulum anlatacağım. İhtiyacınız olanlar: Docker (ve mümkünse Docker Compose), yeterli disk alanı (model boyutuna göre 5–20 GB+), ve tercihen güçlü bir CPU/GPU. GPU hızlandırma her sistemde aynı kolaylıkta olmasa da, CPU ile de temel denemeler yapılabilir. Komutlar Linux/macOS için uygundur; Windows’ta WSL2 ile benzer şekilde ilerleyebilirsiniz.

Docker ile Ollama’yı çalıştırma

Önce kalıcı bir veri dizini kullanmak iyi bir fikirdir; çünkü modeller indirildiğinde container silinse bile tekrar indirmek zorunda kalmazsınız. Aşağıdaki komut, Ollama’yı arka planda ayağa kaldırır ve varsayılan API portunu (11434) dışarı açar:

Komut:

docker run -d --name ollama \ -p 11434:11434 \ -v ollama:/root/.ollama \ ollama/ollama

Bu noktada servis çalışır durumdadır. Kontrol etmek için:

docker logs -f ollama

İlk modelinizi indirme ve çalıştırma

Ollama, model yönetimini komut satırından çok kolaylaştırır. Container içine girip bir model çekebilir veya doğrudan “exec” ile komut çalıştırabilirsiniz. Örneğin küçük ve hızlı bir modelle başlamak mantıklıdır. Aşağıdaki örnekte bir modeli indirip interaktif şekilde çalıştırıyoruz:

docker exec -it ollama ollama run llama3

İlk çalıştırmada model indirileceği için biraz bekleyebilirsiniz. İndirme bittiğinde sohbet ekranı açılır; Türkçe istem (prompt) verip yanıt alabilirsiniz. Daha iyi yanıtlar için isteminizi net tutun: amaç, bağlam, çıktı formatı gibi detayları belirtin.

Model yönetimi: listeleme, silme, güncelleme

Disk alanı yerel LLM dünyasında hızlı tükenir. Bu yüzden indirilen modelleri düzenli yönetmek önemli. Yüklü modelleri listelemek için:

docker exec -it ollama ollama list

Kullanmadığınız bir modeli silmek için:

docker exec -it ollama ollama rm llama3

Modeli tekrar çekmek/güncellemek için aynı “run” komutu ya da ilgili pull akışı kullanılabilir. Ayrıca aynı modelin farklı varyantları (ör. boyut, quantization) performans ve kaliteyi ciddi etkiler. Daha küçük quantization daha hızlıdır ama doğruluk ve akıcılık düşebilir. Bu dengeyi kendi kullanım senaryonuza göre test ederek bulmanız gerekir.

HTTP API ile entegrasyon: uygulamaya bağlamak

Ollama’nın en büyük artılarından biri, yerelde bir servis gibi davranmasıdır. Böylece herhangi bir dille HTTP isteği atarak yanıt alabilirsiniz. Basit bir “prompt gönder, yanıt al” testi için terminalde şu isteği deneyin:

curl http://localhost:11434/api/generate -d '{ "model": "llama3", "prompt": "Bana 5 maddede SEO uyumlu blog yazısı ipucu ver.", "stream": false }'

Yanıtta genellikle modelin ürettiği metin ve bazı ek alanlar döner. Uygulama tarafında JSON parse edip “response” benzeri alanı kullanıcıya gösterebilirsiniz. stream seçeneğini açtığınızda token token akış alarak daha hızlı bir kullanıcı deneyimi sağlayabilirsiniz.

Performans ipuçları ve güvenlik notları

Yerel LLM çalıştırırken performans iki şeye bakar: donanım ve model seçimi. Eğer yalnızca metin özetleme, e-posta taslağı, basit kod yardımı gibi işler yapacaksanız daha küçük modeller yeterli olabilir. Daha karmaşık muhakeme ve uzun bağlam ihtiyaçlarında ise daha büyük modeller gerekebilir; bu da RAM/VRAM ve disk tüketimini artırır. Ayrıca Ollama’yı yalnızca kendi makinenizde kullanacaksanız portu dış dünyaya açmamak iyi bir güvenlik alışkanlığıdır. Sunucuda kullanıyorsanız, ters proxy ve erişim kontrolü (ör. yalnızca VPN içinden erişim) planlayın.

Sonuç: Yerelde LLM denemek artık zor değil

Docker ile Ollama kurulumunu yaptıktan sonra model indirmek, çalıştırmak ve API üzerinden uygulamaya bağlamak oldukça akıcı bir süreç. Bu yaklaşım; kişisel projeler, kurum içi araçlar, gizlilik odaklı metin işleme senaryoları ve düşük gecikme isteyen otomasyonlar için iyi bir seçenek. Bir sonraki adım olarak farklı model varyantlarını test edebilir, istem mühendisliğiyle çıktıları standardize edebilir ve kendi uygulamanızda bir “yerel yapay zekâ asistanı” deneyimi oluşturabilirsiniz.

WebRTC ile Tarayıcıdan Tarayıcıya Dosya Aktarımı: Sinyal Sunucusu ve Güvenli P2P Akışı Kurulumu

WebRTC ile P2P dosya aktarımı neden hâlâ önemli?

Bulut depolama servisleri pratik ama her zaman ideal değil: büyük dosyalarda yükleme süresi, kota sınırları, bağlantı hızına bağlı gecikmeler ve kimi senaryolarda gizlilik endişeleri devreye giriyor. WebRTC (Web Real-Time Communication) ise tarayıcıların birbirleriyle doğrudan haberleşmesini sağlayarak, arada dosyayı tutan bir “depo” olmadan aktarımı mümkün kılıyor. Bu yazıda, ileri seviye ama uygulanabilir bir yaklaşımla, tarayıcıdan tarayıcıya güvenli P2P dosya transferi için gerekli bileşenleri ve kritik ayarları adım adım ele alacağım.

Mimarinin özeti: Sinyal mi, medya mı?

WebRTC, bağlantıyı “kendi kendine” başlatmaz. İki tarayıcının birbirini bulması ve bağlantı parametrelerini paylaşması için bir sinyal (signaling) kanalına ihtiyacı vardır. Bu kanal genellikle WebSocket ile kurulur. Sinyal sunucusu sadece şu verileri iletir: SDP teklif/yanıtları (offer/answer) ve ICE adayları. Dosyanın kendisi ise ideal durumda RTCDataChannel üzerinden P2P akar.

Özet akış: (1) İstemciler sinyal sunucusuna bağlanır. (2) Bir oda/kimlik üzerinden eşleşir. (3) SDP/ICE alışverişi yapılır. (4) NAT arkasından geçiş için STUN/TURN devreye girer. (5) DataChannel açılır ve dosya parçalı şekilde gönderilir.

Gereksinimler: STUN/TURN, HTTPS ve tarayıcı kısıtları

Modern tarayıcılarda WebRTC çoğu zaman “secure context” ister. Üretimde HTTPS kullanmanız önemlidir (localhost istisna). NAT/kurumsal ağ koşullarında yalnız STUN yetmeyebilir; bu nedenle bir TURN sunucusu kritik bir güvence katmanıdır. TURN, doğrudan bağlantı kurulamadığında trafiği relay eder; bu da maliyetli ama erişilebilirliği artıran bir çözümdür.

Pratik öneri: Geliştirme aşamasında STUN ile başlayın; sahaya çıkarken TURN ekleyin. En çok kullanılan açık kaynak TURN çözümü coturn’dür. Ayrıca aktarımın güvenliği WebRTC’de varsayılan olarak DTLS ile sağlanır; yani DataChannel üzerinde giden veri şifrelenir.

1) Basit bir sinyal sunucusu (Node.js + WebSocket)

Sinyal sunucusunun görevi “mesaj taşımak”tır, dosya aktarmak değil. Basit bir odalı yapı kurgulayabilirsiniz: istemci bir odaya katılır, diğer istemci gelince birbirlerinin mesajlarını iletir. Aşağıdaki yaklaşım üretim için değil, mantığı netleştirmek içindir: tek sunucu, oda eşleşmesi, mesaj yönlendirme.

İpucu: Mesajları tip alanıyla sınıflandırın: offer, answer, ice, join. Böylece istemci tarafı daha okunaklı olur ve hataları ayıklamak kolaylaşır.

2) İstemci tarafı: RTCPeerConnection ve RTCDataChannel

Tarayıcı tarafında iki temel nesne kullanılır: RTCPeerConnection ve RTCDataChannel. PeerConnection, ICE/STUN/TURN ile bağlantıyı kurar; DataChannel ise dosya parçalarını taşır. Buradaki kritik konu, dosyayı tek seferde göndermeye kalkmamak. Büyük bir Blob’u tek mesajla yollamak bellek patlamasına, tarayıcı takılmalarına veya kanal buffer’ının dolmasına yol açabilir.

Sağlıklı yöntem: Dosyayı chunk’lara bölün (örneğin 16 KB–256 KB arası), sırayla gönderin ve backpressure yönetin. WebRTC tarafında bunun için dataChannel.bufferedAmount değerini izleyip belirli eşiğin üstünde beklemek iyi bir pratiktir.

3) Chunk stratejisi, akış kontrolü ve bütünlük

Dosya transferinde üç konu genelde gözden kaçar: akış kontrolü, bütünlük ve yeniden birleştirme. Akış kontrolü için bufferedAmount eşiği belirleyin (ör. 8–16 MB). Bütünlük için en basit yaklaşım: dosya boyutu, parça sayısı, her parçanın indeks bilgisi ve isteğe bağlı hash (ör. SHA-256) gönderin. Yeniden birleştirmede alıcı tarafta parçaları sıraya koyup ArrayBuffer/Blob olarak birleştirin.

Ayrıca DataChannel için iki mod var: ordered (varsayılan) ve unordered. Dosya aktarımında genelde ordered işinizi kolaylaştırır. Paket kaybına dayanıklılık isterseniz, parçaları indeksleyip unordered kullanabilir, eksikleri yeniden isteyebilirsiniz; bu ileri seviye bir iyileştirmedir.

4) ICE yapılandırması: STUN ve TURN örneği

PeerConnection oluştururken ICE sunucularını tanımlarsınız. STUN, dış IP/port keşfine yardım eder; TURN ise relay görevi görür. Kurumsal ağlarda UDP engellenmiş olabilir; TURN’u TCP/TLS ile de sunmak gerekir. Üretimde en çok takılınan yer burasıdır: “Aynı Wi‑Fi’da çalışıyor, dış ağda çalışmıyor.” Sebebi genellikle TURN eksikliği veya yanlış kimlik bilgisidir.

Güvenlik notu: TURN kullanıcı adı/parola bilgilerini statik tutmak yerine zaman kısıtlı (time-limited) kimlik doğrulama kullanmak daha güvenlidir. coturn bu konuda esnektir.

5) Test, hata ayıklama ve performans ipuçları

Test aşamasında önce iki sekme arasında (aynı makine) deneyin; sonra aynı LAN, sonra farklı ağlar. Chrome’da chrome://webrtc-internals sayfası ICE adaylarını, bağlantı durumlarını ve kanal istatistiklerini incelemek için çok değerlidir. Bağlantı kurulamıyorsa genellikle sorun sinyal değil, ICE/TURN tarafındadır.

Performans için öneriler: Chunk boyutunu cihazlara göre ayarlayın, gereksiz kopyalamaları azaltın, alıcı tarafta parçaları birleştirirken bellek kullanımını izleyin. Çok büyük dosyalarda (ör. birkaç GB) tarayıcı sınırlarına yaklaşabilirsiniz; bu durumda indirme/streaming yaklaşımı ve dosya sistemi erişimi (File System Access API) gibi ek teknikler gündeme gelir.

Sonuç: Bulutsuz paylaşım için sağlam bir temel

WebRTC ile tarayıcıdan tarayıcıya dosya aktarımı, doğru kurgulandığında hem hızlı hem de şifreli bir deneyim sunar. Bu işin kalbi dosyayı taşımaktan çok, bağlantıyı güvenilir biçimde kurmaktır: sinyal sunucusu basit kalabilir, fakat ICE/STUN/TURN ayarları ve chunk tabanlı aktarım stratejisi projenin başarısını belirler. Buradaki yaklaşımı bir temel olarak alıp; oda yönetimi, kimlik doğrulama, yeniden deneme mekanizmaları ve transfer ilerleme göstergesi gibi parçalarla üretim seviyesine rahatça taşıyabilirsiniz.

Docker ile Rootless Container Çalıştırma: Linux’ta Daha Güvenli ve Pratik Kurulum Rehberi

Rootless Docker nedir ve neden önemli?

Docker’ı çoğu sistemde “root” ayrıcalıklarıyla çalıştırmak alışıldık bir durumdur. Ancak bu yaklaşım, Docker daemon’una (dockerd) erişebilen bir kullanıcının sistem üzerinde beklenmedik yetkilere ulaşabilmesi gibi güvenlik riskleri doğurabilir. Rootless Docker, container’ları ve Docker daemon’unu root yetkisi olmadan, sıradan bir kullanıcı hesabı altında çalıştırarak saldırı yüzeyini azaltmayı hedefler. Özellikle çok kullanıcılı makinelerde, geliştirme sunucularında veya güvenlik hassasiyeti yüksek ortamlarda rootless yaklaşım belirgin bir avantaj sağlar.

Bu yazıda, güncel Linux dağıtımlarında rootless Docker’ı adım adım kuracak, ağ ve port yönlendirme gibi sık karşılaşılan noktaları netleştirecek ve kullanım sırasında işinize yarayacak pratik ipuçlarını paylaşacağım. Anlatım Debian/Ubuntu çizgisinde olsa da, Fedora/Arch gibi dağıtımlarda da kavramlar büyük ölçüde aynıdır.

Ön koşullar ve temel kavramlar

Rootless modun arkasında birkaç önemli mekanizma bulunur: Linux user namespace (kullanıcı isim alanı) sayesinde container içindeki “root”, host üzerinde gerçek root olmaz; ayrıca ağ tarafında çoğunlukla slirp4netns veya benzeri user-space ağ çözümleri devreye girer. Bu sayede Docker, root yetkisi olmadan da container’lara izolasyon sağlayabilir. Yine de bazı sınırlamalar vardır: düşük portlara (1-1023) doğrudan bind etmek, belirli network sürücüleri veya bazı kernel özellikleri rootless senaryoda farklı davranabilir.

Gerekenler: 1) Güncel bir Linux kernel (çoğu modern dağıtım yeterli), 2) Sisteminizde Docker’ın rootless araçları (paket içeriği veya docker-ce kurulumuyla gelir), 3) user namespace desteği (genelde açıktır), 4) Ağ için slirp4netns ve yardımcı araçlar (dağıtıma göre paket isimleri değişebilir).

Kurulum: Rootless Docker’ı etkinleştirme

Önce Docker’ın sisteminizde kurulu olduğundan emin olun. Dağıtımınızın deposundan veya Docker’ın resmi paketlerinden kurulumu yapabilirsiniz. Rootless kurulumun kritik adımı, kullanıcı bazında bir Docker daemon’u başlatmaktır. Bunun için Docker, genellikle dockerd-rootless-setuptool.sh adlı bir yardımcı betik sağlar.

Terminalde kullanıcı hesabınızla şu komutu çalıştırın (dosya yolu dağıtıma göre değişebilir):

dockerd-rootless-setuptool.sh install

Bu işlem, kullanıcı seviyesinde systemd servisleri tanımlar ve Docker socket’ini kullanıcı dizininize taşır. Kurulum tamamlandığında size çoğu zaman bir “DOCKER_HOST” önerisi de gösterilir. Tipik olarak rootless Docker socket’i şu yolda olur:

unix:///run/user/1000/docker.sock

Eğer systemd kullanıyorsanız, rootless daemon’u şu şekilde yönetebilirsiniz:

systemctl --user start docker

systemctl --user enable docker

Ardından Docker istemcisinin doğru socket’e bağlanması gerekir. Çoğu kurulum betiği ortam değişkeni önerir. Örneğin:

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

Bu değişkeni kalıcı yapmak için shell profilinize ekleyebilirsiniz (ör. ~/.bashrc veya ~/.zshrc). Sonrasında kontrol için:

docker info

Çıktıda “rootless” ibaresini ve “Server” kısmında kullanıcı-oturumuna bağlı socket yolunu görmeniz beklenir.

Portlar, ağ ve “1024 altı” konusu

Rootless Docker’da en çok takılınan başlık port yönlendirmedir. Normalde root yetkisiyle 80/443 gibi düşük portlara bind etmek kolaydır; rootless modda ise bu portlar için ek ayar gerekir. İki pratik yaklaşım var: 1) Container’ı 8080/8443 gibi yüksek portlarda yayınlayıp reverse proxy ile 80/443’e taşımak, 2) Rootless için port yönlendirme yardımcılarını kullanmak (dağıtıma ve kurulum biçimine göre değişebilir).

Basit bir test için Nginx container’ını 8080’e yayınlayabilirsiniz:

docker run --rm -p 8080:80 nginx:latest

Tarayıcıdan http://localhost:8080 ile kontrol edin. Bu senaryo rootless modda genellikle sorunsuz çalışır.

Depolama ve performans notları

Rootless modda depolama sürücüsü seçimi ve overlay kullanımı dağıtıma göre değişebilir. Modern sistemlerde “overlay2” çoğu zaman mümkün olsa da, bazı ortamlarda “fuse-overlayfs” devreye girer. Bu, uyumluluk açısından avantaj sağlarken belirli iş yüklerinde performansı etkileyebilir. Eğer çok sayıda küçük dosya operasyonu yapan build süreçleriniz varsa (ör. büyük Node.js bağımlılıkları veya yoğun katmanlı Dockerfile’lar), rootless ve rootful performansını kendi ortamınızda kıyaslamak mantıklıdır.

Bir diğer pratik nokta: Rootless kurulum, imajları ve container verisini kullanıcı dizinine yakın bir yerde tutar. Bu da çok kullanıcı bulunan sistemlerde kullanıcı başına ayrı izolasyon sağlar. Öte yandan disk kotası, home dizini şifrelemesi veya NFS üzerinde home kullanımı gibi durumlar performansı etkileyebilir.

Güvenlik açısından artılar ve dikkat edilmesi gerekenler

Rootless Docker, “Docker grubuna eklenen kullanıcı root olur” eleştirisini önemli ölçüde azaltır; daemon ve container’lar ayrıcalıksız çalıştığı için bir kaçış senaryosunun etkisi genellikle sınırlanır. Yine de bu, tüm risklerin sıfırlandığı anlamına gelmez. Container içindeki uygulamalarınıza dair zafiyetler, yanlış volume mount kullanımı veya hassas dosyaların container’a verilmesi gibi hatalar rootless modda da sorun çıkarabilir.

Öneriler: Gereksiz yetkileri kapatın, container’lara sadece ihtiyaç duyduğu klasörleri bind edin, mümkünse read-only mount kullanın, “latest” yerine sabit etiketli imajlar tercih edin ve düzenli olarak imajlarınızı güncelleyin.

Ne zaman rootless tercih edilmeli?

Eğer kişisel geliştirme makinenizde, paylaşımlı bir Linux sunucusunda veya CI ortamında Docker kullanıyorsanız rootless yaklaşım ciddi bir güvenlik artısı sağlar. “Ben zaten sudo kullanıyorum” diyenler için bile rootless, Docker daemon’u üzerinden gelebilecek ayrıcalık yükseltme risklerini azaltır. Bununla birlikte özel network gereksinimleri, düşük port zorunluluğu veya yüksek I/O performansı gibi ihtiyaçlarınız varsa rootful Docker hâlâ daha uygun olabilir. İdeal yaklaşım, iş yüküne göre iki modeli de doğru yerde kullanmaktır.

Bu rehberdeki adımlarla rootless Docker’ı aktif ettikten sonra günlük kullanım alışkanlıklarınız çok değişmeden, daha güvenli bir çalışma düzenine geçebilirsiniz. İlk etapta port ve ağ detaylarını netleştirmeniz, sonrasında da build ve runtime performansını kendi projenizde test etmeniz yeterli olacaktır.

Cloudflare Zero Trust ile Uygulamalarını İnternete Açmadan Yayına Al: Tunnel Kurulumu ve İnce Ayarlar

İnternete Port Açmadan Yayınlamak Neden Önemli?

Evde ya da küçük bir ofiste bir web paneli, API, yönetim arayüzü veya test ortamı çalıştırıyorsanız “router’dan port yönlendirme” genellikle ilk akla gelen yöntem olur. Ancak bu yaklaşım, servisinizin doğrudan internete açılması demektir: zafiyet taramaları, brute force denemeleri ve yanlış yapılandırmalar bir anda ciddi bir güvenlik riskine dönüşebilir. Modern yaklaşım, uygulamayı dış dünyaya “açmadan” erişilebilir kılmak ve erişimi kimlik doğrulama politikalarıyla kontrol etmektir.

Bu yazıda Cloudflare Zero Trust ekosisteminin en pratik parçalarından biri olan Cloudflare Tunnel (cloudflared) ile, içeride çalışan bir servisi port açmadan dışarıya yayınlamayı anlatacağım. Ayrıca gerçek hayatta iş gören ayarları: alt alan adı yönlendirme, erişim politikaları, HTTPS davranışı ve temel sorun giderme adımlarını da ekleyeceğim.

Cloudflare Tunnel Nedir, Ne İşe Yarar?

Cloudflare Tunnel, içerideki sunucunuzdan Cloudflare ağına doğru çıkış yönlü (outbound) bir tünel kurar. Yani modeminizde inbound port açmazsınız. cloudflared arka planda Cloudflare’a bağlanır; ziyaretçi tarafında gelen istekler Cloudflare üzerinden bu tünelden iç servisinize iletilir. Böylece hem saldırı yüzeyi küçülür hem de Cloudflare’ın WAF, rate limit, Access politikaları gibi katmanları devreye alınabilir.

Ön Koşullar

1) Cloudflare’da yönetebildiğiniz bir alan adı (domain) 2) Cloudflare Zero Trust paneline erişim (ücretsiz plan çoğu senaryo için yeterli) 3) İç ağınızda yayınlanan bir servis: örneğin http://localhost:3000 veya http://192.168.1.50:8080 4) Linux/Windows/macOS üzerinde çalışacak bir makine (tüneli bu makine kuracak)

Adım Adım Kurulum (Zero Trust Panel Üzerinden)

1) Zero Trust’a girin: Cloudflare Dashboard > Zero Trust. Sol menüden Access veya Networks altından Tunnels bölümünü bulun.

2) Yeni tünel oluşturun: “Create a tunnel” deyin, tünele anlamlı bir isim verin (ör. ev-lab).

3) cloudflared kurun: Cloudflare, işletim sisteminize göre komutları ekranda gösterir. Linux için çoğunlukla paket deposu veya tek ikili (binary) ile kurulum sağlanır. Kurulumdan sonra, panelin verdiği komutla tüneli makinenize “bağlarsınız”. Bu adım, makinenizde kimlik doğrulaması yaparak tüneli Cloudflare hesabınıza iliştirir.

4) Public Hostname tanımlayın: Tünelin “Public Hostname” kısmında bir alt alan adı seçin. Örneğin panel.orneksite.com. “Service” bölümüne ise içerideki hedefi yazın: örneğin http://localhost:3000 ya da http://192.168.1.50:8080. Bu noktadan sonra Cloudflare, gelen trafiği tünel üzerinden doğru servise yönlendirmeyi bilir.

HTTPS, Origin ve Güvenli Varsayılanlar

Cloudflare tarafında kullanıcılar genellikle HTTPS ile bağlanır. İçerideki servisiniz HTTP çalışıyor olabilir; bu sorun değildir. Cloudflare, edge’de HTTPS sonlandırıp tünel üzerinden HTTP ile iletebilir. Yine de hassas bir panel yayınlıyorsanız, içeride de TLS kullanmak veya en azından erişimi Cloudflare Access ile kilitlemek iyi fikirdir.

Ek bir güvenlik adımı olarak, panel yayınlıyorsanız Cloudflare WAF kuralları, bot koruması ve rate limit seçeneklerine göz atın. Tunnel kullanmak tek başına “güvenli” anlamına gelmez; yetkisiz erişimi engelleyecek politika katmanı şarttır.

Cloudflare Access ile Kim Girebilir? (Gerçek Hayat Senaryosu)

En güçlü taraflardan biri, uygulamanıza giriş için IP whitelist yerine kimlik tabanlı kontrol sunmasıdır. Örneğin sadece Google Workspace hesabınızla giriş yapılmasını isteyebilirsiniz.

1) Zero Trust > Access > Applications > “Add an application” (Self-hosted seçin). 2) Uygulama alan adını seçin (ör. panel.orneksite.com). 3) Policy oluşturun: “Allow” ve şart olarak e-posta domain’i, belirli e-posta adresleri veya bir kimlik sağlayıcı grubu ekleyin. 4) İsterseniz ek doğrulama (MFA) koşulları ekleyin.

Bu sayede uygulamanız internete açık görünse bile, içeri girmek için kullanıcı Cloudflare Access ekranından geçmek zorunda kalır. Özellikle admin panelleri, Home Assistant, Grafana, Portainer, Git servisleri gibi araçlarda bu yaklaşım port açmaya göre çok daha kontrollüdür.

Sık Karşılaşılan Sorunlar ve Hızlı Çözümler

403/Access ekranı gelmiyor: Access uygulaması doğru hostname’e bağlandı mı kontrol edin. DNS kaydı Cloudflare proxy (turuncu bulut) arkasında mı? Tunnel tarafında “Public Hostname” doğru mu?

502/Bad Gateway: Tünel ayakta olsa bile içeride hedef servis yanıt vermiyor olabilir. Makinede curl http://localhost:3000 gibi bir test yapın. Hedef IP/port doğru mu, servis sadece 127.0.0.1’e mi bağlı, güvenlik duvarı trafiği kesiyor mu kontrol edin.

Performans dalgalanması: Aynı tüneli birden fazla “connector” ile çoğaltmak (yük devretme) mümkün. Kritik servislerde tüneli iki farklı makinede çalıştırarak kesintiye dayanıklılığı artırabilirsiniz.

Ne Zaman Tercih Etmelisiniz?

Cloudflare Tunnel; ev lab ortamları, küçük ekiplerin dahili araçları, müşteri demosu, staging ortamları ve port açmanın kurumsal politikalarla engellendiği senaryolarda çok iyi çalışır. “Hızlıca yayınla, sonra erişimi kilitle” yaklaşımı için idealdir. Buna karşın çok özel ağ topolojileri, L4 seviyesinde özel protokoller veya uçtan uca sertifikalı mTLS gibi gereksinimler varsa tasarımı biraz daha detaylı düşünmek gerekir.

Sonuç

Cloudflare Zero Trust + Tunnel ikilisi, klasik port yönlendirme yöntemini büyük ölçüde gereksiz kılıyor. En önemli kazanım, uygulamayı internete açmadan erişilebilir hale getirirken kimlik doğrulama ve politika katmanını işin merkezine koyması. Bir kez kurduktan sonra yeni servis eklemek de oldukça pratik: yalnızca yeni bir hostname ve hedef servis tanımlıyorsunuz, gerisini tünel taşıyor.

Ev Ağında DNS-over-HTTPS (DoH) Kurulumu: Pi-hole + Unbound ile Reklamsız ve Daha Güvenli DNS

DNS neden hâlâ önemli?

İnternette bir siteye girdiğinizde tarayıcınız önce alan adını (ör. ornek.com) bir IP adresine çevirir. Bu çeviri işlemini DNS yapar. Sorun şu: Klasik DNS trafiği çoğu ağda şifresizdir ve hem ISS düzeyinde hem de aynı ağdaki kötü niyetli bir kişi tarafından gözlemlenebilir. Ayrıca reklam, izleyici ve zararlı alan adlarını engellemek için merkezi bir DNS filtreleme yaklaşımı, tüm cihazlarda tek tek eklenti kurmaktan daha temiz bir çözüm sunar.

Bu rehberde ne kuruyoruz?

Bu “How-To” yazısında ev/Ofis ağında Pi-hole ile reklam/izleyici alan adlarını engelleyen bir DNS filtresi, Unbound ile yerel recursive DNS çözümleyici ve dışarıya çıkarken DNS-over-HTTPS (DoH) kullanarak şifreli DNS trafiği kuracağız. Hedef: ağdaki tüm cihazlar için daha hızlı, daha gizli ve daha az reklamlı bir deneyim. Kurulum örnekleri Debian/Ubuntu tabanlı bir mini PC veya Raspberry Pi üzerinde ilerleyecek.

Ön koşullar

Donanım: Raspberry Pi 3/4 veya düşük güç tüketimli bir mini PC idealdir. Yazılım: Debian/Ubuntu türevi bir Linux, root/sudo erişimi. Ağ: Cihaza statik IP atamanız önerilir (ör. 192.168.1.2). Ayrıca modem/router arayüzüne girip DHCP DNS ayarını değiştirebilmeniz gerekir.

1) Pi-hole kurulumu

Pi-hole kurulumunu resmi script ile yapmak en pratik yöntemdir. Sunucunuzda terminali açın ve güncelleme sonrası kurulumu başlatın:

Komutlar:
sudo apt update && sudo apt upgrade -y
curl -sSL https://install.pi-hole.net | bash

Kurulum sihirbazında ağ arayüzünü seçin, statik IP önerisini kabul edin ve yönetim paneli için parolayı not edin. Kurulum sonunda Pi-hole web paneli genellikle http://cihaz-ip/admine üzerinden erişilir. İlk etapta upstream DNS olarak geçici bir sağlayıcı seçebilirsiniz; birazdan bunu Unbound’a yönlendireceğiz.

2) Unbound ile yerel recursive DNS

Unbound, sorguları doğrudan kök DNS sunucularına kadar takip ederek çözen yerel bir recursive çözümleyicidir. Böylece tek bir harici DNS sağlayıcısına bağımlılığınız azalır ve önbellek avantajı elde edersiniz:

Kurulum:
sudo apt install unbound -y

Pi-hole ile çakışmaması için Unbound’u yerelde farklı bir portta çalıştırmak iyi bir pratiktir. Örnek bir Unbound yapılandırması oluşturun:

Dosya: /etc/unbound/unbound.conf.d/pi-hole.conf
İçerik:
server:
  verbosity: 0
  interface: 127.0.0.1
  port: 5335
  do-ip4: yes
  do-udp: yes
  do-tcp: yes
  root-hints: "/var/lib/unbound/root.hints"
  cache-min-ttl: 300
  cache-max-ttl: 86400
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes

Root hints dosyasını indirip servisi başlatın:

Komutlar:
sudo curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
sudo systemctl enable --now unbound
sudo systemctl restart unbound

3) DoH katmanı: şifreli DNS çıkışı

Burada iki yaklaşım var: (A) Unbound’u doğrudan recursive kullanmak ve sadece “dış DNS sağlayıcıya” gitmemek; (B) Mutlaka bir sağlayıcıya gidecekseniz bunu DoH ile yapmak. Bu yazıda pratikliği nedeniyle cloudflared (DoH proxy) örneğini kullanacağız. Böylece Pi-hole → Unbound yerine Pi-hole → DoH proxy veya Unbound → DoH proxy senaryosu kurulabilir. En yaygın kullanım, Pi-hole’un upstream DNS’ini DoH proxy’ye vermektir.

cloudflared kurulumu (Debian/Ubuntu):
sudo apt install cloudflared -y

cloudflared’ı yerelde DNS proxy olarak çalıştırın (ör. 127.0.0.1:5053):

Komut:
sudo cloudflared proxy-dns --address 127.0.0.1 --port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

Bunu kalıcı servis yapmak için dağıtımınıza uygun systemd birim dosyası oluşturabilir veya cloudflared paketinin servis seçeneklerini kullanabilirsiniz. Mantık basit: DNS sorguları yerelden çıkar, HTTPS içinde şifrelenmiş şekilde DoH sağlayıcısına gider.

4) Pi-hole’u Unbound veya DoH’a yönlendirme

Pi-hole yönetim panelinde Settings > DNS bölümüne gidin. Burada hazır DNS sağlayıcılarını kapatıp Custom (IPv4) alanına bir upstream tanımlayın:

Seçenek 1 (Recursive): 127.0.0.1#5335 (Unbound)
Seçenek 2 (DoH): 127.0.0.1#5053 (cloudflared)

İkisini aynı anda kullanacaksanız mimariyi netleştirin: ya Pi-hole doğrudan Unbound’a gider (en bağımsız yaklaşım), ya Pi-hole doğrudan DoH proxy’ye gider (en basit şifreleme). “Unbound + DoH” birlikte de yapılabilir; ancak yapılandırma karmaşıklığı artar ve hata ayıklamak zorlaşır.

5) Router/DHCP ayarı: tüm ağa yayma

Amaç, ev ağındaki tüm cihazların DNS olarak Pi-hole’u kullanmasıdır. Router arayüzünde DHCP DNS sunucusunu Pi-hole IP adresi (ör. 192.168.1.2) yapın. Alternatif olarak DHCP’yi Pi-hole’un yönetmesine izin verebilirsiniz; fakat çoğu ev ağında router DHCP’si üzerinden DNS dağıtmak daha sorunsuzdur.

Test ve doğrulama

İstemci cihazınızda DNS sunucusunun Pi-hole’a döndüğünü kontrol edin. Ardından Pi-hole panelinde Query Log akışını izleyin. DoH doğrulaması için cloudflared loglarını takip edebilir veya dış DNS sorgularınızın 443 portu üzerinden çıktığını ağ izleme araçlarıyla gözlemleyebilirsiniz. Bir başka pratik test: reklam ağırlıklı bir sitede sayfa yükleme süreleri ve reklam sayısı belirgin biçimde azalmalıdır.

Sık karşılaşılan sorunlar

İnternet gidiyor, DNS çözemiyor: Router’da hâlâ ikinci DNS olarak ISS’nin DNS’i kalmış olabilir; cihazlar bazen onu seçer. DHCP DNS alanında yalnızca Pi-hole IP’si kaldığından emin olun.
Bankacılık/akış servisleri bozuldu: Bazı engelleme listeleri agresif olabilir. Pi-hole’da ilgili alan adını whitelist’e alın veya listeyi değiştirin.
DoH proxy çalışmıyor: 5053 portunu başka bir servis kullanıyor olabilir; portu değiştirip Pi-hole’daki custom upstream’i güncelleyin.

Sonuç

Pi-hole ile ağ genelinde reklam ve izleyici engellemek, günlük internet deneyimini gözle görülür şekilde iyileştirir. Üstüne Unbound ile recursive çözümleme eklediğinizde daha bağımsız ve tutarlı bir DNS altyapısı elde edersiniz. DoH kullanımı ise DNS trafiğini şifreleyerek ağdaki pasif izlemeyi zorlaştırır. Bu üçlüden hangisini seçeceğiniz ihtiyaçlarınıza bağlı; ancak ev ağı için “Pi-hole + DoH” en hızlı kazanım sağlayan, “Pi-hole + Unbound” ise en bağımsız yaklaşım olarak öne çıkar.