Ozan Özdil
← Yazılar

Antigravity ve Konsey ile Uçtan Uca Ağ Optimizasyonu, OPNsense Yapılandırması ve Kastamonu İnci Yurt Yeni Yapılanması

Google Antigravity ve 12 üyeli yapay zekâ konseyiyle gerçekleştirdiğimiz Linux çekirdeği ve BBR ağ optimizasyonu, OPNsense üzerinde FQ_CoDel ve sıfır-atlatmalı DNS mimarisi ile Kastamonu İnci Yurt'un UniFi Wi-Fi 6, 5651 ve Cloudflare uç bilişim tabanlı yeni yapılanması.

· 16 dk okuma
İçindekiler

Özet: Yüksek bant genişliğine sahip bir fiber internet aboneliği tek başına düşük gecikme, kararlı bağlantı veya güvenli bir ağ anlamına gelmiyor. Çekirdek kuyruk algoritmalarından PPPoE paket boyutu (MTU/MSS) hesaplamalarına, DNS sızıntılarından çok katlı binalardaki VLAN izolasyonuna kadar her katman doğru ayarlanmadığında 1000 Mbps hızındaki bir hatta bile anlık kopmalar, tampon şişmesi (bufferbloat) ve ciddi güvenlik açıkları yaşanıyor. Bu yazıda önce bir ağ kurulurken veya iyileştirilirken mutlaka bilinmesi gereken temel mühendislik prensiplerini ve güvenlik önlemlerini ele alıyorum. Ardından Google Antigravity ve 12 üyeli yapay zekâ konseyimizle kendi Linux iş istasyonumuzda ve OPNsense (FreeBSD 15.1) güvenlik duvarımızda yaptığımız uçtan uca optimizasyonu, son olarak da Kastamonu Özel İnci Yükseköğrenim Kız Öğrenci Yurdu (kastamonuinciyurt.com) için hem fiziksel bina ağında (UniFi Wi-Fi 6, 5 VLAN, 5651 zaman damgası) hem de bulut ve yapay zekâ katmanında kurduğumuz yeni yapılanmayı tüm teknik ayrıntılarıyla paylaşıyorum.

Ağ mimarisinde bilinmesi gereken temel kavramlar nelerdir?

Bir ev ofis ağını ya da 150 kişilik çok katlı bir öğrenci yurdunun altyapısını tasarlarken karşılaşılan sorunların büyük bölümü “internet yavaş” şikâyetiyle özetlenir; oysa arka planda çalışan mekanizmalar çok daha spesifiktir. Optimizasyon adımlarına geçmeden önce, yaptığımız müdahalelerin neden işe yaradığını anlamak için şu beş temel kavramı netleştirmek gerekiyor:

1. MTU ve MSS dengesi: Paket boyutu neden bağlantı koparır?

Standart bir Ethernet çerçevesinin taşıyabileceği azami veri boyutu (MTU - Maksimum İletim Birimi) 1500 bayttır. Ancak Türkiye’deki FTTH (Eve Kadar Fiber) GPON altyapılarının neredeyse tamamında bağlantı PPPoE (Ethernet Üzerinden Noktadan Noktaya Protokol) ile kurulur. PPPoE, her pakete 8 baytlık ek bir başlık ekler. Bu durumda hattınızdan parçalanmadan geçebilecek gerçek azami paket boyutu 1500 - 8 = 1492 bayta düşer.

TCP bağlantılarında ise bu 1492 baytın içinden 20 bayt IPv4 başlığı ve 20 bayt TCP başlığı (toplam 40 bayt) çıkarıldığında, tek seferde taşınabilecek azami faydalı yük yani MSS (Maksimum Segment Boyutu) 1452 bayt olur:

Katman / ProtokolBaşlık MaliyetiKalan Azami BoyutAçıklama
Standart Ethernet0 bayt (baz)1500 bayt MTUYerel ağ (LAN) varsayılan çerçeve sınırı
PPPoE (VLAN 35 Fiber)8 bayt1492 bayt MTUİSS omurgasında parçalanmadan geçen üst sınır
TCP/IPv4 Yükü (MSS)40 bayt (20 IP + 20 TCP)1452 bayt MSSTek pakette taşınan net uygulama verisi
ICMP Ping Yükü (-D)28 bayt (20 IP + 8 ICMP)1464 bayt yükParçalanmasız (DF) geçebilen en büyük ping verisi

Eğer yönlendiricinizde MSS sabitleme (MSS Clamping) yanlış yapılırsa iki uç sorun doğar: Değer yüksek kalırsa “PMTU Kara Deliği” (Path MTU Blackhole) oluşur; web sayfaları yarım yüklenir, SSH oturumları büyük çıktı verirken donar. Değer yanlışlıkla çift düşülürse her pakette gereksiz kapasite kaybı ve fazladan işlemci yükü oluşur.

2. Tampon şişmesi (Bufferbloat) ve akıllı kuyruk yönetimi (SQM)

İnternet hattınız boşken 1.1.1.1 adresine attığınız ping 18 ms çıkabilir. Ancak aynı ağda bir cihaz büyük bir dosya indirirken veya buluta yedekleme yaparken bu gecikme bir anda 250-400 ms seviyelerine fırlıyorsa tampon şişmesi (bufferbloat) yaşıyorsunuz demektir.

İSS tarafındaki optik sonlandırıcı (ONT) veya modemlerin derin ama yönetimsiz paket tamponları (FIFO kuyrukları) hat doygunluğa ulaştığında paketleri sıraya dizer. Görüntülü görüşme, sesli iletişim veya DNS sorgusu gibi birkaç baytlık acil paketler, öndeki devasa indirme paketlerinin arkasında beklemek zorunda kalır. Çözüm, hat hızını İSS tamponuna dolmadan hemen önce (%92-%95 seviyesinde) kendi güvenlik duvarınızda yakalayıp RFC 8290 FQ_CoDel (Adil Kuyruklama ve Kontrollü Gecikme) algoritmasıyla her akışı ayrı bir sanal kuyruğa bölmektir.

3. DNS gizliliği (DoT / DoH) ve sıfır-atlatmalı (Zero-Bypass) çözümleme

Ağınızda reklam, zararlı yazılım ve oltalama (phishing) alan adlarını engelleyen bir DNS filtreleme katmanı kursanız bile modern işletim sistemleri ve tarayıcılar bunu kolayca atlatabilir:

  • Sabit kodlu DNS: Bazı IoT cihazları, televizyon kutuları ve uygulamalar DHCP’den verdiğiniz yerel DNS adresini yok sayıp doğrudan 8.8.8.8:53 adresine sorgu atar.
  • Şifreli dış DNS (DoT ve DoH): Android cihazlardaki “Özel DNS” (TCP/UDP 853 üzerinden DNS-over-TLS) veya tarayıcılardaki “Güvenli DNS” (TCP/UDP 443 üzerinden DNS-over-HTTPS), yerel DNS sunucunuzu tamamen devre dışı bırakır.

Gerçek bir ağ güvenliği için yerel ağdan dışarıya giden tüm 53 numaralı port trafiği güvenlik duvarında şeffaf olarak yerel DNS sunucusuna yönlendirilmeli (NAT Redirect), 853 numaralı DoT portu reddedilmeli (Reject - böylece cihaz anında standart DNS’e düşer) ve tarayıcıların DoH tünellerini kapatmak için bilinen DoH sunucu listeleriyle birlikte use-application-dns.net kanarya alan adı NXDOMAIN olarak yanıtlanmalıdır.

4. VLAN bölümleme ve yayın fırtınası (Broadcast Storm) kontrolü

Çok kullanıcılı bir ağda yönetim bilgisayarlarını, personel telefonlarını, yüzlerce öğrenci cihazını, misafirleri ve güvenlik kameralarını aynı 192.168.1.0/24 düz ağında (flat network) çalıştırmak büyük bir güvenlik zaafıdır. Aynı alt ağdaki bir cihaz, ARP zehirlenmesi (ARP Spoofing) ile trafiği dinleyebilir veya güvenlik kameralarının yönetim arayüzüne erişebilir.

IEEE 802.1Q VLAN etiketiyle tek bir fiziksel kablo ve anahtarlayıcı (switch) üzerinden birbirinden tamamen yalıtılmış sanal ağlar kurulur. Ayrıca ağda hem kablolu hem kablosuz arayüzü aynı anda aktif olan medya cihazları (örneğin Sonos hoparlörler veya kablosuz köprüler) bulunduğunda, anahtarlayıcı üzerinde RSTP (Hızlı Yayılan Ağaç Protokolü) öncelikleri doğru ayarlanmazsa saniyeler içinde tüm ağı kilitleyen bir paket döngüsü (broadcast storm) meydana gelir.

Ağ yapılandırmalarını paylaşırken hangi güvenlik önlemlerini alıyoruz?

Teknik bir mimariyi açıkça anlatırken operasyonel güvenliği (OPSEC) tehlikeye atmamak temel kuralımızdır. Hem kendi sistemlerimizde hem de bu makalede şu güvenlik sınırlarını uyguluyoruz:

  • Altyapı kimliklerinin maskelenmesi: Gerçek dış (WAN) IP adresleri, İSS BRAS geçit adresleri, PPPoE abone kimlikleri, cihaz MAC adresleri, bulut veritabanı tekil kimlikleri (UUID) ve iç yönetim alan adları asla açık metin olarak paylaşılmaz; örneklerde RFC 5737 dokümantasyon blokları (203.0.113.0/24, 198.51.100.0/24) ve RFC 1918 özel ağ blokları (192.168.1.0/24, 10.10.0.0/16) kullanılır.
  • Dış ağda (WAN) sıfır açık port ilkesi: Güvenlik duvarlarımızın WAN arayüzünde SSH (22), web yönetim arayüzü (443/8443), kamera izleme (RTSP 554) veya veritabanı portları dahil hiçbir gelen port açık değildir. Uzaktan yönetim yalnızca içeriden dışarıya giden (outbound-only), kuantum sonrası kriptografi (X25519MLKEM768) destekli Cloudflare Zero Trust tünelleri ve WireGuard üzerinden, çok aşamalı kimlik doğrulama (OTP/TOTP) şartıyla yapılır.
  • Güvenlik kameralarının (CCTV) internetten tam izolasyonu: IP kameralar ve NVR kayıt cihazları kendi özel VLAN ağlarında çalışır; dış internete çıkışları güvenlik duvarından tamamen kapatılmıştır. Böylece kamera yazılımlarındaki olası bir sıfırıncı gün (zero-day) açığının dışarıdan istismar edilmesi veya cihazların bir botnet ağına katılması imkânsız hale getirilir.

1. Antigravity ve konsey ile yerel Linux iş istasyonu ağ optimizasyonu

Uçtan uca optimizasyonun ilk halkası, üzerinde çalıştığımız Omarchy (Arch Linux) iş istasyonunun çekirdek ağ yığınını ve kablosuz bağlantı kararlılığını düzenlemek oldu. Konseydeki jcode ve claude-architect ajanlarıyla /etc/sysctl.d/ ve /etc/NetworkManager/ katmanlarında şu kalıcı iyileştirmeleri devreye aldık:

TCP BBR tıkanıklık kontrolü ve 16 MiB soket arabellekleri

Linux çekirdeğinin varsayılan cubic algoritması, hatta tek bir paket kaybı gördüğünde gönderim penceresini sert biçimde küçültür. Bunun yerine Google’ın geliştirdiği ve hattın gerçek bant genişliği ile gidiş-dönüş süresini (RTT) modelleyen BBR algoritmasını ve FQ (Adil Kuyruklama) paket zamanlayıcısını /etc/sysctl.d/99-network-bbr.conf ve 99-omarchy-sysctl.conf dosyalarıyla kalıcı hale getirdik:

# /etc/sysctl.d/99-network-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216

# PPPoE ve tünel hatlarında PMTU kara deliklerini önleyen RFC 4821 keşfi
net.ipv4.tcp_mtu_probing = 1

Kablosuz güç tasarrufu gecikmelerini ve çoklu yayın gürültüsünü kapatma

Modern Wi-Fi 6E ve Wi-Fi 7 yongalarında (özellikle Intel BE200/BE211 serisi) NetworkManager’ın varsayılan güç tasarrufu modu, bağlantı boşta kaldığında radyo katmanını uyku durumuna geçirir. Bu durum paket gönderiminde 20 ms ile 300 ms arasında ani gecikme sıçramalarına (jitter) yol açar. Ayrıca systemd-resolved içindeki LLMNR ve mDNS protokolleri hem yerel ağda gereksiz çoklu yayın (multicast) trafiği üretir hem de yerel ağda isim zehirlenmesi saldırılarına kapı aralar. İki sorunu da kökünden kapattık:

# /etc/NetworkManager/conf.d/omarchy-wifi-powersave.conf
[connection]
wifi.powersave = 2

# /etc/systemd/resolved.conf.d/10-disable-multicast.conf
[Resolve]
LLMNR=no
MulticastDNS=no

Buna ek olarak, yerel ağdaki cihazları ve gecikmeleri izlemek için geliştirdiğimiz omarchy-netradar aracını HANCORE güvenlik standartlarına göre sıkılaştırdık: Araç yalnızca özel ağ bloklarını (RFC 1918, RFC 3927 ve loopback) tarayabiliyor, tüm alt süreçleri ayrı süreç gruplarında (process_group(0)) izole ediyor ve harici komut çağrılarında -- bayrak sonlandırıcısı kullanarak argüman enjeksiyonunu engelliyor.

2. OPNsense (FreeBSD 15.1) çekirdek, SQM ve DNS optimizasyonu

Ağın kalbinde, 4 çekirdekli Intel N150 işlemci, 8 GB RAM ve NVMe SSD üzerinde çalışan OPNsense 26.7.7 (FreeBSD 15.1) yer alıyor. Konseyin 1M+ bağlamlı gemini-cli ve research ajanlarıyla mevcut yapılandırma yedeğini satır satır incelediğimizde, standart kurulumlarda gözden kaçan kritik darboğazlar tespit ettik ve bunları sırasıyla çözdük.

Gizli kapasite kaybı: Çift MSS düşümü hatasının düzeltilmesi

Türk Telekom FTTH GPON (VLAN 35 / PPPoE) hattımızda DF (Parçalama Yapma) bayraklı doğrulama testleri çalıştırdığımızda hattın tam 1492 bayt MTU desteklediğini doğruladık:

# 1464 bayt yük + 20 bayt IP + 8 bayt ICMP = 1492 bayt (%0 kayıp)
ping -D -s 1464 1.1.1.1

# 1465 bayt yük = 1493 bayt -> "frag needed and DF set (MTU 1492)"
ping -D -s 1465 1.1.1.1

Ancak OPNsense arayüz yapılandırmasında oldukça yaygın ama önemli bir nüans vardır: WAN arayüzündeki <mss> alanına doğrudan 1452 yazdığınızda, OPNsense arka planda TCP/IP başlığı olan 40 baytı ikinci kez çıkarır ve pf güvenlik duvarında scrub on pppoe1 inet all max-mss 1412 kuralı üretir. Bu da her TCP paketinde 40 baytın boşa gitmesi demektir. WAN arayüzündeki değeri <mss>1492</mss> olarak düzelttiğimizde OPNsense kendisi 40 bayt düşerek pf üzerinde tam olması gereken max-mss 1452 değerini üretti.

Donanım kesme (IRQ) izolasyonu ve FreeBSD çekirdek ayarları

4 çekirdekli Intel N150 işlemcide ağ paketlerinin, şifreleme işlemlerinin ve kullanıcı alanı servislerinin aynı çekirdek üzerinde birbirini beklememesi için /usr/local/etc/rc.syshook.d/start/95-antigravity-netopt önyükleme kancasıyla çekirdek görev paylaşımı (CPU Pinning) kurduk:

İşlemci ÇekirdeğiAtanan Görev ve Kesme (IRQ)Mimari Gerekçe
CPU 0NetISR (hybrid, QLimit=4096) + Dummynet FQ_CoDelPaket yönlendirme ve akıllı kuyruk zamanlamasının kesintisiz çalışması
CPU 1re0 (LAN Gigabit Ethernet kesmesi)Yerel ağ trafiğinin WAN kesmeleriyle çarpışmaması
CPU 2re1 (WAN GPON VLAN 35 / PPPoE kesmesi)PPPoE kapsülleme yükünün tek çekirdekte izole edilmesi
CPU 3Kullanıcı alanı (unbound, cloudflared, crowdsec, dnsmasq)DNS filtreleme ve tünel şifrelemesinin paket iletimini geciktirmemesi

Fiziksel Ethernet arayüzlerinde yazılımsal kuyruklarla çakışan donanımsal TSO/LRO ve VLAN filtrelemeyi (-vlanhwtso -tso -lro) kapattık; bunun sonucunda arayüz istatistiklerinde Ierrs=0, Oerrs=0, Idrop=0, Coll=0 (sıfır paket hatası ve sıfır kuyruk düşmesi) değerlerine ulaştık. Ayrıca 8 GB RAM’e sahip sistemde ZFS dosya sisteminin belleğin tamamını yutmasını önlemek için vfs.zfs.arc.max = 2147483648 (2 GB) sınırını ve Intel Speed Shift donanımsal frekans yönetimini (dev.hwpstate_intel.{0..3}.epp = 20) devreye aldık.

Dummynet FQ_CoDel boruları ve Waveform Bufferbloat A+ sonucu

Asimetrik 1000 Mbps / 50 Mbps fiber hatta tampon şişmesini sıfırlamak için OPNsense Traffic Shaper (Dummynet) üzerinde RFC 8290 standardına tam uyumlu iki FQ_CoDel borusu tanımladık:

  • İndirme Borusu (WAN_Down_930M_FQCoDel): 930 Mbit/s bant genişliği, target = 5 ms, interval = 100 ms, PPPoE paket boyutuyla birebir eşleşen quantum = 1492, limit = 4096, flows = 4096 ve ECN = açık.
  • Yükleme Borusu (WAN_Up_46M_FQCoDel): 46 Mbit/s bant genişliği, target = 5 ms, interval = 100 ms, 100 Mbps altı hatlarda küçük ACK/DNS paketlerine öncelik veren RFC 8290 düşük kuantum standardı (quantum = 300), limit = 1024, flows = 1024 ve NoECN.

Optimizasyon sonrasında gerçekleştirdiğimiz canlı başarım ölçütleri şu sonuçları verdi:

Ölçüm Noktası / SenaryoEn DüşükOrtalamaEn YüksekSapma (Jitter)Paket Kaybı
İSS İlk Atlama (BRAS - Boşta)1.24 ms1.64 ms2.00 ms0.27 ms%0.0
Türk Telekom Omurga DNS (dpinger)4.25 ms5.31 ms6.00 ms0.52 ms%0.0
Cloudflare Anycast (1.1.1.1)18.06 ms18.57 ms19.00 ms0.31 ms%0.0
Google Anycast (8.8.8.8)25.14 ms25.94 ms27.01 ms0.62 ms%0.0
Tam Yükte İndirme (8 Paralel Akış)—8.67 ms (+7.04 ms)——A+ Sınıfı
Tam Yükte Yükleme (6 Paralel Akış)—3.21 ms (-0.56 ms)——A+ Sınıfı

Unbound DNS (1.26.1): 1.1 GB bellek tasarrufu ve sıfır-atlatmalı mimari

Mevcut Unbound yapılandırmasında iki kritik sorun vardı: Birincisi, hem düz metin Query Forwarding hem de DNS-over-TLS (DoT) aynı anda açık bırakıldığı için 3.000’den fazla sorgu zaman aşımına (queries_discard_timeout) düşüyordu. İkincisi, birbiriyle örtüşen 11 farklı kara liste (2.89 milyon alan adı) Unbound’un tek başına 2.37 GB RAM tüketmesine yol açıyordu.

  1. Sadece TLS 1.3 DoT: Düz metin yönlendirmeyi kapattık; yalnızca cloudflare-dns.com (1.1.1.1:853, 1.0.0.1:853) ve dns.google (8.8.8.8:853, 8.8.4.4:853) DoT uç noktalarını bıraktık.
  2. Hedefli DNSBL ve 1.1 GB RAM kazancı: Mükerrer listeleri kaldırıp HaGeZi Multi PRO Wildcard, Threat Intelligence Feeds, Abuse.ch ThreatFox ve 3.283 sunuculuk Saf DoH engelleme listesini (doh.txt) aktif ettik. Yanıt modunu 0.0.0.0 yerine NXDOMAIN (nxdomain = 1) yaptık; böylece istemci uygulamalar bağlantı zaman aşımı beklemeden anında yanıt alıyor. Toplam tekil alan adı sayısı 1.709.008 olarak sabitlendi ve Unbound bellek kullanımı 2.37 GB’tan 1.28 GB’a (%15.8) indi.
  3. Kanarya alan adı ve Apple iCloud muafiyeti: Tarayıcıların gizli DoH tünellerini kapatmak için use-application-dns.net kanarya alan adını kara listeye, Apple cihazlarda iCloud Özel Geçiş (Private Relay) servisinin bozulmaması için mask.icloud.com, mask-h2.icloud.com ve mask-api.icloud.com adreslerini beyaz listeye ekledik.
  4. PF üzerinde zorunlu yönlendirme: Güvenlik duvarında LAN dışına giden tüm TCP/UDP 53 paketlerini şeffaf biçimde 127.0.0.1:53 adresine çeviren bir NAT rdr kuralı ve dış TCP/UDP 853 (DoT) paketlerini 3.5 ms içinde Reject (TCP RST / ICMP Unreachable) ile düşüren bir filtre kuralı yazdık.

Neden Suricata ve Zenarmor yerine CrowdSec ve Cloudflare Zero Trust seçtik?

OPNsense kullanıcılarının sıkça düştüğü bir tuzak, düşük güç tüketimli güvenlik duvarlarına aynı anda hem Suricata (IPS) hem de Zenarmor (os-sensei) kurmaktır. Konsey analizimizde bu iki paketin neden bu donanımda kullanılmaması gerektiğini somut verilerle ortaya koyduk:

  • Her iki motor da FreeBSD’nin netmap çekirdek çerçevesini aynı arayüzde kancalamaya çalışır; bu durum kesme çakışmalarına ve paket düşmelerine yol açar.
  • Şifreli HTTPS/QUIC trafiğinin %95’i aştığı günümüzde, TLS çözme (SSL Inspection) yapmadan paket gövdesi taramaya çalışmak yüksek işlemci maliyeti karşılığında çok düşük ek görünürlük sağlar; üstelik Zenarmor’un veritabanı servisleri tek başına 2 ila 4 GB RAM tüketir.

Bunun yerine çekirdek paket yolunu (netmap) hiç bozmayan çok daha etkili bir ikili kurduk:

  • os-crowdsec (Davranışsal IPS ve Tehdit İstihbaratı): Güvenlik duvarı ve servis kayıtlarını kullanıcı alanında analiz edip saldırgan IP’leri doğrudan pf tablosuna (crowdsec_blocklists, 1.000.000 tablo sınırı) yazar; paket yoluna sıfır gecikme ekler.
  • os-cloudflared (Kuantum Sonrası Sıfır Güven Tüneli): WAN üzerinde tek bir port bile açmadan, QUIC protokolü ve X25519MLKEM768 kuantum sonrası hibrit anahtar değişimiyle yönetim arayüzünü Cloudflare Zero Trust Access (yalnızca yetkili e-posta ve tek kullanımlık doğrulama kodu) arkasına alır.

3. Kastamonu İnci Yurt (kastamonuinciyurt.com) için yeni yapılanma

Ağ ve güvenlik mimarisindeki bu yaklaşımı, kurumsal ölçekte Kastamonu Özel İnci Yükseköğrenim Kız Öğrenci Yurdu projesinde hem fiziksel bina ağı ve mevzuat katmanına hem de bulut, yönetim portalı ve otonom yapay zekâ katmanına uyguladık.

Fiziksel bina ağı: 60 oda, 16 UniFi Wi-Fi 6 erişim noktası ve orta ada mimarisi

Yurt binası; Zemin Kat, 1. Kat (22 oda), 2. Kat (23 oda) ve Çatı Katı (15 oda) olmak üzere toplam 60 oda, 100-150 öğrenci, 15 personel ve 32 kablolu IP kameradan oluşuyor. Kat krokilerini incelediğimizde 1. ve 2. katların ortasında etrafı koridorlarla çevrili bir “orta ada” (iç odalar 112-117 ve etüt salonları) bulunduğunu gördük. Klasik “koridorun iki ucuna birer erişim noktası koyalım” yaklaşımı, betonarme iç oda duvarlarında 5 GHz sinyalinin tamamen sönümlenmesine yol açıyordu.

Bunu çözmek için toplam 16 adet UniFi Wi-Fi 6 erişim noktasını hücresel kapsama planıyla konumlandırdık:

  • Mevcut 6 adet UniFi U6-Lite korundu; üzerine 8 adet yeni UniFi U6+ ve öğrencilerin aynı anda yoğun bağlantı kurduğu Yemekhane/Dinlenme Odası ile 2. Kat Etüt kesişim noktaları için yüksek kapasiteli 2 adet UniFi U6-Pro eklendi.
  • Tüm kablolama, öğrenci yurtları yangın yönetmeliğine uygun olarak duman çıkarmayan ve halojen içermeyen %100 Bakır Cat6 LSZH (Low Smoke Zero Halogen) kablolarla dikey şaft üzerinden Zemin Kat Yönetim Odası’ndaki 18U/22U merkezi kabinete indirildi.

5 ayrı VLAN ile sıfır güven bölümlemesi ve 5651 mevzuat uyumu

Bina içindeki tüm trafiği OPNsense ve yönetilebilir PoE anahtarlayıcı üzerinde 5 ayrı VLAN ile birbirinden tamamen yalıttık:

VLAN KimliğiAğ Adı ve Alt AğKapsadığı Cihazlar ve Uygulanan Güvenlik Politikası
VLAN 10Yurt_Personel (10.10.10.0/24)15 personel cihazı; rastgele MAC kapatılarak DHCP’de Ad-Soyad/T.C. Kimlik ile sabit IP’ye eşleştirildi (Captive Portal çıkmadan 5651 uyumlu doğrudan giriş)
VLAN 20Yurt_Ogrenci (10.10.20.0/24)100-150 öğrenci; T.C. Kimlik (NVİ) ve FreeRADIUS doğrulamalı Captive Portal, öğrenci başı adil hız sınırı ve diğer tüm VLAN’lara erişim engeli
VLAN 30Yurt_Misafir (10.10.30.0/24)Ziyaretçiler için hız sınırı uygulanmış ve iç ağdan tamamen yalıtılmış misafir ağı
VLAN 40Guvenlik_CCTV (10.10.40.0/24)32 adet PoE IP kamera ve Karel NVR; kameraların dış internete çıkışı tamamen kapalı, GSB standartlarına uygun 30 günlük H.265 kayıt ve 3 kVA Online UPS koruması
VLAN 50Medya_IoT (10.10.50.0/24)Yemekhane ve katlardaki Apple TV, Sonos ses sistemleri ve akıllı TV kutuları; MAC doğrulama muafiyeti ve Sonos yayın döngülerine karşı RSTP Priority = 4096

Tek cihazda konsolidasyon: OPNsense ZFS RAID-1 Mirror mimarisi

Yurt yönetim odasında ayrı bir güvenlik duvarı, ayrı bir UniFi Cloud Key, ayrı bir 5651 log sunucusu ve ayrı bir VPN cihazı çalıştırmak hem arıza noktasını hem de enerji tüketimini artırıyordu. Araya sanal makine katmanı (TrueNAS/Proxmox) sokmadan, doğrudan fansız 4x Intel i226-V 2.5GbE ağ kartlı Mini PC (16 GB RAM, 2x 512 GB NVMe SSD ZFS RAID-1 Mirror) üzerinde çalışan tek bir OPNsense cihazında 6 kritik görevi birleştirdik:

  1. Çekirdek Yönlendirici, Güvenlik Duvarı ve FQ_CoDel Trafik Şekillendirici.
  2. Yerleşik UniFi Denetleyicisi (os-unifi-maxit): 16 adet Wi-Fi 6 erişim noktasını ve PoE anahtarlayıcıları ek cihaz gerektirmeden yönetir.
  3. 5651 Öğrenci Captive Portal ve os-freeradius Kimlik Doğrulama Motoru.
  4. TÜBİTAK Kamu SM Otomatik Zaman Damgalayıcı: Her gece saat 00:05’te o güne ait IP dağıtım, MAC ve NAT kayıtlarını 5651 sayılı kanuna uygun olarak kriptografik zaman damgasıyla mühürler ve çift diskli ZFS RAID-1 aynalı depolamada 2 yıl boyunca saklar (disklerden biri bozulsa bile veri kaybı yaşanmaz).
  5. Cloudflare Zero Trust Tüneli (cloudflared): Dışarıya port açmadan yurt yönetim panellerine güvenli erişim.
  6. WireGuard VPN (os-wireguard): Yetkili yöneticilerin mobil cihazlardan Karel NVR kamera sistemine güvenli erişimi.

Bulut yönetim portalı ve Düzey 5 ajan-yerli (Agent-Native) web platformu

Fiziksel ağın yanı sıra kastamonuinciyurt.com ve portal.kastamonuinciyurt.com dijital altyapısını da baştan sona yeniledik:

  • Cloudflare Uç Bilişim ve D1 Sunucusuz SQL Veritabanı: Statik yapıdan çıkarılarak Cloudflare üzerinde çalışan _worker.js uç çalışma zamanına ve Cloudflare D1 ilişkisel SQL veritabanına geçirildi. Öğrenci kayıtları, yabancı uyruklu ve mezun öğrenci arşivleri, oda/yatak planlaması, muhasebe/tahsilat, yemek menüsü ve Gençlik ve Spor Bakanlığı (GSB) formatına uygun A4 resmi izin/zimmet belgesi çıktıları tek merkezden yönetiliyor.
  • Çok Aşamalı Sıfır Güven Giriş Mimarisi: Eski basit PIN doğrulaması tamamen kaldırıldı; yerine Google OAuth2, SHA-256 parola özetleme, RFC 6238 TOTP (Google/Apple Authenticator 2FA) ve e-posta tek kullanımlık doğrulama kodu (OTP) katmanları getirildi. Tüm yanıtlar katı Content-Security-Policy, HSTS (preload) ve /portal/* altında noindex, nofollow, no-store başlıklarıyla korunuyor.
  • 4 Dilli Yapay Zekâ Danışmanı ve Düzey 5 Ajan Keşif Protokolleri: Yurt web sitesine Türkçe (TR), İngilizce (EN), Arapça (AR - sağdan sola dizilim) ve Rusça (RU) dillerinde çalışan uç yapay zekâ danışmanı eklendi. Ayrıca otonom yapay zekâ ajanlarının yurt bilgilerini, oda özelliklerini ve kampüs ulaşım mesafelerini doğrudan doğrulayabilmesi için llms.txt, llms-full.txt, /.well-known/mcp.json (Model Context Protocol sunucu kartı), /.well-known/agent-card.json (A2A), RFC 9728 / RFC 8414 otonom ajan OAuth 2.0 uç noktaları ve RFC 9460 DNS-AID (_index._agents, _mcp._agents, _a2a._agents SVCB/HTTPS) DNS kayıtları devreye alındı.

Benim okumam

  • Kesin olan: Ağ performansını ve güvenliğini artırmak için her zaman daha pahalı donanım veya daha yüksek hızda paket satın almak gerekmiyor. PPPoE hattında çift düşülen 40 baytlık bir MSS hatasını düzeltmek, Unbound DNS’te çakışan kara listeleri temizleyip NXDOMAIN moduna geçmek ve FQ_CoDel ile tampon şişmesini kesmek, aynı donanımda ağı bambaşka bir seviyeye taşıyor.
  • Pratikte en çok fark yaratan: Kurumsal binalarda (özellikle çok katlı öğrenci yurtlarında) fiziksel mimariyi okumadan yapılan erişim noktası yerleşimi ve düz ağ (flat network) kurulumları en büyük sorun kaynağı. Kameraları VLAN 40 içine hapsedip internet çıkışlarını kesmek, öğrenci ve personel ağlarını ayırmak ve tüm sistemi ZFS RAID-1 aynalı tek bir OPNsense kutusunda toplamak hem güvenliği hem de bakım kolaylığını dramatik biçimde artırdı.
  • Özetle: İster kişisel Linux iş istasyonunuzu ve ev güvenlik duvarınızı yönetin ister 150 kişilik bir kurumun ağını ve bulut portalını kurun; çekirdek seviyesinde doğru kuyruk yönetimi (BBR + FQ_CoDel), sıfır-atlatmalı DNS, dış ağda sıfır açık port ilkesi ve çoklu model konseyinin katmanlı denetimi bir araya geldiğinde hem yüksek hız hem de kurumsal düzeyde güvenlik aynı anda elde edilebiliyor.

Kaynaklar