Zwei Netze, die sich nicht sehen dürfen

Ich brauchte einen vollständigen Klon meines Minecraft-Netzwerks: dieselben Server, dieselben Welten, dieselbe Konfiguration — aber ohne jede Verbindung zum Livebetrieb.

Ein Klon ist schnell gemacht. Ihn wirklich zu trennen ist die eigentliche Arbeit, und es ist eine, bei der man nichts übersehen darf.

Warum ein Klon gefährlich ist

Ein kopierter Server bringt die gesamte Konfiguration des Originals mit. Und in dieser Konfiguration stehen Adressen — Datenbanken, Schnittstellen, Webhooks, Verzeichnisse.

Ein Klon, den man einfach startet, verbindet sich also mit denselben Zielen wie das Original. Er schreibt in dieselbe Datenbank, meldet sich an denselben Diensten an, schickt Ereignisse an dieselben Empfänger.

Das ist nicht theoretisch: Ein Testserver, der Rechte in die Live-Datenbank schreibt, kann im Livebetrieb Rechte ändern. Ein Testserver, der Statistiken meldet, verfälscht die echten Zahlen.

Die fünf Stellen

Bei meinem Klon waren es genau fünf, und ich schreibe sie auf, weil die Liste für die meisten solchen Aufbauten stimmen dürfte.

1. Die gemeinsame Rechte-Datenbank. Der wichtigste Punkt. Der Klon bekommt eine eigene, oder er läuft auf lokaler Datenhaltung.

2. Die Statistikanbindung. Wenn Spielerdaten an einen zentralen Dienst gemeldet werden, meldet der Klon in denselben Topf.

3. Die Auslieferung von Paketen. Adressen, unter denen Texturenpakete liegen. Solange nur gelesen wird, ist das harmlos — sobald eine Seite schreibt, nicht mehr.

4. Verbindungen zwischen den Servern des Netzwerks. Meine Server tauschen untereinander Daten aus. Ein Klon, der die Adressen des Originals behält, meldet sich bei den echten Servern.

5. Der Proxy-Eintrag. Ein Klon darf nicht im Proxy des Livebetriebs stehen — sonst landen echte Spieler darauf.

Die Stelle, die nicht offensichtlich ist

Die fünfte hat einen Nachbarn, den ich beinahe übersehen hätte: Ein verschobener Server behält seinen Besitzer.

Mein Panel kennt Benutzerkonten, und die Sichtbarkeit von Diensten hängt daran, wem sie gehören. Der Klon sollte einem eigenen Konto gehören, damit nur dieses Konto ihn sieht — und damit dieses Konto nichts anderes sieht.

Beim Verschieben eines Dienstes zwischen Maschinen wird der Besitzer aber nicht mitgeändert. Ein Server, den ich für den Klon vorgesehen hatte, hing danach weiterhin am ursprünglichen Konto und tauchte für das neue gar nicht auf.

Das ist eine Kleinigkeit mit zwei unangenehmen Seiten: Der Zugriff funktioniert nicht wie gedacht, und die Trennung, die man aufgebaut hat, existiert nicht.

Die Trennung im Netz

Zusätzlich zur Konfiguration braucht es eine Trennung auf Netzebene, und zwar aus einem einfachen Grund: Konfiguration kann man vergessen, Netzgrenzen nicht.

Bei mir liegen die beiden Netze auf verschiedenen Maschinen. Damit ist die Trennung physisch, und ein vergessener Eintrag führt zu einem Verbindungsfehler statt zu einem stillen Schreibzugriff.

Ein Verbindungsfehler ist die freundlichste Fehlerart, die es gibt. Er ist laut, er ist sofort sichtbar, und er richtet keinen Schaden an. Das ist ein Argument, das ich bei solchen Aufbauten inzwischen bewusst mitdenke: Man baut nicht nur so, dass es funktioniert, sondern so, dass Fehler in die harmlose Richtung fallen.

Der eigene Eingang

Der Klon hat einen eigenen Zugang unter einer eigenen Adresse und einem eigenen Port. Das ist wichtiger, als es klingt: Solange beide Netze über denselben Eingang erreichbar wären, hinge die Trennung an einer Konfigurationszeile.

Ein Nebeneffekt, über den ich mich gefreut habe: Für die Adresse brauchte es keinen neuen Eintrag in der Namensauflösung, weil ein Platzhalter für alle Unteradressen bereits auf die richtige Maschine zeigt. Solche Vorarbeiten zahlen sich Monate später aus, ohne dass man daran denkt.

Wie ich einen Klon anlege

Aus diesem Aufbau ist eine Reihenfolge geworden, die die Trennung vor die Inbetriebnahme stellt.

1. Kopieren, aber nicht starten. Der wichtigste Schritt. Ein Klon, der einmal gestartet wurde, hat möglicherweise schon irgendwo geschrieben.

2. Alle Verbindungen nach außen suchen und kappen. Datenbankadressen, Schnittstellen, Webhooks, Nachbarserver. Bei mir sind das fünf feste Stellen, und die Liste steht in den Notizen.

3. Eigene Kennungen vergeben. Eigener Eingang, eigener Port, eigener Name.

4. Besitzverhältnisse prüfen. Wem gehört der Dienst im Panel, und wer sieht ihn?

5. Erst dann starten — und danach prüfen, ob irgendwo eine Verbindung ins Live-System versucht wurde. Das steht in den Protokollen, wenn man danach sucht.

Schritt 5 ist die Kontrolle für Schritt 2. Ein Verbindungsversuch, der fehlschlägt, ist ein Fund — er zeigt eine Stelle, die ich übersehen habe, und zwar bevor sie Schaden anrichten konnte.

Warum ein Testnetz mehr wert ist, als es kostet

Ein vollständiger Klon verbraucht Ressourcen für etwas, das niemand benutzt. Das ist der offensichtliche Einwand, und er stimmt.

Was er ermöglicht, ist trotzdem mehr wert:

Änderungen ausprobieren, ohne Angst. Ein Versionssprung, ein neues Plugin, eine Konfigurationsänderung — alles zuerst dort.

Fehler nachstellen. Wenn etwas im Livebetrieb schiefgeht, kann man es im Klon reproduzieren, ohne die Leute zu stören, die gerade spielen.

Rückwege üben. Eine Sicherung zurückspielen ist eine Übung, die man einmal gemacht haben sollte, bevor man sie unter Druck macht.

Der dritte Punkt ist der, den ich am meisten unterschätzt hatte. Beim ersten Rückspielversuch im Klon habe ich einen Fehler in meinem eigenen Sicherungsverfahren gefunden — ein zu weit gefasstes Ausschlussmuster, durch das Plugin-Konfigurationen nicht im Archiv landeten.

Diesen Fehler hätte ich sonst im Ernstfall gefunden. Das ist der Zeitpunkt, an dem man ihn am wenigsten gebrauchen kann.

Was ich mitnehme

Ein Klon ist kein Kopiervorgang, sondern ein Trennungsvorgang. Die Kopie dauert Minuten, die Trennung Stunden — und nur die Trennung entscheidet, ob der Klon sicher ist.

Die Liste der Verbindungen nach außen sollte man einmal aufschreiben. Nicht beim Klonen, sondern vorher, für das Original. Dann ist sie beim nächsten Klon eine Prüfliste statt einer Suche.

Physische Grenzen schlagen konfigurierte. Wo es geht, trennt man auf einer Ebene, die man nicht versehentlich aufheben kann.