Siebzehn Tage lag der Fix bereit — weil er als „Nutzeraktion“ galt

Mein Tor-Relay läuft als Container mit strenger Isolation: Es darf ins Internet, aber nie ins LAN, nie zum Host, nie in andere Container-Netze. Vier Drop-Regeln in der DOCKER-USER-Chain erzwingen das. Seit Ende August hat das Relay außerdem einen MetricsPort, und HomeOS hat eine Seite dafür — die siebzehn Tage lang nur „n/a" zeigte.

Die Diagnose dauerte Sekunden, sobald man hinsah: iptables -L -v mit Paketzählern. Regel 3 — Container-Netz nach Docker-Netze verwerfen — stand bei 39 285 Paketen. Das waren keine Angriffsversuche des Relays auf meine Infrastruktur. Das waren seine Antworten an den Scraper im Netz des Control Centers. Die Conntrack-Regel, die Antworten bestehender Verbindungen durchlässt, stand an Position 6. Hinter den Drops.

Vom Host aus antwortete der Port übrigens — der Loopback-Pfad umgeht die Chain. Ein Test, der nichts über den Pfad aussagt, den der Scraper wirklich nimmt. Die Probe muss aus dem Netz kommen, das später misst.

Der Fix war längst geschrieben. Conntrack nach vorn, die Isolations- Drops dahinter, dazu eine Regel, die den MetricsPort vom LAN-Interface aus sperrt. Das Skript lag geprüft auf dem Server, mit Diff und Backup. Es stand auf der Liste der Dinge, die nur ein Mensch tun darf — zwei sudo-Befehle. Und dort blieb es. Siebzehn Tage.

Der Grund war nicht technisch. Das Werkzeug, mit dem ich arbeite, stufte Schreibzugriffe per SSH auf den Server als Aktion ein, die ich selbst auslösen muss. Vernünftig als Standard. Nur hatte ich die Aktion nie ausgelöst, weil sie auf einer Warteliste stand statt in der Session. Nachdem ich sie ausdrücklich freigegeben hatte, dauerte die Freischaltung eine Minute — und die Regel gilt seitdem: Reversible Live-Änderungen mit Backup gehören mit Freigabe in die Session, nicht auf eine Liste.

Verifiziert, nicht nur geändert. Conntrack an Position 1. Scrape-Target grün, erste Metriken nach einer Minute. Isolation intakt: Aus dem Container heraus laufen Verbindungsversuche zum DNS-Server, zum Host und ins Control-Center-Netz weiter in den Timeout, und die Drop-Zähler laufen hoch — nur Antworten passieren, nie neue Verbindungen. Der MetricsPort ist aus dem LAN weiterhin zu.

Regelreihenfolge ist Semantik. Eine Drop-Regel vor Conntrack blockt nicht nur Initiierungen, sondern auch Antworten — in beide Richtungen unsichtbar, solange niemand von innen scrapt. Und ein Fix, der siebzehn Tage gestaged liegt, ist ein Fix, der nicht existiert.