DEV Community: Hakan İSMAİL

Local LLM Ops: Building an Observable, GPU-Accelerated AI Cloud at Home with Docker & Grafana

Hakan İSMAİL — Fri, 13 Feb 2026 19:50:35 +0000

Why I Built My Own Local AI Stack: Prioritizing Privacy & ROI

Integrating AI into a development workflow usually starts with a compromise: you either send your proprietary code to a third-party API (risking Data Privacy and Compliance) or you watch your "pay-per-token" bill spiral out of control (Operational Overhead).

As a Systems Administrator, I prefer a third option: Data Sovereignty. I wanted a private, secure, and fully observable AI environment, eliminating data leak risks (GDPR/KVKK compliance) while achieving significant Long-term ROI by running on my own hardware (Arch Linux + NVIDIA RTX 3050 Ti).

The real challenge wasn't just downloading an LLM; it was engineering a Scalable AI Infrastructure that runs efficiently on consumer hardware. I'm documenting how I orchestrated this microservices-based stack with Docker Compose, optimized Resource Management for limited VRAM, and established Full-Stack Observability with Grafana and Prometheus.

Scalable Microservices Architecture

I went with a modular, containerized approach to ensure internal Scalability and keep the host system clean:

Inference Management: Ollama
Secure Hardware Integration: NVIDIA Container Toolkit
User Experience (UX): OpenWebUI (for a polished RAG-capable interface).
The Observability Layer:
- NVIDIA DCGM Exporter for real-time hardware telemetry.
- Prometheus & Grafana for SLA monitoring and data retention.

Infrastructure & GPU Passthrough

Before deploying the containers, we must ensure the host operating system (Arch Linux in my case) allows Docker to access the GPU hardware. This is not enabled by default.

1.1 The Prerequisites: NVIDIA Container Toolkit

The bridge between Docker containers and the physical GPU is the NVIDIA Container Toolkit. Without this, the containers would only see the CPU, resulting in painfully slow inference speeds (0.5 tokens/sec).

Since I am running Arch Linux, the setup was straightforward:

# Install the toolkit
sudo pacman -S nvidia-container-toolkit

# Configure the Docker daemon to use the NVIDIA runtime
sudo nvidia-ctk runtime configure --runtime=docker

# Restart Docker to apply changes
sudo systemctl restart docker

To verify the passthrough is working, I ran a quick ephemeral container. If nvidia-smi prints the GPU stats inside Docker, we are green.

docker run --rm --gpus all nvidia/cuda:12.4.1-runtime-ubuntu22.04 nvidia-smi

Container Orchestration

I believe in "defining once, running everywhere." Instead of running disparate docker run commands, I defined the entire stack in a single docker-compose.yml file.

This file handles network isolation (creating a private ai-net), volume persistence (so our chat history isn't lost on reboot), and most importantly, GPU resource reservation.

Here is the complete configuration:

services:
  # 🧠 1. AI ENGINE: Ollama
  # This is the backend that runs the LLM inference.
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_storage:/root/.ollama
    # Critical: This section reserves the NVIDIA GPU for this container
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: unless-stopped
    networks:
      - ai-net

  # 💻 2. INTERFACE: OpenWebUI
  # A user-friendly frontend that connects to Ollama.
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - openwebui_storage:/app/backend/data
    depends_on:
      - ollama
    restart: unless-stopped
    networks:
      - ai-net

  # 🕵️ 3. METRICS EXPORTER: NVIDIA DCGM
  # This container scrapes GPU metrics (Temp, Power, Utilization).
  dcgm-exporter:
    image: nvidia/dcgm-exporter:latest
    container_name: dcgm-exporter
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    environment:
      - DCGM_EXPORTER_NO_HOSTNAME=1
    ports:
      - "9400:9400"
    restart: unless-stopped
    networks:
      - ai-net

  # 🗄️ 4. TIME-SERIES DB: Prometheus
  # Collects the metrics exposed by dcgm-exporter.
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
    restart: unless-stopped
    networks:
      - ai-net

  # 📊 5. VISUALIZATION: Grafana
  # Displays the metrics in a dashboard.
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3001:3000"
    volumes:
      - grafana_storage:/var/lib/grafana
    restart: unless-stopped
    networks:
      - ai-net

volumes:
  ollama_storage:
  openwebui_storage:
  prometheus_data:
  grafana_storage:

networks:
  ai-net:
    driver: bridge

Prometheus Scraper Configuration

Prometheus needs to know exactly where to pull metrics from. I configured a 5-second scrape_interval. While 15s-30s is more common for production, a 5s interval is better for a local lab where we want to track immediate power spikes during token generation.

global:
  scrape_interval: 5s # Scrape often for real-time visibility

scrape_configs:
  - job_name: "gpu-metrics"
    static_configs:
      - targets: ["dcgm-exporter:9400"]

With the configuration files in place, a single command boots the entire cloud infrastructure:

docker compose up -d

Resource Management: Optimizing for 4GB VRAM

The infrastructure setup is the foundation, but Cost-Sensitive Resource Allocation, selecting a model that runs effectively on limited hardware, is where the real value lies. I optimized this build for an NVIDIA RTX 3050 Ti with 4GB of VRAM.

The VRAM Constraint

Popular models like DeepSeek R1 or Llama 3 (8B) usually require 5GB to 6GB of VRAM just to load. Offloading these models to system RAM via PCIe on a 4GB card results in unusable generation speeds, often dropping to 1-2 tokens per second.

I needed a model that fits entirely within the 4GB ceiling while remaining capable for coding tasks.

Choosing the right model: Qwen 2.5 Coder (3B)

I used Hugging Face to cross-reference benchmarks and VRAM requirements for various 1B, 3B, and 7B models. After evaluating the trade-offs between parameter count and inference speed, I settled on Qwen 2.5 Coder (3B Instruct).

Since it only occupies roughly 2.2 GB of VRAM, it leaves enough headroom for the context window without triggering a bottleneck. It's significantly faster than larger models that would force the system to swap to system RAM.

I specifically used the Instruct version; it's much better at actual code logic than the base model.

You can pull it with:

docker exec -it ollama ollama run qwen2.5-coder:3b

Verifying Telemetry

Once the containers are up, query the DCGM exporter directly to ensure the GPU is communicating correctly with Docker:

curl http://localhost:9400/metrics

You'll see keys like DCGM_FI_DEV_GPU_TEMP and DCGM_FI_DEV_POWER_USAGE. Now we need to visualize these in Grafana.

Dashboard Configuration

Since Grafana and Prometheus are on the same Docker network (ai-net), they communicate via container names.

Log in to Grafana (http://localhost:3001, default admin/admin).
Add Prometheus as a data source and use the URL: http://prometheus:9090.

Import Dashboard ID 12239 (NVIDIA DCGM Exporter).

The result is a comprehensive command center for your local AI hardware.

Real-World Business Value & Metrics

I tested the stack with a typical DevOps automation request:

"Write a bash script that detects zombie processes and logs the action."

Full-Stack Observability Analysis

Checking the Grafana dashboard during inference gives the ultimate validation of the setup, proving System Reliability:

VRAM Efficiency: Usage peaked at 2.8 GB. This confirms that the 3B model is the sweet spot: fluent generation with Zero Licensing Overhead.
Scalability Benchmarks: ~438 prompt tokens/s and ~10 generation tokens/s. Proving that high-performance AI is possible without cloud dependency.

Operational Sustainability: The GPU pulled a steady 20W and stayed at 64°C. This is a Low-Cost/High-Performance local solution.

Summary: Driving Innovation Internally

Building a local AI stack isn't just a technical exercise; it's a strategic move for Business Continuity and Data Security. By combining Docker, NVIDIA's toolkit, and a comprehensive observability layer, I've created a dev environment that's both secure and cost-efficient, proving that significant AI ROI can be achieved on existing on-premise hardware.

Dijital Mahremiyeti Geri Kazanmak: Pi-hole, Unbound ve Tailscale ile Gözetimsiz İnternet

Hakan İSMAİL — Wed, 28 Jan 2026 15:44:13 +0000

Giriş

Bir Sistem Mühendisi için en büyük israf, atıl duran işlem gücüdür. Çekmecemde uzun süredir "kış uykusunda" olan Raspberry Pi 3'e baktığımda, sadece eski bir devre kartı değil, potansiyel bir ağ savunma hattı görüyordum.

İnternet Servis Sağlayıcımın (ISS) şeffaf olmayan DNS yönlendirmeleri ve evdeki Akıllı TV’min, ben kullanmasam bile arka planda Google sunucularına telemetri verisi gönderme çabası artık bardağı taşırmıştı.

Ev ağım, benim kontrolümde olması gereken özel bir alanken, adeta büyük şirketlerin veri madenciliği sahasına dönüşmüştü. Çözüm, o çekmecedeki atıl donanımı aktif ve tavizsiz bir ağ geçidine dönüştürmekte yatıyordu.

Amacım netti: Kurumsal ağlarda uyguladığımız "Zero Trust" prensibini ev ölçeğine taşımak. Hiçbir cihazın, benim iznim olmadan "Big Tech" sunucularına veri göndermediğinden emin olmak ve bunu yaparken internet performansından ödün vermemek.

Bu yazıda, basit bir "reklam engelleyici kur geç" rehberinin ötesine geçeceğiz. Terminali açıp, sistemin derinliklerine inerek şunları nasıl yaptığımı anlatacağım:

Google veya Cloudflare'a güvenmek yerine, kendi Recursive DNS (Unbound) sunucumu yapılandırarak aracıları nasıl ortadan kaldırdım?
İnatçı ISS modeminin elinden DHCP yetkisini alarak ağ yönetimini nasıl tamamen kendi kontrolüme geçirdim?
Ve en önemlisi: CGNAT arkasında olmama rağmen, bu güvenli kaleye Tailscale ile dünyanın her yerinden nasıl şifreli bir tünel açtım?

Eski bir donanımı, modern bir güvenlik cihazına (Network Appliance) dönüştürme hikayesi başlıyor.

Araç Çantası (The Stack)

Bu projeyi hayata geçirmek için bir süper bilgisayara veya pahalı firewall cihazlarına ihtiyacınız yok. DNS sorguları ve VPN tünelleme işlemleri şaşırtıcı derecede hafiftir; bu yüzden "atıl donanım" felsefesi burada mükemmel işler.

1. Donanım (Elimdeki Envanter)

Bu proje için özel bir alışveriş yapmadım. Tamamen "çekmeceden ne çıkarsa" prensibiyle ilerledim.

Kart: Raspberry Pi 3 Model B
Neden Bu? Çünkü elimde boşta duran kart buydu. Ancak şansıma, dahili Ethernet portuna sahip olması DNS sunucusu için büyük avantaj. Wi-Fi gecikmesini (latency) veya sinyal kopmalarını bir DNS sunucusunda asla istemezsiniz. Kablo kararlılıktır.
Depolama: MicroSD Kart (Class 10)

Alternatifler

Elinizde illaki Raspberry Pi 3 gibi bit kart olmak zorunda değil. İşte diğer güzel alternatifler:

Raspberry Pi Zero W / 2W: Çok daha ucuz ve az güç tüketir. (Ancak Micro-USB Ethernet adaptörü kullanmanızı şiddetle öneririm).
Eski Bir Laptop: Ekranı kırık, bataryası bitik eski dizüstü bilgisayarınız harika bir sunucu olur. Üstelik dahili bataryası "UPS" (Kesintisiz Güç Kaynağı) görevi görür.
Orange Pi / Banana Pi: Piyasadaki Raspberry Pi klonlarının çoğu bu proje için fazlasıyla yeterlidir.
Always-Free Cloud VPS: Oracle Cloud veya Google Cloud'un ücretsiz katmanlarında (Free Tier) bir Ubuntu sunucu açıp, ev ağınıza Tailscale "Subnet Router" olarak bağlayabilirsiniz. (Donanım maliyeti: 0₺).

2. Yazılım (Software)

Burada "bloat"tan (gereksiz şişkinlikten) kaçınan, Unix felsefesine uygun (bir şeyi yap ve iyi yap) araçları seçtim:

İşletim Sistemi: Raspberry Pi OS Lite (64-bit).
Masaüstü ortamı (GUI) yok, sadece terminal. Bir sunucunun monitöre ihtiyacı yoktur. Headless kurulum yapacağız.
Pi-hole: Ağ seviyesinde reklam ve takipçi engelleyici (DNS Sinkhole).
Unbound: Recursive DNS çözümleyici. Google'a veya diğer DNS sağlayıcılarına güvenmek yerine kendi doğrulamamızı yapacağız.
Tailscale: WireGuard tabanlı Mesh VPN. CGNAT duvarlarını delmek ve dışarıdan eve güvenli tünel açmak için.

🏗️ Bölüm 1: Temeli Atmak (İşletim Sistemi Kurulumu)

Bir sunucu kuruyorsak, ilk kural şudur: GUI (Grafik Arayüz) gereksiz yük ve güvenlik açığıdır. Sunucunun monitörü olmaz, terminali olur. Bu yüzden "Raspberry Pi OS Lite (64-bit)" sürümünü tercih ettim.

Adım 1: İmajı Yazdırmak

Raspberry Pi kullandığım için işim nispeten kolaydı. Resmi Raspberry Pi Imager yazılımı, sadece imajı karta yazmakla kalmıyor, "OS Customization" özelliğiyle SSH ayarlarını daha kartı cihaza takmadan yapmamızı sağlıyor.

Cihaz Seçimi: Raspberry Pi 3.
İşletim Sistemi: Raspberry Pi OS (Other) -> Raspberry Pi OS Lite (64-bit).
Neden 64-bit? Pi 3, 64-bit mimariyi destekler. MongoDB gibi bazı modern veritabanı ve servisler artık 32-bit desteğini kesiyor. Geleceğe yatırım yapmak iyidir.

3. Kritik Adım: "Headless" Hazırlık (OS Customization)

Bir sunucu kurarken monitör, klavye ve fare aramakla vakit kaybetmek istemeyiz. Amacımız "Tak ve Çalıştır" (Plug and Play) değil, "Tak ve Yönet" olmalı.

Raspberry Pi Imager'ın yeni sürümleri, "OS Customization" özelliği sayesinde işletim sistemini daha karta yazmadan konfigüre etmemize olanak tanıyor. Bu sayede Pi ilk açıldığı anda ağa bağlanıyor, SSH kapısını açıyor ve bizim bağlanmamızı bekliyor.

İmajı yazdır ("Write") demeden önce, o sihirli ayar menüsünü açarak şu konfigürasyonları yaptım:

Hostname (Cihaz Adı): Cihaza ağda tanınacağı kimliği verdim: pi-hole. (Siz dns-server veya yaratıcı başka bir isim seçebilirsiniz).
Enable SSH (SSH'ı Aç): Bu adım hayati önem taşıyor. Cihaza monitör bağlamayacağımız için tek iletişim yolumuz bu olacak. "Use password authentication" seçeneğini aktif ettim.
Username & Password: Buraya kendime özel, kullanıcı adı ve güçlü bir şifre tanımladım.
Wireless LAN (Wi-Fi): Burayı bilinçli olarak boş bıraktım. Bir DNS sunucusu kablosuz ağın kararsızlığına emanet edilemez. Ethernet kablosu takılı olacağı için Wi-Fi konfigürasyonuna ihtiyacımız yok.

Bu ayarları kaydedip "WRITE" butonuna bastığımda, elimde sadece bir işletim sistemi değil, tamamen benim kurallarımla yapılandırılmış, göreve hazır bir sunucu kartı vardı.

Laptop veya Mini PC Kullananlar İçin Not

Eğer bu projeyi eski bir laptop veya Intel NUC gibi bir x86 cihazda yapacaksanız süreç biraz daha geleneksel:

Hafif bir dağıtımın ISO dosyasını indirin (Örn: Debian Server veya Ubuntu Server).
Rufus veya BalenaEtcher kullanarak USB belleğe yazdırın.
Cihazı USB'den başlatıp kurulumu tamamlayın.

Adım 2: İlk Önyükleme (First Boot) ve Ağ Taraması

SD kartı Pi'ye taktım, Ethernet kablosunu modeme bağladım ve gücü verdim. Işıklar yanıp sönmeye başladı ama kritik bir eksiğimiz var: Monitörsüz bir cihazın IP adresini nasıl bulacağız?

Bunun için iki yolumuz var.

Yöntem 1: Klasik Yol (Modem Arayüzü)
En garantili yöntem, ağın patronuna yani modeme sormaktır. 192.168.1.1 (veya modeminizin IP'si neyse) adresinden arayüze giriş yapıp "Bağlı Cihazlar" (Connected Devices) listesine baktığınızda, Raspberry Pi'nin sessizce bir IP aldığını göreceksiniz.

Yöntem 2: Terminal Yolu (Nmap Taraması)
Eğer modem şifresini hatırlamıyorsanız veya tarayıcıyla uğraşmak istemiyorsanız, terminalden ağı taramak çok daha hızlı bir yöntemdir.

Ağdaki cihazları ve üreticilerini listelemek için şu komutu kullandım:

# -sn: Port taraması yapma, sadece ping at (Ping Scan)
sudo nmap -sn 192.168.1.0/24

Ve işte aradığım cevap karşımda:

Nmap scan report for PC192.168.1.4.station (192.168.1.4)
Host is up (0.0040s latency).
MAC Address: B8:27:EB:4B:79:A8 (Raspberry Pi Foundation)

Terminal, üreticisi "Raspberry Pi Foundation" olan cihazın 192.168.1.4 adresinde olduğunu raporladı.

Bağlantı Anı

Hedef belli olduğuna göre, o büyülü an geldi. SSH ile sisteme giriş yapıyoruz:

ssh hakan@192.168.1.4

İçerideyim. 🎉

Ancak titiz bir Linux kullanıcısı olarak, ilk iş htop ve systemd-analyze komutlarını çalıştırdığımda gördüğüm manzara beni tatmin etmedi. Kullanmadığım donanımlar için çalışan servisler ve arka plandaki gereksiz yükler (bloatware), açılış süresini uzatıyordu.

hakan@pi-hole:~ $ systemd-analyze
Startup finished in 5.988s (kernel) + 52.832s (userspace) = 58.821s 
multi-user.target reached after 22.577s in userspace.

Sıradaki adımda, elime dijital süpürgeyi alıp bu sistemi temizlemem ve sunucu kondisyonuna getirmem gerekiyordu.

🧹 Bölüm 2: "Lite" Yeterince Hafif Değildir (System Hardening)

Sisteme ilk bağlandığımda htop ve systemd-analyze blame komutlarını çalıştırdım. Gördüğüm manzara, bir sistem mühendisi için kabul edilemezdi. Boot süresi 1 dakikaya yakındı ve kullanmadığım donanımlar için servisler çalışıyordu.

Raspberry Pi OS Lite, genel uyumluluk için "herkese her şey" mantığıyla gelir. Ancak bizim senaryomuzda Headless (Monitörsüz) ve Kablolu (Ethernet) bir DNS sunucusu kuruyoruz. Fazlalıklara yer yok.

İşte uyguladığım "diyet" programı:

1. Baş Şüpheli: Cloud-Init

En büyük gecikmeyi (yaklaşık 50 saniye) cloud-init servisi yaratıyordu. Bu servis, cihaz bir bulut ortamında (AWS, Azure vb.) çalışıyorsa metadata çekmeye yarar. Benim Pi'm masamın üstündeydi, bulutta değil.

# Servisleri durdur
sudo systemctl disable --now cloud-init-local.service cloud-config.service cloud-final.service

# Paketi ve kalıntılarını sistemden kazı
sudo apt purge -y cloud-init
sudo rm -rf /etc/cloud /var/lib/cloud

2. Gereksiz Donanım Servisleri

Sunucumda hoparlör, bluetooth kulaklık veya Wi-Fi kullanmayacağım. Bunları kapatmak hem RAM kazandırır hem de saldırı yüzeyini (attack surface) daraltır.

# Bluetooth ve Ses (ALSA) servislerini kaldır
sudo apt purge -y bluez bluez-firmware alsa-utils

# ModemManager (3G/4G dongle kullanmayacaksanız gereksiz)
sudo apt purge -y modemmanager

# Wi-Fi Servisi (Ethernet kullandığım için)
sudo systemctl disable --now wpa_supplicant
sudo systemctl mask wpa_supplicant

3. Avahi (mDNS)

Sabit IP kullanacağım ve DNS yönetimini kendim yapacağım için raspberrypi.local gibi mDNS yayınlarına (Bonjour) ihtiyacım yoktu.

sudo systemctl disable --now avahi-daemon
sudo apt purge -y avahi-daemon

4. Son Temizlik, Güncellemeler ve Yeniden Başlatma

Sistemi gereksiz servislerden arındırdık. Sistemde yaptığım cloud-init ve diğer temizliklerden sonra geriye, artık hiçbir işe yaramayan "yetim" paketler (orphan packages) kalmıştı. Terminal bana bunları temizlememi öneriyordu, ben de öneriye uydum:

sudo apt autoremove -y

Artık elimizde, üzerine bina inşa edebileceğimiz tertemiz bir temel var. Bu temeli en son güncellemeler ile güçlendirelim:

sudo apt update && sudo apt upgrade -y

Sistemi yeniden başlatıp sonuca bakalım:

sudo reboot now

Yeni sonuçlar ise daha tatmin edici:

hakan@pi-hole:~ $ systemd-analyze
Startup finished in 9.046s (kernel) + 21.894s (userspace) = 30.941s 
multi-user.target reached after 20.891s in userspace.

⚓ Sabit IP (Static IP) Ayarı

Temizlik bitince, ağdaki yerimizi sağlamlaştırmamız gerekiyordu. DNS sunucusunun IP adresi değişirse tüm evin interneti kesilir.

Modern Raspberry Pi OS sürümleri NetworkManager kullanır. IP sabitlemek için en temiz yol nmtui aracıdır.

Terminale sudo nmtui yazdım.
Edit a connection -> netplan-eth0.
IPv4 CONFIGURATION -> Manual.
Addresses: 192.168.1.4/24 (Siz kendi ağınıza göre belirleyin).
Gateway: 192.168.1.1 (Modem IP'si).
DNS Servers: Şimdilik 1.1.1.1 (Kurulum bitince 127.0.0.1 yapacağız).
(Opsiyonel) IPv6 CONFIGURATION -> Disabled (Eğer IPv6 kullanmıyorsanız yapabilirsiniz).

Sistemi yeniden başlatabiliriz:

sudo reboot now

🛡️ Bölüm 3: Savunma Hattı (Pi-hole & Unbound)

Temiz bir işletim sistemimiz var. Şimdi onu bir ağ cihazına (Network Appliance) dönüştüreceğiz. Buradaki stratejimiz iki katmanlı:

Pi-hole: Reklamları ve izleyicileri çöpe atan bekçi.
Unbound: Sorguları Google'a sormak yerine, doğrudan internetin kök sunucularından (Root Servers) öğrenen çözümleyici.

Adım 1: Pi-hole Kurulumu (Bekçi)

Pi-hole kurulumu, Linux dünyasının en pratik scriptlerinden birine sahip. Terminale şu komutu yapıştırarak kurulum sihirbazı başlattım:

sudo curl -sSL https://install.pi-hole.net | bash

Sihirbaz sırasında dikkat ettiğim kritik noktalar:

Static IP: Burada size basit bir uyarı veriyor. Cihazın IP'sinin statik olması gerektiğini özellikle belirtiyor. Biz bunu önceki adımda tamamladık.
Upstream DNS: Kurulum sırasında herhangi birini (örn: Google) seçebilirsiniz, birazdan bunu değiştireceğiz.
Bloclist: Burada pihole un kullandığı 3. pari filtreler için bildirge var. Ben kullanmak istediğim için 'yes'i seçtim.
Query Logging: Eğer aşırı gizlilik isterneniz 'no' yu seçebilirsiniz. Ben 'yes' ile devam ettim.
Privacy mode for FTL: Kullanıcıların hangi siteye sorgu gönderdiğini web arayüzünde göstermek için Show Everything ile devam ettim.

Adım 2: Erişim ve Yetkilendirme (Post-Install)

Kurulum sihirbazı bitti ama terminalden henüz çıkmıyoruz. Özellikle Pi-hole v6 mimarisiyle gelen önemli bir değişikliği yapılandırmamız gerekiyor.

CLI için API Yetkilendirmesi
Pi-hole v6, CLI (Komut Satırı) komutları için artık doğrudan veritabanı manipülasyonu yerine yeni API'sini kullanıyor. Bu güvenlik açısından harika olsa da, her komut girdiğimizde bizden parola istemesi (API authentication) can sıkıcı olabilir.

Bir sistemci "sudo" yazmaya alışkındır ama gereksiz parola girmekten nefret eder. Kendi kullanıcımızı pihole grubuna ekleyerek, terminalden parola girmeden yönetim komutlarını çalıştırabilme yetkisi verelim:

# Mevcut kullanıcımızı ($USER), pihole grubuna ekle
sudo usermod -aG pihole $USER

Not: Bu değişikliğin aktif olması için SSH oturumunu kapatıp (exit) tekrar bağlanmanız gerekebilir.

Web Arayüzü Şifresi
Pi-hole kurulum sırasında rastgele bir şifre atar. Web arayüzüne (http://192.168.1.4/admin) her girişte loglara bakmak için o karmaşık şifreyi aramak istemeyiz.

Aklımızda kalacak güçlü bir şifre belirleyelim:

pihole setpassword

Komutu girdikten sonra yeni şifrenizi yazın (ekranda görünmeyecektir) ve onaylayın.

Artık hem terminalde hem de web arayüzünde tam yetkiliyiz. Sıra geldi DNS sorgularını özgürleştirmeye: Unbound Kurulumu.

Adım 3: Unbound Kurulumu (Özgürlük)

İşte işin mühendislik kısmı burada başlıyor. Çoğu kullanıcı Pi-hole'u kurar ve DNS olarak Google (8.8.8.8) kullanmaya devam eder. Bu, reklamları engeller ama gizliliğinizi korumaz. Verileriniz hala Google'a akar.

Biz Recursive DNS kuracağız. Yani aracıları aradan çıkaracağız.

sudo apt install unbound -y

Adım 3: Konfigürasyon ve Hız Optimizasyonu 🚀

Unbound'un varsayılan ayarları güvenlik odaklıdır ancak biraz hantaldır. Benim buradaki amacım ise gecikme hissini biraz da olsa azaltmak.

Bunun için Unbound konfigürasyon dosyasını oluşturdum:

sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

Ve içine şu optimize edilmiş ayarları girdim. (Buradaki serve-expired parametresi sihirli dokunuştur):

server:
    # Log seviyesi (Hata ayıklama gerekmedikçe 0)
    verbosity: 0
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # IPv6'yı kapat (Ev ağında gecikme yaratabilir)
    do-ip6: no

    # Root Hints dosyası
    root-hints: "/var/lib/unbound/root.hints"

    # Gizlilik Ayarları
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes

    # --- PERFORMANS OPTİMİZASYONLARI ---

    # Süresi bitmiş kayıtları (expired) anında sun, arkada güncelle
    serve-expired: yes
    serve-expired-ttl: 86400  # 1 gün

    # Cache boyutlarını Pi 3'ün RAM'ine göre ayarla
    msg-cache-size: 50m
    rrset-cache-size: 100m

    # İşlemci çekirdeklerini kullan
    num-threads: 2

Dosyayı kaydettikten sonra kök sunucuları resmi kaynaktan (InterNIC) en güncel Root Hints listesini çekip Unbound'un beklediği klasöre koyalım ve izinlerini sağlama alalım:

# Dosyayı indir
sudo wget -O /var/lib/unbound/root.hints https://www.internic.net/domain/named.root

# İzinleri ayarla (Unbound kullanıcısının okuyabildiğinden emin olalım)
sudo chown unbound:unbound /var/lib/unbound/root.hints

Dosyayı kaydedip (CTRL+X, Y, Enter) Servisi yeniden başlatalım:

sudo systemctl restart unbound

Ayrıca unbound servisi her açılışta otomatik açılacak şekilde ayarlayalım:

sudo systemctl enable unbound

Adım 4: Büyük Buluşma (Entegrasyon)

Artık Pi-hole'a "Google ile konuşma, yan odadaki Unbound ile konuş" dememiz lazım.

Sabit IP (Static IP) Ayarı Yaptığımızda DNS Servers kısmına 1.1.1.1 vererek DNS sunucusunu cloudflare olarak ayarlamıştık. Şimdi o ayarı değiştirerek 127.0.0.1 yapıp dns sunucusunu yerel cihaz olarak değiştirdim.
Web tarayıcısından http://192.168.1.4/admin adresine girdim.
Settings > DNS sekmesine geldim.
Sağdaki hazır listelerin (Google, OpenDNS vb.) hepsinin tikini kaldırdım.
Custom 1 (IPv4) kutusuna şunu yazdım: 127.0.0.1#5335.

Sonuç:
Şu anda ağımda bir reklam engelleme servisi çalışıyor ve DNS sorgularım şifreli, doğrulanmış ve aracı olmadan çözülüyor. Ancak bir sorun var: Cihazlarım (Telefon, TV) hala modemi dinliyor.

Sıradaki adımda "Ağ Yönetimini Ele Geçirme" (DHCP Handover) operasyonunu yapacağız.

⚔️ Bölüm 4: Modemi "Aptallaştırmak" (DHCP Operasyonu)

Pi-hole ve Unbound hazırdı. Normal şartlarda, modem arayüzüne girip DNS adresini 192.168.1.4 olarak değiştirmek yeterli olmalıydı.

Ancak teori ve pratik, ISS modemlerinde asla uyuşmaz.

Kullandığım modem (Vodafone H300s), çoğu ISS cihazı gibi "kilitli" bir kutuydu. DNS ayarlarını değiştirmeme izin verse bile, arka planda ikincil DNS olarak kendi sunucularını zorluyor veya bazı cihazlar (özellikle Android TV ve Chromecast) inatla modemin önerdiği DNS'e gidiyordu. Sonuç? Reklamlar sızmaya devam ediyordu.

"Kibarca" rica ettim olmadı. Ben de yönetimi zorla almaya karar verdim.

Çözüm: Modemin DHCP sunucusunu kapatmak ve IP dağıtma yetkisini Pi-hole'a vermek.

Bu yöntem iki devasa avantaj sağlar:

Garanti Yönlendirme: Pi-hole, IP dağıtırken cihazlara "Tek DNS benim, başka yere bakma" der. Kaçış yoktur.
Detaylı Analiz: Modem DHCP iken Pi-hole loglarında tüm trafiği tek bir cihazdan (Modem) geliyormuş gibi görürsünüz. Pi-hole DHCP olduğunda, hangi cihazın (iPad, TV, Laptop) hangi siteye girdiğini tek tek görebilirsiniz.

Operasyon Sırası (Dikkat!)

Ağdan kopmamak için sıralama hayati önem taşır. Önce yeni patronu (Pi-hole) devreye almalı, sonra eskisini (Modem) emekli etmelisiniz.

Adım 1: Yeni Patronu Hazırla (Pi-hole)

Pi-hole panelinde Settings > DHCP sekmesine gittim.
DHCP server enabled kutusunu işaretledim.
Range: Modeminkiyle çakışmayacak bir aralık verdim (Örn: 192.168.1.5 - 192.168.1.254).
Router (Gateway): Modemin IP adresini (192.168.1.1) girdim. Burası çok kritik, yanlış girerseniz internete çıkamazsınız.

Adım 2: Eskisini Sustur (Modem)

Modem arayüzüne girdim.
LAN / Yerel Ağ ayarlarından DHCP Sunucusu seçeneğini KAPALI (Disable) konuma getirdim.
Kaydettim.

Adım 3: Sözleşme Yenileme (Renew Leases)

Şu an ağda bir kaos yok ama cihazların hala eski "kira sözleşmeleri" (IP Lease) var. Onları yenilemek için:

Telefonun Wi-Fi özelliğini kapatıp açtım.
Bilgisayarın Ethernet kablosunu çıkarıp taktım.

Sonuç: Pi-hole panelindeki "DHCP Leases" kısmında cihazlarımın tek tek belirdiğini gördüm. Artık ağın mutlak hakimi Raspberry Pi idi. Modem ise sadece internet sinyalini içeri taşıyan "aptal" bir kutuya (Dumb Pipe) dönüşmüştü. Tam istediğim gibi.

🌍 Bölüm 5: Duvarların İçinden Tünel Açmak (CGNAT ve Tailscale)

Ev ağım artık bir kaleydi: Reklamlar giremiyor, DNS sorguları dışarı sızmıyordu. Ancak büyük bir sorunum vardı: Ben de eve giremiyordum.

Evden çıktığım anda (mobil veri veya kafe Wi-Fi'ı), ISS'mın güvenli olmayan ağına veya halka açık güvensiz ağlara mahkum kalıyordum. Eve bağlanmak için geleneksel yöntem, modemden port açmaktır. Ancak Türkiye'deki çoğu ev kullanıcısı gibi ben de CGNAT (Carrier Grade NAT) havuzundayım. Yani gerçek bir genel (public) IP adresim yok, bir apartman bloğu gibi binlerce kişiyle aynı IP'yi paylaşıyorum. Dolayısıyla dışarıdan içeriye kapı (port) açmam teknik olarak imkansız.

Çözüm? NAT Traversal (NAT Aşımı) ve Overlay Network.

Burada Tailscale devreye giriyor. Tailscale, ISS'nın karmaşık NAT duvarlarını yıkmaz (bunu yapamayız), ancak "NAT Traversal" tekniklerini kullanarak bu duvarların içinden şifreli bir tünel (WireGuard) açar.

Bu sayede ISS altyapısını kullanmaya devam ederiz ancak ISS, paketlerimizin içeriğini veya nereye gittiğini (DNS) göremez. Sadece şifreli bir veri akışı görür. Kısacası ISS'yı, veriyi sadece A noktasından B noktasına taşıyan "kör" bir taşıyıcıya (Dumb Pipe) dönüştürürüz.

Adım 1: Kurulum ve IP Yönlendirme

Headless sunucuma tek satırla Tailscale'i kurdum:

curl -fsSL https://tailscale.com/install.sh | sh

Tailscale bir "Overlay Network" (Katman Ağı) oluşturur. Ancak Linux çekirdeği varsayılan olarak üzerinden geçen trafiği (packet forwarding) engeller. Pi'nin gelen trafiği internete taşıması için çekirdek ayarlarını değiştirdim:

# IPv4 Forwarding'i aç
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
# Eğer IPv6 Kullanacaksanız:
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Adım 2: Sihirli Komut (Exit Node)

Servisi başlatırken Pi'ye "Sen artık bu sanal ağın internete çıkış kapısısın" dedim:

sudo tailscale up --advertise-exit-node

Bana verdiği linke tıklayıp cihazı hesabımla eşleştirdim.

Adım 3: Admin Onayı (Güvenlik)

Bu adım genellikle unutulur. Terminalden "ben çıkış kapısıyım" demek yetmez, Tailscale yönetim panelinden (Web) buna izin vermeniz gerekir.

Admin Paneli > Machines > pi-hole > Edit Route Settings.
Use as exit node seçeneğini aktif ettim.

Adım 4 (Opsiyonel ama Önemli): Anahtar Süresini Uzatmak (Disable Key Expiry)

Tailscale, güvenlik tedbiri olarak cihazların oturum anahtarlarını belirli aralıklarla (varsayılan 180 gün) geçersiz kılar. 7/24 çalışan bir sunucu için bu risklidir; tam ihtiyacınız olduğu anda erişiminiz kesilebilir.

Bu "baş ağrısını" yaşamamak için Pi-hole sunucumuzun oturum süresini kalıcı hale getiriyoruz:

Admin Paneli > Machines listesinden pi-hole cihazını bulun.
Sağdaki üç noktaya tıklayıp Disable Key Expiry seçeneğini işaretledik.

🎉 Sonuç: Dijital Özgürlük

Telefonumun Wi-Fi'ını kapattım, mobil veriye geçtim. Tailscale uygulamasından "Exit Node" olarak evdeki Pi'mi seçtim ve testi başlattım:

Tünel Testi (Exit Node): whatismyip.com'a girdiğimde, mobil operatörümün IP'sini değil, evimdeki fiber hattın IP'sini gördüm. Trafiğim şifreli bir tünelden eve gidiyor, oradan internete çıkıyordu.
Sanal Yerel Ağ: Tarayıcıya Pi-hole'un Tailscale IP adresini (100.x.x.x) yazdığımda, sanki evde masamda oturuyormuşum gibi yönetim paneli karşımdaydı. CGNAT engelini, sanal bir ağ katmanıyla aşmıştım.
Termux ile Tam Kontrol: Mobil telefonumdan Termux'u açıp, yine aynı Tailscale IP'sine SSH bağlantısı kurdum.

Özetle:
ISS'yi veya CGNAT'ı yok etmedik; bu fiziksel olarak imkansızdı. Ancak kurduğumuz bu yapı ile onları sadece şifreli paket taşıyan bir altyapıya indirgedik.

DNS sorgularımızı göremiyorlar (Unbound + Şifreleme).
Hangi sitelere girdiğimizi analiz edemiyorlar (VPN Tüneli).
Bize "public IP vermiyoruz, eve bağlanamazsın" diyemiyorlar (Tailscale/NAT Traversal).

Eski bir Raspberry Pi ve doğru mühendislik yaklaşımıyla; binlerce liralık kurumsal cihazların sunduğu "Zero Trust" konforunu evimize getirdik.

Çekmecenizdeki o kartı çıkarın. İnternetiniz size ait olsun.