Ausgangslage: ein blinder Fleck

Es gibt diesen einen Rechner, der zu Hause im lokalen Netz steht: ein kleiner Kubernetes-Cluster auf ein paar unprivilegierten Containern, dazu der Virtualisierungs-Host darunter. Er tut brav seinen Dienst — aber er ist eine Insel. Vom zentralen Server aus nicht erreichbar, und, schlimmer: dem zentralen Sicherheits-Monitoring komplett unsichtbar. Jeder andere Rechner meldet seine Datei-Änderungen, Logins und Auffälligkeiten an eine Stelle. Dieser hier: schweigt.

Das Ziel war deshalb simpel formuliert und in der Umsetzung überraschend lehrreich: den Cluster in das private VPN-Mesh einbinden und einen Monitoring-Agenten darauf laufen lassen, der an das zentrale SIEM meldet — ohne die gemeinsam genutzte Infrastruktur des Hauptservers anzufassen, und als sauberes Infrastructure-as-Code, nicht als Handarbeit.

Anbindung: den Node ins Mesh, nicht das Netz aufreißen

Für „ein Gerät im fremden LAN erreichbar machen" gibt es zwei Wege. Man kann einen Subnetz-Router aufsetzen: ein Gerät, das bereits im VPN und im lokalen Netz hängt, wirbt für das ganze Subnetz und leitet weiter. Bequem — aber es zieht das komplette Heimnetz ins VPN. Jeder Drucker, jede Kamera wird für alle VPN-Teilnehmer erreichbar. Deutlich mehr Angriffsfläche, als man für einen einzigen Dienst wollte.

Der chirurgische Weg: jeden Node direkt ins Mesh aufnehmen. Er bekommt seine eigene VPN-Adresse, und nur er wird erreichbar. Ein wiederverwendbarer Vorab-Schlüssel automatisiert die Anmeldung, ein Tag sorgt dafür, dass der Schlüssel des Dauerläufers nicht abläuft. Für Infrastruktur, die man versteht und schmal halten will, ist das die richtige Wahl.

Die Container-Falle: kein Tunnel-Gerät

Der erste Stolperstein kam sofort. Der VPN-Client braucht ein Tunnel-Gerät (/dev/net/tun) — und in einem unprivilegierten Container existiert das nicht. Es gäbe einen Notausgang, den „Userspace"-Modus ohne echtes Interface, aber dann kann der Monitoring-Agent die Gegenstelle nicht erreichen. Das wäre eine halbe Lösung, die genau das kaputt macht, worum es geht.

Die saubere Antwort liegt eine Ebene tiefer: Der Virtualisierungs-Host reicht das Tunnel-Gerät in den Container durch. Ein kleiner Eintrag in der Container-Definition, ein einmaliger Neustart — und der Client bekommt ein echtes Interface. Kein Workaround, sondern die Ursache behoben.

Monitoring über das VPN — und die Frage nach dem Enrollment

Der Agent meldet sich über das VPN an das zentrale SIEM. Zwei Ports sind im Spiel: einer für die laufende Kommunikation, einer für die Erst-Anmeldung (das „Enrollment"). Der Kommunikations-Port ist ohnehin nur im VPN erreichbar. Beim Enrollment aber steht eine echte Design-Entscheidung an.

Variante A — von Hand, Port bleibt zu. Man registriert jeden Agenten am Server, erzeugt dort seinen Schlüssel und legt ihn beim Agenten ab. Der Enrollment-Port muss dafür nie nach außen. Maximal geschlossen — aber pro neuem Node ein manueller Handgriff.

Variante B — Selbst-Anmeldung über das VPN. Der Enrollment-Port wird ausschließlich im VPN geöffnet und zusätzlich mit einem Registrierungs-Passwort geschützt. Neue Agenten melden sich beim ersten Start selbst an. Das skaliert — ein Node mehr ist kein Handgriff mehr.

Zuerst lief Variante A, ganz bewusst. Als klar wurde, dass mehrere Nodes folgen würden, wechselte ich auf B — aber mit klarer Abwägung: Der Port ist nie öffentlich, nur im verschlüsselten Mesh, und ohne das gemeinsame Passwort meldet sich niemand an. Diese Umstellung ist kein „aufgeweicht", sondern eine dokumentierte Entscheidung mit benannten Kosten.

Drei Bugs, die Idempotenz aufdeckt

Der eigentliche Wert von Infrastructure-as-Code zeigt sich nicht beim ersten Lauf, sondern beim zweiten. Ein idempotenter Lauf soll melden: „nichts zu tun". Genau dieser Test-gegen-sich-selbst hat drei echte Fehler ans Licht geholt, die man sonst nie bemerkt hätte.

1. Die Reboot-Schleife. Die Konfigurationsdatei des Virtualisierungs-Hosts wird vom System im Hintergrund umsortiert. Mein Automatisierungs-Skript setzte den Tunnel-Eintrag über einen „Block mit Markierung" — und weil die Zeilen jedes Mal woanders landeten, galt der Block bei jedem Lauf als „geändert". Folge: Der Container wurde bei jedem Durchlauf neu gestartet, und die Einträge vervielfältigten sich. Erkannt nur, weil der zweite Lauf nicht „0 Änderungen" zeigte. Fix: kein Markierungsblock, sondern schlicht prüfen, ob die Zeile schon existiert.

2. Das API-Modul, das den Schlüssel verstümmelt. Das Standard-Modul zum Anlegen von Containern lehnte den hinterlegten SSH-Schlüssel mit einem generischen Serverfehler ab — nur bei Neu-Anlagen. Der Beweis, dass nicht der Schlüssel schuld war: Derselbe Schlüssel funktionierte über das Kommandozeilen-Werkzeug tadellos. Also raus mit dem Modul, rein mit dem nativen Befehl. Manchmal ist die „saubere" Abstraktion der Fehler.

3. Der stille Versions-Drift. Ein routinemäßiges System-Update hatte den Monitoring-Agenten unbemerkt auf eine Version gehoben, die neuer war als der zentrale Server — was nicht unterstützt wird. Der nächste Deploy scheiterte am Downgrade. Doppelter Fix: die Agent-Version fest auf das Server-Niveau nageln und das Paket „festhalten", damit das nächste Update sie nicht wieder anhebt.

Der Lohn: ein Node mehr = ein Eintrag mehr

Nach all dem Feintuning kommt die Belohnung. Einen weiteren Arbeiter-Node hinzuzufügen bedeutet jetzt: einen Eintrag in der Inventar-Datei, ein git push, und die Automatisierung durchlaufen lassen. Der Container entsteht, wird gehärtet, tritt dem Cluster bei, hängt sich ins VPN und meldet sich von selbst beim Monitoring an. Vom „blinden Fleck" zum „ein Handgriff pro Node".

Und das Ganze läuft nicht mehr von einem Laptop, sondern über einen zentralen Automatisierungs-Runner mit Weboberfläche: Man trägt die Änderung ein und drückt auf „Start". Sogar die regelmäßige Wartung — Updates, kontrolliertes Neustarten Node für Node — hängt an einem wöchentlichen Zeitplan. Der Cluster pflegt sich weitgehend selbst.

Was man mitnimmt

• Schmal exponieren. Einzelne Maschinen ins Mesh nehmen schlägt fast immer das bequeme „ganzes Subnetz aufreißen".
• Ursachen beheben, nicht umgehen. Das fehlende Tunnel-Gerät wurde durchgereicht, nicht mit einem Halb-Modus überbrückt.
• Kompromisse benennen. Ein bewusst geöffneter Port im VPN mit Passwort ist eine Entscheidung mit Preisschild — kein Versehen.
• Idempotenz ist ein Test. Der zweite Lauf hat drei Bugs gefunden, die der erste versteckt hatte.
• Automatisieren lohnt sich erst ab „einmal mehr". Der Aufwand vorne zahlt sich beim zweiten, dritten, zehnten Node zurück.

Ein blinder Fleck im Monitoring ist keine Kleinigkeit — er ist genau die Ecke, in der man später nicht nachsehen kann. Ihn zu schließen war kein einzelner Handgriff, sondern eine Kette kleiner, bewusster Entscheidungen. Und am Ende ein System, das man mit einem Eintrag wachsen lässt.