Es fing damit an, dass ich einen neuen Dienst hochzog — zwei Container, eine
Datenbank, nichts Besonderes. Danach war die Fernwartung tot. Nicht langsam,
nicht fehlerhaft: keine Antwort mehr, als gäbe es den Rechner nicht.
Das Verwirrende war, dass alles andere weiterlief. Sämtliche Dienste waren
von außen erreichbar, die Überwachung meldete durchgehend grün. Nur der direkte
Weg aus dem eigenen Netz war weg.
Was passiert war
Container-Netze brauchen Adressbereiche, und der Dienst vergibt sie selbst,
wenn man ihm keine vorgibt. Er arbeitet dabei eine Liste ab. Ganz oben stehen
die üblichen Verdächtigen im 172er-Bereich. Sind die aufgebraucht — und mit
fünfzehn Stapeln ist man da schneller, als man denkt —, geht es weiter mit
192.168.0.0/16, aufgeteilt in Blöcke zu je 4096 Adressen.
Der erste dieser Blöcke deckt alles von 192.168.0.0 bis
192.168.15.255 ab. Wer sein Hausnetz in diesem Bereich betreibt,
hat ein Problem: Der Rechner hat plötzlich zwei Wege zu denselben Adressen und
nimmt den spezielleren — die Brücke. Antworten an das eigene Netz landen ab
sofort im Container-Netz und verschwinden.
Warum es so schwer zu sehen ist
Die Dienste liefen weiter, weil eingehende Verbindungen von außen kommen und
über einen vorgelagerten Proxy hereingereicht werden. Dieser Weg berührt die
kaputte Route nie. Kaputt war nur die Gegenrichtung ins eigene Netz — und die
benutzt im Alltag fast nur die Fernwartung.
Wer in dieser Lage die Dienste prüft, bekommt Entwarnung und sucht an der
falschen Stelle. Die eine Frage, die es entscheidet, lautet: Welchen Weg nimmt
der Rechner zu einer Adresse in meinem Netz? Zeigt die Antwort einen
Brückennamen statt der Netzwerkkarte, ist der Fall klar.
Herauskommen ohne Fernwartung
Genau dafür ist der Gastagent der Virtualisierung da. Über ihn lassen sich
Befehle in der Maschine ausführen, ohne eine Netzverbindung zu ihr zu haben —
der Weg führt über den Wirt. Stapel herunterfahren, Netz verschwindet, Route
kommt zurück. Bei mir war es damit in unter einer Minute erledigt.
Wer das nicht hat, muss an die Konsole. Es lohnt sich, vorher zu wissen,
welchen Weg man in dieser Lage hätte.
Damit es nicht wieder passiert
Zwei Ebenen. Erstens: Jedem Stapel den Adressbereich fest vorgeben statt ihn
zuteilen zu lassen. Das ist eine Zeile in der Stapeldatei und beendet die
Zufälligkeit sofort.
Zweitens, gründlicher: dem Dienst insgesamt vorschreiben, aus welchem Vorrat
er vergeben darf. Das steht in seiner Konfigurationsdatei und wirkt für alle
künftigen Netze. Bestehende behalten ihre Bereiche, nur das Standardnetz wird
neu vergeben.
Bei der Wahl des Vorrats gibt es eine Falle, in die ich prompt getappt bin:
Ich nahm zusätzlich einen Bereich aus 10.0.0.0/8 — und dieser
Bereich stand in einer Zugriffsliste meines Proxys, die interne Netze
freigibt. Das Standardnetz landete darin, und damit war die Brücke plötzlich
freigegeben. Zurückgenommen und auf einen Bereich beschränkt, der in keiner
meiner Listen vorkommt.
Und ein selbstverschuldeter Ausfall obendrauf
Beim Korrigieren schrieb ich einen erklärenden Kommentar in die
Konfigurationsdatei — als zusätzlicher Schlüssel, weil das Format keine
Kommentare kennt. Die Prüfung sagte mir das auch. Ich spielte die Datei
trotzdem ein, weil Prüfung und Einspielen bei mir zwei getrennte Schritte
waren und ich das Ergebnis der ersten nicht ausgewertet hatte.
Der Dienst startete nicht mehr. Alle Container standen, gut eine Minute
lang. Die Lehre ist banal und trotzdem teuer: Wenn ein Werkzeug eine Prüfung
anbietet, muss das Einspielen von deren Ergebnis abhängen — nicht danebenstehen.