[LAYER_1&2] Fabric & Security: OSPF-Kopplung und FortiGate Hardening

Jeder noch so intelligente KI-Assistent ist wertlos, wenn das darunter liegende Netzwerk eine "Black Box" ist. Für Project Sentinel haben wir ein Underlay geschaffen, das auf maximalen Determinismus und lückenlose Überwachung setzt. Wir verlassen uns nicht auf statische Routen – wir erzwingen dynamische Intelligenz bis zur Firewall.

Layer 1: Das Fabric Underlay (The Spine-Leaf Core)

Im virtuellen Labor (EVE-NG) haben wir eine klassische 2-Tier Spine-Leaf Architektur realisiert. Das Ziel: Horizontale Skalierbarkeit und minimale Latenz für den Datentransfer zwischen den SSoT-Systemen und dem KI-Backend.

• Core-Komponenten: Cisco Nexus 9000v als Spines, Aruba CX als Leafs.
• Routing-Protokoll: Volle OSPF-Masche (Area 0.0.0.0).
• Segmentierung: Point-to-Point /30 Transitsegmente.
• Redundanz: Redundant deklarierte Loopback-Schnittstellen fungieren als Router-IDs und Ankerpunkte für das Management. Durch ECMP (Equal-Cost Multi-Pathing) nutzen wir alle verfügbaren Pfade der Fabric gleichzeitig.

Layer 2: Security Plane (FortiGate als ISFW)

In einer Zero-Trust-Architektur gibt es kein "internes vertrauenswürdiges Netz". Die FortiGate-VM (FG-01) fungiert hier als Internal Segmentation Firewall (ISFW). Sie steht physisch zwischen dem Management-VLAN und der Fabric.

Die OSPF-Integration

Anstatt die Firewall händisch über jede Änderung im Netz zu informieren, haben wir das Transit-Interface port2 (10.100.100.2/30) aktiv in den OSPF-Prozess eingebunden.

• Effekt: Die FortiGate lernt alle internen Switch-Netzwerke dynamisch.
• Security-Impact: Wir implementieren Next-Gen-Firewall-Richtlinien mit aktiver Intrusion Prevention (IPS) und SSL-Inspection. Selbst der Traffic zwischen den Management-Containern wird tiefen-geprüft.

Lessons Learned: Das Problem mit der SSH-Automatisierung

Ein technisches Highlight dieses Layers war die Überwindung eines "Vendor-Hiccups". Neuere Fortinet-Ansible-Sammlungen haben die Unterstützung für klassische ssh/network_cli-Verbindungen eingeschränkt. In einer automatisierten GitOps-Pipeline (GitLab Runner) ist das ein Showstopper.

Die Lösung:
Wir haben im flüchtigen Pipeline-Container eine unkaputtbare SSH-Pipe via sshpass und openssh-client gebaut.

codeBash

# Beispiel der automatisierten CLI-Injektion via GitLab-Runner
echo "config system global" > config.txt
sshpass -p "$FG_PASSWORD" ssh -o StrictHostKeyChecking=no $FG_USER@$FG_IP < config.txt

Status: CLI-Konfigurationen werden nun fehlerfrei und ohne manuelle Interaktion an die Firewall gestreamt.

Fazit Layer 1 & 2

Die Kombination aus einer dynamischen OSPF-Fabric und einer tief integrierten ISFW bildet den Schutzwall für die sensiblen Daten von Project Sentinel. Wir haben eine Infrastruktur geschaffen, die nicht nur Pakete schaufelt, sondern jede Verbindung aktiv auditiert.

Nächster Halt: Im nächsten Beitrag verlassen wir den physischen Maschinenraum und widmen uns der Governance (Layer 3) – wie wir NetBox und GitLab nutzen, um diesen gesamten Stack deklarativ zu steuern.

Status: Underlay Stabilized. Security Enforcement Active.