End-to-End-Netzwerkoptimierung mit Antigravity und dem Rat, OPNsense-Konfiguration und die neue Struktur des Kastamonu İnci Yurt

Zusammenfassung: Ein Glasfaser-Internetanschluss mit hoher Bandbreite allein bedeutet nicht niedrige Latenz, eine stabile Verbindung oder ein sicheres Netz. Von den Kern-Queue-Algorithmen über die Berechnung der PPPoE-Paketgröße (MTU/MSS) bis hin zu DNS-Leaks und der VLAN-Isolierung in Mehrfamilienhäusern: Wenn nicht jede Schicht richtig eingestellt ist, kommt es selbst auf einer Leitung mit 1000 Mbps zu kurzen Verbindungsabbrüchen, Pufferblähung (Bufferbloat) und ernsthaften Sicherheitslücken. In diesem Artikel behandle ich zunächst die grundlegenden technischen Prinzipien und Sicherheitsmaßnahmen, die man beim Aufbau oder bei der Verbesserung eines Netzwerks unbedingt kennen muss. Anschließend beschreibe ich die Ende-zu-Ende-Optimierung, die wir mit Google Antigravity und unserem 12-köpfigen KI-Rat auf unserer eigenen Linux-Workstation und unserer OPNsense (FreeBSD 15.1)-Firewall durchgeführt haben, und schließlich die neue Struktur, die wir für das Kastamonu Özel İnci Yükseköğrenim Kız Öğrenci Yurdu (kastamonuinciyurt.com) sowohl im physischen Gebäudenetz (UniFi Wi-Fi 6, 5 VLANs, 5651-Zeitstempel) als auch in der Cloud- und KI-Schicht aufgebaut haben – mit allen technischen Details.

Welche grundlegenden Konzepte sollte man in der Netzwerkarchitektur kennen?

Beim Entwurf eines Heim- oder Büronetzwerks oder der Infrastruktur eines mehrstöckigen Studentenwohnheims für 150 Personen lässt sich ein Großteil der Probleme mit der Beschwerde „das Internet ist langsam“ zusammenfassen; dabei sind die im Hintergrund ablaufenden Mechanismen viel spezifischer. Bevor wir zu den Optimierungsschritten übergehen, müssen wir die folgenden fünf grundlegenden Konzepte klären, um zu verstehen, warum unsere Eingriffe wirken:

1. Das Gleichgewicht von MTU und MSS: Warum bricht die Verbindung wegen der Paketgröße ab?

Die maximale Datenmenge, die ein standardmäßiger Ethernet-Rahmen transportieren kann (MTU – Maximum Transmission Unit), beträgt 1500 Byte. In nahezu allen FTTH-GPON-Infrastrukturen (Fiber to the Home) in der Türkei wird die Verbindung jedoch über PPPoE (Point-to-Point Protocol over Ethernet) hergestellt. PPPoE fügt jedem Paket einen zusätzlichen 8-Byte-Header hinzu. Damit sinkt die tatsächliche maximale Paketgröße, die ungefragmentiert über Ihre Leitung passt, auf 1500 - 8 = 1492 Byte.

Bei TCP-Verbindungen ergibt sich, wenn man von diesen 1492 Byte noch den 20-Byte-IPv4-Header und den 20-Byte-TCP-Header (insgesamt 40 Byte) abzieht, eine maximale Nutzlast pro Übertragung, also eine MSS (Maximum Segment Size) von 1452 Byte:

Schicht / Protokoll	Header-Kosten	Verbleibende maximale Größe	Erklärung
Standard-Ethernet	0 Byte (Basis)	`1500` Byte MTU	Standard-Rahmengrenze im lokalen Netz (LAN)
PPPoE (VLAN 35 Fiber)	8 Byte	`1492` Byte MTU	Obergrenze, die im ISP-Backbone ungefragmentiert durchgeht
TCP/IPv4-Nutzlast (MSS)	40 Byte (20 IP + 20 TCP)	`1452` Byte MSS	Netto-Anwendungsdaten, die in einem Paket übertragen werden
ICMP-Ping-Nutzlast (`-D`)	28 Byte (20 IP + 8 ICMP)	`1464` Byte Nutzlast	Größte Ping-Datenmenge, die ungefragmentiert (`DF`) durchgeht

Wenn die MSS-Fixierung (MSS Clamping) auf Ihrem Router falsch konfiguriert ist, entstehen zwei Probleme: Bleibt der Wert zu hoch, entsteht ein „PMTU Blackhole“ (Path MTU Blackhole); Webseiten laden nur halb, SSH-Sitzungen frieren ein, wenn sie große Ausgaben liefern. Wird der Wert versehentlich doppelt abgezogen, entsteht bei jedem Paket unnötiger Kapazitätsverlust und zusätzliche Prozessorlast.

2. Pufferblähung (Bufferbloat) und intelligente Queue-Verwaltung (SQM)

Wenn Ihre Internetleitung leer ist, kann ein Ping an 1.1.1.1 18 ms ergeben. Wenn jedoch im selben Netz ein Gerät eine große Datei herunterlädt oder ein Backup in die Cloud macht und diese Verzögerung plötzlich auf 250-400 ms ansteigt, dann erleben Sie eine Pufferblähung (Bufferbloat).

Die tiefen, aber unverwalteten Paketpuffer (FIFO-Queues) der optischen Abschlusseinheit (ONT) oder der Modems auf der ISP-Seite reihen die Pakete in eine Warteschlange ein, wenn die Leitung gesättigt ist. Dringende Pakete von nur wenigen Byte wie Videoanrufe, Sprachkommunikation oder DNS-Abfragen müssen hinter den riesigen Download-Paketen davor warten. Die Lösung besteht darin, die Leitungskapazität direkt vor dem Füllen des ISP-Puffers (auf einem Niveau von 92 %–95 %) in der eigenen Firewall abzufangen und mit dem RFC 8290 FQ_CoDel (Fair Queueing und Controlled Delay)-Algorithmus jeden Datenstrom in eine eigene virtuelle Queue aufzuteilen.

3. DNS-Privatsphäre (DoT / DoH) und Zero-Bypass-Auflösung

Selbst wenn Sie in Ihrem Netzwerk eine DNS-Filterungsschicht einrichten, die Werbe-, Schadsoftware- und Phishing-Domains blockiert, können moderne Betriebssysteme und Browser diese leicht umgehen:

Fest codiertes DNS: Einige IoT-Geräte, Fernsehboxen und Anwendungen ignorieren die lokale DNS-Adresse, die Sie per DHCP zuweisen, und senden ihre Abfragen direkt an 8.8.8.8:53.
Verschlüsseltes externes DNS (DoT und DoH): Das „Private DNS“ auf Android-Geräten (DNS-over-TLS über TCP/UDP 853) oder das „Sichere DNS“ in Browsern (DNS-over-HTTPS über TCP/UDP 443) setzt Ihren lokalen DNS-Server vollständig außer Kraft.

Für eine echte Netzwerksicherheit muss der gesamte vom lokalen Netz nach außen gehende Verkehr auf Port 53 in der Firewall transparent an den lokalen DNS-Server umgeleitet werden (NAT Redirect), der DoT-Port 853 muss abgelehnt werden (Reject – so fällt das Gerät sofort auf Standard-DNS zurück), und um die DoH-Tunnel der Browser zu schließen, müssen die bekannten DoH-Serverlisten zusammen mit der Kanarien-Domain use-application-dns.net als NXDOMAIN beantwortet werden.

4. VLAN-Segmentierung und Kontrolle von Broadcast-Stürmen (Broadcast Storm)

In einem Netz mit vielen Nutzern ist es eine große Sicherheitsschwäche, Verwaltungsrechner, Mitarbeitertelefone, Hunderte von Schüler- und Studierendengeräten, Gäste und Überwachungskameras im selben flachen 192.168.1.0/24-Netz (Flat Network) zu betreiben. Ein Gerät im selben Subnetz kann durch ARP-Spoofing den Verkehr abhören oder auf die Verwaltungsoberfläche der Überwachungskameras zugreifen.

Mit dem IEEE 802.1Q VLAN-Tag werden über ein einziges physisches Kabel und einen einzigen Switch vollständig voneinander isolierte virtuelle Netze aufgebaut. Wenn sich zudem Mediengeräte im Netz befinden, deren kabelgebundene und drahtlose Schnittstelle gleichzeitig aktiv sind (etwa Sonos-Lautsprecher oder WLAN-Bridges), entsteht außerdem eine Paketschleife (Broadcast Storm), die das gesamte Netz innerhalb von Sekunden blockiert, wenn die Prioritäten von RSTP (Rapid Spanning Tree Protocol) am Switch nicht korrekt eingestellt sind.

Welche Sicherheitsmaßnahmen ergreifen wir beim Teilen von Netzwerkkonfigurationen?

Unsere Grundregel ist, die operative Sicherheit (OPSEC) nicht zu gefährden, während eine technische Architektur offen beschrieben wird. Sowohl in unseren eigenen Systemen als auch in diesem Artikel wenden wir folgende Sicherheitsgrenzen an:

Maskierung von Infrastruktur-Identitäten: Echte externe (WAN-)IP-Adressen, BRAS-Gateway-Adressen des ISPs, PPPoE-Teilnehmerkennungen, Geräte-MAC-Adressen, eindeutige Kennungen von Cloud-Datenbanken (UUID) und interne Verwaltungsdomänen werden niemals im Klartext geteilt; in den Beispielen werden RFC 5737-Dokumentationsblöcke (203.0.113.0/24, 198.51.100.0/24) und private RFC 1918-Netzblöcke (192.168.1.0/24, 10.10.0.0/16) verwendet.
Prinzip null offener Ports im externen Netz (WAN): Auf der WAN-Schnittstelle unserer Firewalls ist kein einziger eingehender Port offen, einschließlich Fernzugriff, Web-Verwaltungsoberfläche, Kameraüberwachung oder Datenbankdiensten. Die Fernverwaltung erfolgt ausschließlich über von innen nach außen gehende (outbound-only) Cloudflare Zero Trust-Tunnel mit Post-Quanten-Kryptografie (X25519MLKEM768) und über WireGuard, mit der Voraussetzung einer mehrstufigen Authentifizierung (OTP/TOTP).
Vollständige Isolierung der Überwachungskameras (CCTV) vom Internet: IP-Kameras und NVR-Aufnahmegeräte laufen in eigenen privaten VLAN-Netzen; ihr Zugang zum externen Internet ist in der Firewall vollständig gesperrt. So wird es unmöglich, eine mögliche Zero-Day-Schwachstelle in der Kamersoftware von außen auszunutzen oder die Geräte in ein Botnetz einzubinden.

1. Lokale Linux-Workstation-Netzwerkoptimierung mit Antigravity und dem Rat

Das erste Glied der End-to-End-Optimierung war, den Kernel-Netzwerkstack und die Stabilität der drahtlosen Verbindung der Omarchy (Arch Linux)-Workstation zu regeln, auf der wir arbeiten. Mit den Agenten jcode und claude-architect aus dem Rat haben wir in den Ebenen /etc/sysctl.d/ und /etc/NetworkManager/ folgende dauerhaften Verbesserungen umgesetzt:

TCP-BBR-Überlastkontrolle und 16-MiB-Socket-Puffer

Der Standard-cubic-Algorithmus des Linux-Kernels verkleinert das Sendefenster drastisch, sobald er auch nur einen einzigen Paketverlust feststellt. Stattdessen haben wir den von Google entwickelten BBR-Algorithmus, der die tatsächliche Bandbreite und die Umlaufzeit (RTT) der Leitung modelliert, und den Paket-Scheduler FQ (Fair Queueing) mit den Dateien /etc/sysctl.d/99-network-bbr.conf und 99-omarchy-sysctl.conf dauerhaft gemacht:

# /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

Verzögerungen bei der drahtlosen Energieverwaltung und Multicast-Rauschen abschalten

Bei modernen Wi-Fi-6E- und Wi-Fi-7-Chips (insbesondere der Intel-BE200/BE211-Serie) versetzt der Standard-Energiesparmodus von NetworkManager die Funkschicht in den Ruhezustand, wenn die Verbindung im Leerlauf ist. Dies führt beim Senden von Paketen zu plötzlichen Verzögerungssprüngen (Jitter) zwischen 20 ms und 300 ms. Außerdem erzeugen die Protokolle LLMNR und mDNS in systemd-resolved sowohl unnötigen Multicast-Verkehr im lokalen Netz als auch eine Angriffsfläche für Namensvergiftungsangriffe im lokalen Netz. Wir haben beide Probleme an der Wurzel beseitigt:

# /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

Zusätzlich haben wir das von uns entwickelte Werkzeug omarchy-netradar zur Überwachung von Geräten und Verzögerungen im lokalen Netz nach den Sicherheitsstandards von HANCORE gehärtet: Das Werkzeug kann nur private Netzblöcke (RFC 1918, RFC 3927 und loopback) scannen, isoliert alle Unterprozesse in eigenen Prozessgruppen (process_group(0)) und verhindert Argument-Injection bei externen Befehlsaufrufen durch die Verwendung des ---Flag-Terminators.

2. OPNsense (FreeBSD 15.1) Kernel-, SQM- und DNS-Optimierung

Im Herzen des Netzes steht OPNsense 26.7.7 (FreeBSD 15.1), das auf einem 4-Kern-Prozessor Intel N150, 8 GB RAM und einer NVMe SSD läuft. Als wir mit den gemini-cli- und research-Agenten des Konzepts mit über 1 Mio. Kontext die vorhandene Konfigurationssicherung Zeile für Zeile untersuchten, haben wir kritische Engpässe entdeckt, die bei Standardinstallationen übersehen werden, und sie der Reihe nach behoben.

Versteckter Kapazitätsverlust: Behebung des doppelten MSS-Reduktionsfehlers

Als wir auf unserer Türk Telekom FTTH GPON-Leitung (VLAN 35 / PPPoE) Validierungstests mit dem DF-Flag (Don't Fragment) durchführten, haben wir bestätigt, dass die Leitung genau 1492 Byte MTU unterstützt:

# 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

Es gibt jedoch eine recht verbreitete, aber wichtige Feinheit in der OPNsense-Schnittstellenkonfiguration: Wenn Sie im Feld <mss> der WAN-Schnittstelle direkt 1452 eingeben, zieht OPNsense im Hintergrund die 40 Byte des TCP/IP-Headers ein zweites Mal ab und erzeugt in der pf-Firewall die Regel scrub on pppoe1 inet all max-mss 1412. Das bedeutet, dass in jedem TCP-Paket 40 Byte verschwendet werden. Als wir den Wert in der WAN-Schnittstelle auf <mss>1492</mss> korrigierten, zog OPNsense selbst 40 Byte ab und erzeugte in pf den genau richtigen Wert max-mss 1452.

Hardware-Interrupt-(IRQ-)Isolierung und FreeBSD-Kerneleinstellungen

Auf dem 4-Kern-Intel-N150-Prozessor haben wir über einen Boot-Hook ein Kern-Task-Sharing (CPU Pinning) eingerichtet, damit Netzwerkpakete, Verschlüsselungsvorgänge und Userspace-Dienste nicht auf demselben Kern aufeinander warten:

Prozessorkern	Zugewiesene Aufgabe und Interrupt (IRQ)	Architektonische Begründung
`CPU 0`	`NetISR` (`hybrid`, `QLimit=4096`) + `Dummynet FQ_CoDel`	Ununterbrochener Betrieb von Paketweiterleitung und intelligenter Queue-Planung
`CPU 1`	`re0` (LAN-Gigabit-Ethernet-Interrupt)	Damit lokaler Netzwerkverkehr nicht mit WAN-Interrupts kollidiert
`CPU 2`	`re1` (WAN-GPON-`VLAN 35` / `PPPoE`-Interrupt)	Isolierung der PPPoE-Kapselungslast auf einem einzigen Kern
`CPU 3`	Userspace (`unbound`, `cloudflared`, `crowdsec`, `dnsmasq`)	Damit DNS-Filterung und Tunnelverschlüsselung die Paketweiterleitung nicht verzögern

Auf den physischen Ethernet-Schnittstellen haben wir Hardware-TSO/LRO und VLAN-Filterung (-vlanhwtso -tso -lro) deaktiviert, die mit den Software-Queues kollidierten; dadurch erreichten wir in den Schnittstellenstatistiken die Werte Ierrs=0, Oerrs=0, Idrop=0, Coll=0 (null Paketfehler und null Queue-Drops). Außerdem haben wir auf dem System mit 8 GB RAM, um zu verhindern, dass das ZFS-Dateisystem den gesamten Speicher verschlingt, das Limit vfs.zfs.arc.max = 2147483648 (2 GB) und die Intel-Speed-Shift-Hardware-Frequenzverwaltung (dev.hwpstate_intel.{0..3}.epp = 20) aktiviert.

Dummynet-FQ_CoDel-Pipes und Waveform-Bufferbloat-A+-Ergebnis

Um die Pufferblähung auf der asymmetrischen Glasfaserleitung mit 1000 Mbps / 50 Mbps auf null zu bringen, haben wir im OPNsense Traffic Shaper (Dummynet) zwei vollständig RFC 8290-konforme FQ_CoDel-Pipes definiert:

Download-Pipe (WAN_Down_930M_FQCoDel): 930 Mbit/s Bandbreite, target = 5 ms, interval = 100 ms, exakt auf die PPPoE-Paketgröße abgestimmtes quantum = 1492, limit = 4096, flows = 4096 und ECN = aktiviert.
Upload-Pipe (WAN_Up_46M_FQCoDel): 46 Mbit/s Bandbreite, target = 5 ms, interval = 100 ms, der RFC-8290-Standard für niedriges Quantum (quantum = 300), der auf Leitungen unter 100 Mbps kleinen ACK/DNS-Paketen Vorrang gibt, limit = 1024, flows = 1024 und NoECN.

Die Live-Leistungsmessungen, die wir nach der Optimierung durchführten, ergaben folgende Ergebnisse:

Messpunkt / Szenario	Minimum	Durchschnitt	Maximum	Abweichung (Jitter)	Paketverlust
Erster ISP-Hop (BRAS - Leerlauf)	`1.24 ms`	`1.64 ms`	`2.00 ms`	`0.27 ms`	`%0.0`
Türk Telekom Backbone-DNS (`dpinger`)	`4.25 ms`	`5.31 ms`	`6.00 ms`	`0.52 ms`	`%0.0`
Cloudflare Anycast (`1.1.1.1`)	`18.06 ms`	`18.57 ms`	`19.00 ms`	`0.31 ms`	`%0.0`
Google Anycast (`8.8.8.8`)	`25.14 ms`	`25.94 ms`	`27.01 ms`	`0.62 ms`	`%0.0`
Download unter Volllast (8 parallele Streams)	—	`8.67 ms` (`+7.04 ms`)	—	—	Klasse A+
Upload unter Volllast (6 parallele Streams)	—	`3.21 ms` (`-0.56 ms`)	—	—	Klasse A+

Unbound DNS (1.26.1): 1,1 GB Speichereinsparung und eine Architektur ohne Latenz

In der bestehenden Unbound-Konfiguration gab es zwei kritische Probleme: Erstens waren sowohl Query Forwarding im Klartext als auch DNS-over-TLS (DoT) gleichzeitig aktiv, wodurch mehr als 3.000 Abfragen in einen Timeout liefen (queries_discard_timeout). Zweitens führten 11 sich überschneidende Blacklists (2,89 Millionen Domainnamen) dazu, dass Unbound allein 2,37 GB RAM verbrauchte.

Nur TLS 1.3 DoT: Wir haben die Klartext-Weiterleitung deaktiviert und nur die DoT-Endpunkte cloudflare-dns.com (1.1.1.1:853, 1.0.0.1:853) und dns.google (8.8.8.8:853, 8.8.4.4:853) belassen.
Gezielte DNSBL und 1,1 GB RAM-Gewinn: Wir haben die doppelten Listen entfernt und HaGeZi Multi PRO Wildcard, Threat Intelligence Feeds, Abuse.ch ThreatFox sowie die reine DoH-Blockliste mit 3.283 Servern (doh.txt) aktiviert. Den Antwortmodus haben wir statt auf 0.0.0.0 auf NXDOMAIN (nxdomain = 1) gesetzt; so erhalten Client-Anwendungen sofort eine Antwort, ohne auf einen Verbindungs-Timeout zu warten. Die Gesamtzahl der eindeutigen Domainnamen wurde auf 1.709.008 festgelegt, und der Speicherverbrauch von Unbound sank von 2,37 GB auf 1,28 GB (%15.8).
Kanarien-Domain und Apple iCloud-Ausnahme: Um die versteckten DoH-Tunnel der Browser zu schließen, haben wir die Kanarien-Domain use-application-dns.net auf die Blacklist gesetzt und, damit der Dienst iCloud Private Relay auf Apple-Geräten nicht beeinträchtigt wird, die Adressen mask.icloud.com, mask-h2.icloud.com und mask-api.icloud.com auf die Whitelist gesetzt.
Erzwungene Weiterleitung über PF: In der Firewall haben wir eine NAT-rdr-Regel geschrieben, die alle TCP/UDP 53-Pakete, die das LAN verlassen, transparent auf 127.0.0.1:53 umleitet, sowie eine Filterregel, die externe TCP/UDP 853-Pakete (DoT) innerhalb von 3.5 ms mit Reject (TCP RST / ICMP Unreachable) verwirft.

Warum wir CrowdSec und Cloudflare Zero Trust statt Suricata und Zenarmor gewählt haben

Eine häufige Falle, in die OPNsense-Nutzer tappen, ist die gleichzeitige Installation von Suricata (IPS) und Zenarmor (os-sensei) auf stromsparenden Firewalls. In unserer Ratsanalyse haben wir mit konkreten Daten dargelegt, warum diese beiden Pakete auf dieser Hardware nicht verwendet werden sollten:

Beide Engines versuchen, das netmap-Kernel-Framework von FreeBSD auf derselben Schnittstelle zu verankern; dies führt zu Interrupt-Konflikten und Paketverlusten.
Da verschlüsselter HTTPS/QUIC-Verkehr heute über 95 % ausmacht, bietet der Versuch, Paketinhalte ohne TLS-Entschlüsselung (SSL Inspection) zu scannen, bei hohen Prozessorkosten nur sehr geringe zusätzliche Sichtbarkeit; zudem verbrauchen allein die Datenbankdienste von Zenarmor 2 bis 4 GB RAM.

Stattdessen haben wir ein viel wirksameres Duo eingerichtet, das den Kernel-Paketpfad (netmap) überhaupt nicht beeinträchtigt:

os-crowdsec (verhaltensbasiertes IPS und Threat Intelligence): Analysiert Firewall- und Dienstprotokolle im Userspace und schreibt Angreifer-IPs direkt in die pf-Tabelle (crowdsec_blocklists, 1.000.000 Tabellenlimit); fügt dem Paketpfad null Latenz hinzu.
os-cloudflared (Post-Quanten-Zero-Trust-Tunnel): Stellt die Verwaltungsschnittstelle hinter Cloudflare Zero Trust Access (nur autorisierte E-Mail und Einmal-Bestätigungscode), ohne auch nur einen einzigen Port auf der WAN-Seite zu öffnen, mit dem QUIC-Protokoll und dem Post-Quanten-Hybridschlüsselaustausch X25519MLKEM768.

3. Neue Struktur für Kastamonu İnci Yurt (`kastamonuinciyurt.com`)

Diesen Ansatz in der Netzwerk- und Sicherheitsarchitektur haben wir im Projekt Kastamonu Özel İnci Yükseköğrenim Kız Öğrenci Yurdu im institutionellen Maßstab sowohl auf der Ebene des physischen Gebäudenetzes und der Vorschriften als auch auf der Ebene der Website umgesetzt. Da es sich um ein institutionelles Netz handelt, verzichte ich in diesem Abschnitt auf Details wie Adressplan, Türnummern und Gerätestandorte.

Physisches Gebäudenetz: 16 UniFi Wi-Fi 6 Access Points und Mittelinsel-Architektur

Das Wohnheimgebäude besteht aus vier Etagen, 100-150 Schülerinnen und 15 Mitarbeitenden. Bei der Prüfung der Etagengrundrisse stellten wir fest, dass sich in der Mitte der Zwischenetagen eine von Korridoren umgebene „Mittelinsel“ (Innenzimmer und Lernräume) befindet. Der klassische Ansatz „wir setzen an beide Korridorenden je einen Access Point“ führte dazu, dass das 5-GHz-Signal an den Innenwänden aus Stahlbeton vollständig gedämpft wurde.

Um dies zu lösen, haben wir insgesamt 16 UniFi Wi-Fi 6 Access Points mit einem zellularen Abdeckungsplan positioniert:

Die vorhandenen 6 UniFi U6-Lite wurden beibehalten; ergänzt wurden 8 neue UniFi U6+ sowie für die Gemeinschaftsbereiche, in denen Schülerinnen gleichzeitig intensive Verbindungen aufbauen, 2 leistungsstarke UniFi U6-Pro.
Die gesamte Verkabelung wurde gemäß der Brandschutzverordnung für Schülerwohnheime mit rauchfreien und halogenfreien %100 Bakır Cat6 LSZH (Low Smoke Zero Halogen)-Kabeln zum zentralen Schrank geführt.

Zero-Trust-Segmentierung mit 5 separaten VLANs und Einhaltung der 5651-Vorschriften

Den gesamten Datenverkehr im Gebäude haben wir über OPNsense und einen verwaltbaren PoE-Switch mit 5 separaten VLANs vollständig voneinander isoliert:

Personennetz: Personengeräte erhalten feste, mit ihrer Identität verknüpfte Adressen; die 5651-Aufzeichnungen werden ohne Captive Portal geführt.
Schülernetz: Captive Portal mit T.C.-Kimlik-(NVİ-) und FreeRADIUS-Authentifizierung, faire Geschwindigkeitsbegrenzung pro Schülerin und Sperre des Zugriffs auf andere Netze.
Gastnetz: Besuchernetz mit Geschwindigkeitsbegrenzung und vollständiger Isolierung vom internen Netz.
Sicherheitskameras: IP-Kameras und Aufzeichnungsgerät in einem separaten Netz; der Internetzugang der Kameras ist vollständig gesperrt, die Aufzeichnungen werden gemäß den GSB-Standards für die vorgeschriebene Dauer gespeichert und durch eine unterbrechungsfreie Stromversorgung geschützt.
Medien und IoT: Fernsehboxen und Audiosysteme in den Gemeinschaftsbereichen; gegen Sendeschleifen wurde am Switch die RSTP-Priorität eingestellt.

Konsolidierung auf einem Gerät: OPNsense ZFS RAID-1 Mirror-Architektur

Im Wohnheim erhöhte der Betrieb einer separaten Firewall, eines separaten UniFi Cloud Key, eines separaten 5651-Log-Servers und eines separaten VPN-Geräts sowohl die Ausfallpunkte als auch den Energieverbrauch. Ohne eine dazwischenliegende Virtualisierungsschicht (TrueNAS/Proxmox) haben wir 6 kritische Aufgaben auf einem einzigen OPNsense-Gerät zusammengeführt, das direkt auf einem lüfterlosen Mini-PC mit zwei NVMe-SSDs (ZFS RAID-1 Mirror) läuft:

Kernrouter, Firewall und FQ_CoDel-Traffic-Shaper.
Integrierter UniFi-Controller (os-unifi-maxit): Verwaltet 16 Wi-Fi-6-Access-Points und die PoE-Switches ohne zusätzliche Geräte.
5651-Schüler-Captive-Portal und os-freeradius-Authentifizierungs-Engine.
TÜBİTAK Kamu SM automatischer Zeitstempel-Dienst: Versiegelt jede Nacht die IP-Zuweisungs-, MAC- und NAT-Aufzeichnungen des jeweiligen Tages gemäß dem Gesetz Nr. 5651 mit einem kryptografischen Zeitstempel und bewahrt sie zwei Jahre lang auf dem gespiegelten ZFS-RAID-1-Speicher mit zwei Festplatten auf (selbst bei Ausfall einer der Festplatten geht kein Datenverlust einher).
Cloudflare Zero Trust Tunnel (cloudflared): Sicherer Zugriff auf die Verwaltungsoberflächen des Wohnheims, ohne Ports nach außen zu öffnen.
WireGuard VPN (os-wireguard): Sicherer Fernzugriff für autorisierte Administratoren.

Website

kastamonuinciyurt.com wurde von einer statischen Struktur auf eine Edge-Anwendung verlagert, die auf Cloudflare Workers läuft. Das im ersten Entwurf des Artikels beschriebene Verwaltungsportal, der mehrsprachige KI-Berater und die Agent-Erkundungsprotokolle wurden im Oktober 2026 entfernt; die Website besteht heute aus Seiten, die das Wohnheim vorstellen, vorbereiteten Antworten auf häufig gestellte Fragen und den neuesten Instagram-Beiträgen.

Meine Einschätzung

Sicher ist: Um Netzwerkleistung und Sicherheit zu verbessern, muss man nicht immer teurere Hardware oder Pakete mit höherer Geschwindigkeit kaufen. Die Korrektur eines 40-Byte-MSS-Fehlers, der auf der PPPoE-Leitung doppelt auftrat, das Bereinigen sich überschneidender Blacklists in Unbound DNS mit Wechsel in den NXDOMAIN-Modus und das Unterbinden von Bufferbloat mit FQ_CoDel bringen das Netz auf derselben Hardware auf ein völlig anderes Niveau.
In der Praxis am wirkungsvollsten: In institutionellen Gebäuden (insbesondere in mehrstöckigen Schülerwohnheimen) sind Access-Point-Platzierungen ohne Kenntnis der physischen Architektur und flache Netzwerkinstallationen (Flat Network) die größte Problemquelle. Kameras in ein separates Netz zu verlegen und ihren Internetzugang zu sperren, Schüler- und Personennetze zu trennen und das gesamte System in einer einzigen OPNsense-Box mit ZFS-RAID-1-Spiegelung zusammenzuführen, hat sowohl die Sicherheit als auch die Wartungsfreundlichkeit drastisch erhöht.
Zusammenfassend: Ob Sie Ihre persönliche Linux-Workstation und Ihre Heim-Firewall verwalten oder das Netz einer Institution mit 150 Personen aufbauen; wenn korrektes Queue-Management auf Kernel-Ebene (BBR + FQ_CoDel), DNS ohne Latenz, das Prinzip null offener Ports im Außennetz und die mehrschichtige Kontrolle eines Multi-Modell-Rats zusammenkommen, lassen sich hohe Geschwindigkeit und Sicherheit auf institutionellem Niveau gleichzeitig erreichen.