DEV Community: Hakan İSMAİL

VMware vSAN ile Başlarken: Depolama Politikası, Kullanılabilirlik ve HOL Notları (Modül 1)

Hakan İSMAİL — Sat, 13 Jun 2026 17:36:05 +0000

Birkaç haftadır "VMware vSAN - Getting Started and Advanced Topics" başlıklı HOL (Hands-on Lab) üzerinde çalışıyorum. Bu yazı, o serinin ilk modülünden çıkardığım notların ve gözlemlerin bir dökümü. Baştan söyleyeyim: burada anlatılanlar gerçek bir üretim ortamından değil, tamamen HOL ortamından geliyor. Kendi adıma bu ayrımı net tutmak önemliydi çünkü sahadaki dinamikler ile simüle bir ortam arasında her zaman fark var. Ama bu fark, HOL'u değersiz kılmıyor; tam tersine, kavramları karşılıklı test edip yanılma maliyeti sıfır olarak görmek için iyi bir zemin.

Şimdi Modül 1'de neyle karşılaştığımı aktarayım.

Ortam Hakkında Kısa Bir Not

Lab iki siteden oluşuyor: Site A ve Site B. İlk dört modül tamamen Site A üzerinde ilerliyor. Yönetim cluster'larına dokunulmaksızın sadece workload cluster'larında çalışıyoruz. Bu ayrım, özellikle VCF (VMware Cloud Foundation) bağlamında düşününce mantıklı: yönetim katmanına gereksiz yandan temas, gerçek ortamlarda da kaçınılan bir şey.

vSAN Nedir, Neden Var?

vSAN 2014'te hayatımıza girdi. Temel fikir şu: birden fazla ESXi host'unun yerel disklerini bir araya getirip tek, merkezi olarak yönetilen bir depolama havuzu oluşturmak. Ayrı bir storage donanımına gerek kalmıyor, en azından teoride.

Bunun anlamı şu: vSAN doğrudan vSphere hypervisor'ına gömülü. Yani bir storage OS yönetmiyorsunuz, ayrı bir SAN fabric kurmuyor değilsiniz. Compute ve storage, vSphere Client üzerinden tek elden yönetiliyor. TCO açısından geleneksel storage'a kıyasla yüzde elliye varan maliyet düşüşü iddiası var. Bunu elbette ortam büyüklüğüne, lisans yapısına ve mevcut altyapıya göre ayrı değerlendirmek gerek, ama kavramsal olarak mantığı oturuyor.

Data resilience tarafında erasure coding (silme kodlaması) kullanılıyor. RAID-5 ve RAID-6 burada saf disk mirroring'e göre daha verimli kapasite kullanımı sağlıyor.

vSAN 9'da Neler Değişti?

Bu HOL, vSAN 9 üzerine kurulu. vSAN 9'da öne çıkan başlıklara bakmak istedim çünkü önceki sürümlerle karşılaştırma yapmadan nelerin "yeni" olduğunu anlamak zor.

Gerçek hayatta şunu sormak gerekir: mevcut donanımınız ESA'yı destekliyor mu? ESA'nın VMware HCL gereksinimleri daha kısıtlayıcı. Bu, HOL'da görmediğiniz ama sahaya geçince sizi ilk duraksatan şeylerden biri olabilir.

VMware Live Recovery ile DR

vSAN cluster'ları artık VMware Live Recovery entegrasyonuyla korunabiliyor. RPO 1 dakikaya kadar inebiliyormuş. Bu özellik Modül 7'de işleniyor, burada sadece genel bir bilgi olarak geçiyor.

File Services ve Kubernetes

vSAN artık Kubernetes pod'ları için file-based persistent volume destekliyor. Aynı zamanda cluster başına 500 adet file share'e kadar çıkılabiliyor (vSAN 9 ile gelen bir iyileştirme). Bu konu Modül 6'da detaylandırılıyor.

Dying Disk Handling (DDH)

ESA'da disk latency değerlerini izleyip önceden belirlenen eşik aşılırsa otomatik müdahale edebiliyor. Cache drive arızalarını da proaktif olarak yakalıyor. Bu tür şeyler production ortamında görünmez çalışmasını beklediğiniz mekanizmalar; genelde var olduğunu ancak bir sorun çıktığında fark ediyorsunuz.

Global Deduplication (Sınırlı Yayın)

OSA'da deduplikasyon alanı disk grubuyla sınırlıydı. ESA ile bu kapsam tüm cluster'a genişliyor; tekrar eden bloklar cluster genelinde tek depolama ihtiyacına düşüyor. Veri azaltma oranları teorik olarak daha iyi. VCF 9.0 P01 ile TQR programı kapsamında geliyor.

Storage Policy Based Management (SPBM)

Bu modülün asıl konusu SPBM. Burada anlatmak istediğim şeyin "politika" kısmına takılmamak lazım; bu bir kurumsal yazılım sloganı değil, gerçekten işe yarayan bir mekanizma.

Temel mantık şu: VM'e "şu datastore'a yerleştir" demiyorsunuz. Onun yerine bir politika tanımlıyorsunuz, "bu VM en az 1 arıza tolere edebilmeli, RAID-5 ile" gibi. vSAN bu politikaya uyan yerleşimi kendisi buluyor. VM o politikaya uymakta zorlanırsa bunu da raporluyor: "Compliant" ya da "Non-compliant."

Bu yaklaşım, özellikle büyük ortamlarda her VM için ayrı ayrı storage konfigürasyonu yapmak yerine politika bazlı bir standart getiriyor. Dezavantajı şu olabilir: politika sayısı artınca bunları kim/ne zaman güncelleyecek, eski politikalara kim sahip çıkacak sorularına önceden cevap vermek gerekiyor.

Default Policy ve Optimal Datastore Default Policy

vSAN'ın bir "default storage policy"si var. Bu, herhangi bir politika atanmadan oluşturulan VM'lere otomatik atanıyor. Bunu silemiyorsunuz, ama kopyalayıp üzerine kendi politikanızı kurabiliyorsunuz.

vSAN 8.0 U1 ile gelen "Auto-Policy Management" özelliği ise bunu bir adım öteye taşıyor. Cluster'daki host sayısına ve konfigürasyonuna bakarak size özel bir "cluster-esa-01a - Optimal Datastore Default Policy - RAID5" gibi bir politika oluşturuyor. Bu otomatik politika RAID seviyesini cluster büyüklüğüne göre belirliyor. HOL'da bu özellik zaten etkin hale getirilmiş.

İlk Uygulama: VM Deploy Etmek

Bu bölümde mevcut bir VM'i (core-a) vSAN datastore'a klonluyoruz. Adımlar gayet açık:

vSphere Client'tan VM'e sağ tık → Clone → Clone to Virtual Machine
İsim: clone-vm-a
Cluster: cluster-esa-01a
Datastore: vsan-esa-01a_Datastore
Storage Policy: cluster-esa-01a - Optimal Datastore Default Policy - RAID 5

Klon işlemi tamamlanınca VM Summary ekranından politikanın atanmış ve "Compliant" olduğunu doğrulamak mümkün.

VM vSAN Üzerinde Nasıl Depolanıyor?

Bu kısım bence modülün en ilginç parçası. vSAN ESA'nın log-structured file system mimarisine bakınca şunu görüyorsunuz:

Yazma işlemi iki aşamada gerçekleşiyor:

Performance Leg (RAID-1): Gelen yazma önce RAID-1 olarak iki host arasında mirroring ile saklanıyor. Hızlı write acknowledgement için. Veri henüz kalıcı konumuna geçmedi.

Capacity Leg (RAID-5 veya RAID-6): Küçük yazmaların yeterince birikmesiyle vSAN bunları full-stripe write olarak RAID-5/6 formatında kalıcı kapasiteye indiriyor (destage). Bu, IO amplifikasyonunu azaltmak için tasarlanmış.

HOL'da bunu "Monitor > vSAN > Virtual Objects" üzerinden görebiliyorsunuz. VM'in hard diskini seçip "View Placement Details"e tıklayınca bileşenlerin hangi host üzerinde bulunduğunu görüyorsunuz.

Bu dağılımı görmek, "storage siyah bir kutu" algısını kırıyor. Veriyi görünür kılıyor.

Cluster'ı Büyütmek: Scale Out

RAID-5 ve RAID-6 için host sayısı gereksinimleri önemli:

Mimari	RAID-5 Minimum	RAID-6 Minimum
OSA	4 host	6 host
ESA	3 host (2+1 şeması, 1.5x kapasite)	6 host

ESA'da 6 veya daha fazla host varsa RAID-5 şeması 4+1'e geçiyor ve kapasite verimliliği artıyor (1.25x). Bu geçiş host sayısı değiştikten 24 saat sonra otomatik.

Yeni Host Eklemek

HOL'da cluster başlangıçta 4 host ile geliyor. İki ek host (esx-09a ve esx-10a) dışarıda bekliyor. Bu host'ları sürükle-bırak ile cluster'a ekliyorsunuz.

ESA'da artık "disk group" kavramı yok. Onun yerine "disk pool" var; host üzerindeki tüm uyumlu sürücüler havuza dahil oluyor. "vSAN Managed Disk Claim" etkinse eklenen host'un uyumlu sürücüleri otomatik olarak algılanıp vSAN datastore'a dahil ediliyor. HOL'da bu özellik etkin.

Disk Management: eklenen host'un sürücüleri" width="800" height="339">

Skyline Health ve Otomatik Policy Önerisi

İki host eklendikten sonra Skyline Health'i açtığımızda bir uyarı görüyoruz: cluster 6 host'a çıktığı için Auto Policy Management yeni bir politika öneriyor.

"TROUBLESHOOT" dediğinizde mevcut politika (RAID-5) ile önerilen politika (RAID-6) yan yana görünüyor. Mantıklı: 6 host ile RAID-6 hem mümkün hem daha resilient.

"UPDATE CLUSTER DS POLICY" diyebilirsiniz; bu noktadan sonra oluşturulan VM'ler RAID-6 politikası alıyor. Mevcut VM'leri de Policies and Profiles > REAPPLY ile güncelleyebiliyorsunuz. HOL'da bu adım zaman kazanmak için atlanıyor.

İleri Düzey Policy: Compression'ı Kapatmak

ESA'da sıkıştırma (compression) artık storage policy seviyesinde yönetiliyor. Varsayılan olarak açık, çünkü replica trafiği de compressed olarak taşınıyor. Ama bazı durumlarda kapatmak gerekebilir: kendi sıkıştırmasını yapan uygulamalar (veritabanları gibi) için ekstra sıkıştırma hem CPU israfı hem de veri azaltma oranlarını yanıltabilir.

Bu bölümde şunu yapıyoruz:

Mevcut vSAN ESA Default Policy - RAID5 politikasını klonla.
Yeni politikaya isim ver: vSAN ESA No Compression - RAID 5
Storage rules > Storage tier: "No space efficiency" seç (sıkıştırma bu şekilde devre dışı kalıyor)
Uyumluluk kontrolü: vsan-esa-01a_Datastore compatible göründüğünü doğrula
Finish

Ardından mevcut clone-vm-a VM'ine bu yeni politikayı atıyoruz: VM > Configure > Policies > EDIT VM STORAGE POLICIES. Dropdown'dan yeni politikayı seçince bir süre sonra VM "Compliant" statüsüne geçiyor.

Reserved Capacity

vSAN'ın tüm kapasitesi varsayılan olarak workload'lara açık. Ama cluster'da bir rebuild veya rebalancing operasyonu başladığında o an doluysa ne olacak? İşte "Reserved Capacity" tam buna yönelik.

İki tür rezervasyon var:

Operations Reserve: Cluster içi operasyonlar (policy reconfig, vb.) için ayrılan alan.

Host Rebuild Reserve: Bir host arızalandığında veri yeniden inşası için ayrılan alan. Bu rezervasyon, cluster'daki en büyük host'un kapasitesine göre belirleniyor. Minimum 4 host gereksinimi var.

HOL'da bu özelliği etkinleştirme ekranını görüyoruz: uyarı eşikleri %70, hata eşikleri %90 olarak ayarlanmış. Sonra iptal ediliyor çünkü iç içe geçmiş (nested) lab ortamında gerçek anlamda reserve etmek için yeterli kapasite yok.

Bu noktada şunu düşünmeden geçemedim: gerçek ortamlarda bu rezervasyonu kurmak ne zaman anlam taşıyor? Disk kapasitesi kısıtlıysa reserve etmek kısa vadede sizi zorlar. Ama o buffer olmadan bir host çöktüğünde rebuild yetersiz kapasiteye çarpar, bu daha büyük bir risk. Denge kurmak gerekiyor.

Bir kısıtlama notu: Stretched cluster, fault domain kullanılan cluster'lar, ROBO cluster ve 4'ten az host içeren cluster'larda bu özellik desteklenmiyor.

Scale In: Node Çıkarmak

Scale out kadar konuşulmayan ama production'da bir o kadar önemli olan şey: cluster'ı küçültmek. vSAN cluster'ı minimum 3 host ile çalışır. Host çıkarmadan önce şunlara bakmak gerekiyor:

Kalan compute ve storage kapasitesi yeterli mi?
Mevcut VM storage policy'leri compliant kalmaya devam edecek mi?

Data Migration Pre-Check

Bu araç, "şu host'u çıkarsam ne etkilenir?" sorusunun cevabını veriyor. HOL'da esx-10a seçilip "Full data migration" tercih edildiğinde hiçbir nesnenin etkilenmeyeceği görülüyor. Ardından direkt "ENTER MAINTENANCE MODE" adımına geçilebiliyor.

Maintenance Mode ve Host Kaldırma

Maintenance mode'a alınan host sonra drag & drop ile cluster dışına (datacenter seviyesine) taşınıyor. Aynı adımlar esx-09a için de tekrarlanıyor. Cluster böylece 4'e iniyor.

Genel Değerlendirme

HOL formatı bu konu için iyi çalışıyor. Her adım ekran yönlendirmesiyle geldiği için "nerede tıklamalıyım" sancısı yaşamıyorsunuz; odağınız tamamen mantığı anlamaya kayıyor. Ama şunu da söylemeliyim: HOL sizi hiçbir şeyin bozulmadığı, kapasitesinin üstünde çalışmayan bir ortamda karşılıyor. Gerçek sahada bu adımların her birinin yanına "peki bunu değişken bir ortamda nasıl yapacaksın, işler ters giderse ne olur" soruları ekleniyor.

Modülün beni en çok düşündüren kısmı RAID şeması geçişleri ve bunların kapasite verimliliğine yansımaları oldu. ESA'nın adaptif RAID-5'i (3-5 host için 1.5x, 6+ host için 1.25x) storage planlaması açısından gerçekten önemli bir ayrıntı. Host ekledikten 24 saat sonra otomatik geçiş yapması şık, ama o 24 saatte neler olabileceğini de takip etmek gerekir.

Bir sonraki haftada Modül 2'ye; sağlık izleme, kapasite takibi ve performans raporlaması konularına geçeceğim.

Bu seri VMware HOL ortamı (HOL-2634-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production ortamı kararları için mutlaka resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.

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.