Feinschliff am Heimnetz — ein Tunnel nach Hause, Meldungen und Funkkanäle

Am Vormittag hatte ich beide Firewalls aufgeräumt und zu Hause einen Werbefilter eingerichtet. Der Rest des Tages ging in Dinge, die man nicht sieht, solange alles läuft: wie ich unterwegs nach Hause komme, wer mir Bescheid sagt, wenn etwas ausfällt, und auf welchem Kanal das WLAN funkt. Dazu kam ein neuer Plan für das Lab.

Ein zweiter Tunnel, nach Hause

Den Fernzugang ins Rechenzentrum gibt es seit Oktober. Jetzt kam ein zweiter dazu, der zu Hause auf der eigenen Firewall endet. Unterwegs schalte ich ein, was ich brauche: den Tunnel ins Rechenzentrum oder den nach Hause, nie beide, und ohne geteiltes DNS, bei dem je nach Name mal der eine, mal der andere Resolver antwortet.

Der Tunnel nach Hause ist ein voller Tunnel. Alles geht über den Anschluss zu Hause, und die Namen löst dieselbe Firewall auf, die dort auch den Werbefilter hat. Im Café oder im Hotel ist die Werbung damit genauso weg wie auf dem Sofa. Im Tunnel gelten dieselben Regeln wie im Verwaltungsnetz zu Hause; die Regeln habe ich nicht von Hand nachgebaut, sondern aus dem Verwaltungsnetz geklont.

Zwei Grenzen habe ich bewusst stehen lassen. Fällt zu Hause DSL aus und übernimmt das 5G-Modem, ist der Tunnel nach Hause nicht erreichbar, weil der Mobilfunk keine eingehenden Verbindungen durchlässt. Dann nehme ich den ins Rechenzentrum. Und unterwegs ist der Upload der Heimleitung die Grenze, nicht WireGuard.

Ein Skript für beliebig viele Tunnel

Die Schlüssel und Profile für die Geräte erzeugt seit Oktober ein Skript auf meinem Rechner; die privaten Schlüssel entstehen nur dort, nie auf einer Firewall. Es kannte genau einen Tunnel. Mit dem Notfallzugang und dem Tunnel nach Hause wurden es drei, und jede Erweiterung hätte fünf Stellen im Code berührt.

Jetzt ist jeder Tunnel eine kleine Datei: Gegenstelle, Netz, DNS, MTU, die Profile mit ihren erlaubten Zielen und das Format, in dem die Gegenstelle ihre Liste braucht. Die Geräte stehen in einer Tabelle, je Tunnel eine Spalte mit der Adresse oder einem Strich. Ein Gerät in einen weiteren Tunnel aufnehmen, aus einem herausnehmen oder neu verschlüsseln ist ein Befehl, die nächste freie Adresse sucht das Skript selbst. Ein vierter Tunnel wäre eine vierte Datei. Beide Dateien sind öffentlich und liegen im Git; die Ordner mit den Schlüsseln nicht.

Die Gegenstelle zu Hause habe ich wieder offline eingerichtet, wie am Vormittag: Konfiguration exportieren, die neuen Regeln, NAT und den Filter in die Datei schreiben, prüfen, dass jeder Verweis auf etwas Existierendes zeigt und sonst nichts anders ist, dann zurückspielen.

Ein Feld, das nicht hält, was es verspricht. Für WireGuard über PPPoE sollte TCP auf eine passende Segmentgröße begrenzt werden, sonst hängen größere Pakete. Ich habe den gewünschten Wert in das Feld „MSS“ am Interface geschrieben. Die Firewall zog davon noch einmal 40 Byte ab: Das Feld erwartet die MTU, nicht die MSS. Gemerkt habe ich es nur, weil ich im laufenden Regelwerk nachgesehen habe statt in der Oberfläche.

Wer Bescheid sagt

Der Omada-Controller verwaltet Switches und Access Points. Jetzt schickt er auch Mails, über den eigenen Mailserver im Rechenzentrum: wenn ein Gerät wegbleibt, eine Schleife entsteht, ein fremder DHCP-Server antwortet oder ein Port gesperrt wird.

Der erste Test brachte keine Mail. Der Grund: Es gibt zwei Arten von Meldungen. Einzelne Ereignisse wie „Gerät getrennt“ und darüber eine Auswertung, die erst anschlägt, wenn ein Gerät mehrmals in der Stunde ausfällt. Ich hatte nur die Auswertung angesehen, und einmal Kabel ziehen reicht dafür nicht.

Den Test selbst habe ich danach geändert. Statt das Kabel am Access Point zu ziehen, was das WLAN in der ganzen Wohnung abschaltet, habe ich zwei freie Switch-Ports mit einem Patchkabel verbunden. Der Switch hat die Schleife erkannt und den Port gesperrt, die Sturmbremse hatte vorher schon gedrosselt, und es kamen drei Mails. Das Netz lief dabei weiter.

Bewusst offen: Die Mails gehen durch den Tunnel ins Rechenzentrum. Ist der Tunnel weg, kommt vom Controller nichts an. Das Fehlen des Tunnels muss ohnehin die Gegenseite melden, denn wenn das Internet zu Hause ausfällt, kann von dort niemand mehr etwas schicken.

Signal ist nicht Auslastung

Für die Funkkanäle habe ich zuerst die Nachbarn gescannt. Auf Kanal 1 funkte eine FRITZ!Box deutlich hörbar, auf Kanal 11 nur ein paar Netze am Rand des Empfangs. Also Kanal 11. Die Auslastung stieg dort innerhalb von Minuten von 10 auf 47 Prozent; zurück auf Kanal 1 lag sie wieder bei 11.

Die Stärke eines Nachbarnetzes sagt nur, wie laut es ist, nicht wie viel es sendet. Ein leises Netz, das ständig funkt, belegt einen Kanal mehr als ein lautes, das schweigt. Seitdem entscheide ich nach der gemessenen Auslastung. Im 5-GHz-Band bleibt es bei 80 MHz ohne die Radarkanäle, das ist stabiler als die doppelte Breite mit gelegentlichen Abbrüchen; im 6-GHz-Band funkt in der Nachbarschaft noch niemand.

Was nicht geklappt hat: Die Access Points können Bonjour zwischen den VLANs weiterreichen, damit ein iPhone im Verwaltungsnetz den Drucker im Haushaltsnetz findet. Gefunden hat es weder Drucker noch Fernseher. AirPrint sucht nach einem Untertyp, den der Controller gar nicht eintragen lässt. Gedruckt wird vom Mac jetzt über die Adresse; vom iPhone nur, wenn es im Haushaltsnetz ist. Wird das mal lästig, kommt ein mDNS-Repeater auf die Firewall.

Das Lab wird kleiner und bekommt eine Aufgabe

Geplant waren drei Mini-PCs als Cluster mit einem eigenen Speicher und eigenem Switch. Gebraucht wird ein Ort, an dem ich Puppet und die Datensicherung ausprobieren kann, und ein Ausfall von ein, zwei Tagen ist dort kein Problem. Dafür reicht ein einziger Mini-PC, nur mit SSDs, damit er in der Wohnung leise bleibt.

Dazu bekommt er eine zweite Aufgabe: Er wird der Standort außer Haus für das Rechenzentrum. Eine vollständige Kopie der Proxmox-Sicherungen, das zweite Sicherungsziel und der Wächter, der die Überwachung überwacht, ziehen von einem Cloud-Anbieter nach Hause. Den Preis schreibe ich mir ausdrücklich auf: Zu Hause hängen Kopie und Original am selben Netzbetreiber und liegen in derselben Region. Bei einem Ausfall dieses Netzes oder einem großen Schaden in der Gegend sind beide betroffen. Die öffentlichen Nameserver bleiben deshalb, wo sie sind.

Die Kopie der Sicherungen läuft nicht über das offene Internet und nicht über die Firewall im Rechenzentrum, sondern über einen eigenen Tunnel direkt zum Hypervisor. Den gab es als Notfallzugang ohnehin im Plan: Fällt die Firewall-VM aus, komme ich darüber an den Host und an ihre Konsole. Jetzt hängt zusätzlich die Firewall zu Hause daran, mit Erlaubnis nur für den Sicherungsdienst. Die Kopie läuft damit gerade dann weiter, wenn die Firewall im Rechenzentrum ausfällt, und auch, wenn zu Hause das 5G-Modem übernimmt.

Was ich daraus mitnehme

Messen statt vermuten. Der Kanal mit den schwächsten Nachbarn war der vollste, das Feld mit dem richtigen Namen hatte die falsche Bedeutung, und die Meldung, die nicht kam, war richtig eingestellt. Jedes Mal hat das laufende System die Antwort geliefert, nicht die Oberfläche.

Einen Test wählen, der nichts kaputt macht. Eine Schleife an zwei freien Ports prüft dieselbe Meldekette wie ein gezogenes Kabel am Access Point, ohne dass jemand ohne WLAN dasitzt.

Was etwas kostet, gehört in die Doku. Kopie und Original in derselben Region ist eine Entscheidung, kein Versehen. Steht sie aufgeschrieben, muss sie beim nächsten Blick niemand neu herleiten.