Ein Internetanschluss reicht in den meisten Haushalten vollkommen aus.
Bei mir inzwischen nicht mehr.
Der Grund ist weniger „weil man es kann“, sondern eine Mischung aus instabiler Leitung, Homeoffice, Homelab und dem Wunsch, aktuelle Netzwerkfunktionen nicht nur in einer Demo-Umgebung zu testen.
Aus einem simplen LTE-Fallback ist deshalb inzwischen ein deutlich interessanteres Setup geworden: zwei voneinander unabhängige Internetzugänge und Palo Alto SD-WAN.
Die Ausgangslage: Internet auf dem Land
Ich wohne auf dem Land. Mein bestehender Internetanschluss läuft über Inexio und auf der letzten Strecke über eine alte Kupferleitung.
Technisch funktioniert das grundsätzlich.
Die Verbindung ist aber weder besonders schnell noch so stabil, wie ich es gerne hätte. Immer wieder gab es Probleme oder komplette Ausfälle.
Beim normalen Surfen ist ein kurzer Ausfall ärgerlich.
Wenn man gerade in einem Teams-Call sitzt oder remote arbeitet, sieht das anders aus.
Und genau da fing das Projekt an.
Der erste Versuch: LTE als Backup
Die naheliegende Lösung war zunächst ein LTE-Router mit einer Prepaid-SIM.
Kein kompliziertes Setup. Kein zweiter Festnetzvertrag.
Einfach Mobilfunk als Backup.
Der LTE-Router wurde als zweiter WAN-Zugang an meine Palo-Alto-Firewall angebunden.
Das Failover lief über einen klassischen Virtual Router mit:
- Path Monitoring
- unterschiedlichen Routing Metrics
- einer primären Route über den Festnetzanschluss
- einer Backup-Route über LTE
Die Idee dahinter war simpel:
Solange der Hauptanschluss funktioniert, wird er verwendet.
Fällt er aus, entfernt die Firewall die entsprechende Route und der Datenverkehr läuft über LTE weiter.
Technisch hat das funktioniert.
Aber eben nicht so, wie ich es im Alltag wollte.
15 Sekunden können ziemlich lang sein
Bei meinen Tests dauerte die Umschaltung ungefähr 15 Sekunden.
Für viele Anwendungen ist das gar nicht dramatisch.
Eine Webseite lädt kurz nicht. Ein Download hängt einen Moment. Danach geht es weiter.
Bei Echtzeitanwendungen sieht es anders aus.
Ein laufender Teams-Call hat die Umschaltung nicht einfach unbemerkt überstanden.
Die Session war weg.
Damit war das LTE-Backup zwar besser als überhaupt kein zweiter Zugang, aber es löste mein eigentliches Problem nur teilweise.
Ich hatte Redundanz.
Aber keine wirklich gute Ausfallsicherheit für laufende Verbindungen.
Backup ist nicht automatisch Resilienz
Das war für mich die entscheidende Erkenntnis des ersten Setups.
Zwei WAN-Interfaces bedeuten noch lange nicht, dass ein Netzwerk tatsächlich resilient ist.
Ein klassisches Routing-Failover beantwortet im Wesentlichen nur eine Frage:
Ist der primäre Pfad noch erreichbar oder nicht?
In der Praxis interessieren mich aber deutlich mehr Dinge.
Zum Beispiel:
- Wie hoch ist die Latenz?
- Gibt es Packet Loss?
- Wie stark schwankt die Verbindung?
- Ist ein Pfad zwar technisch erreichbar, aber praktisch kaum noch nutzbar?
- Welche Anwendungen sollen welchen Internetzugang verwenden?
- Wann sollte auf einen anderen Pfad gewechselt werden?
Damit war ziemlich schnell klar, in welche Richtung das Projekt weitergehen sollte.
Warum Starlink?
Als zweiter WAN-Link wollte ich diesmal nicht einfach nur einen weiteren Zugang, der womöglich an ähnlicher lokaler Infrastruktur hängt.
Starlink ist dafür interessant, weil der Zugang technisch komplett anders realisiert wird als mein bestehender Anschluss über Kupfer.
Damit bekomme ich zwei sehr unterschiedliche Wege ins Internet:
WAN 1: terrestrischer Anschluss über die bestehende lokale Infrastruktur
WAN 2: Starlink über Satellit
Natürlich bedeutet das nicht, dass Starlink automatisch perfekt oder ausfallsicher ist.
Aber für mein Homelab ist genau diese Kombination spannend.
Sie gibt mir die Möglichkeit, zwei sehr unterschiedliche WAN-Verbindungen unter realen Bedingungen miteinander zu vergleichen.
Und damit kommt SD-WAN ins Spiel
Ich arbeite im Bereich IT-Security und nutze mein Homelab unter anderem dazu, aktuelle Palo-Alto- und PAN-OS-Funktionen praktisch zu testen.
Aktuell läuft die Umgebung auf PAN-OS 12.1.
Ein klassischer Virtual Router mit statischen Routen und Path Monitoring war deshalb für mich nicht das Ende des Experiments.
Der nächste Schritt ist Palo Alto SD-WAN.
SD-WAN kann deutlich mehr als nur:
„Leitung A ist weg, also benutze Leitung B.“
Interessant wird es vor allem dann, wenn die Qualität verschiedener Pfade berücksichtigt wird.
Je nach Konfiguration können Kriterien wie Latenz, Jitter und Packet Loss in die Auswahl des WAN-Pfads einfließen.
Damit lässt sich beispielsweise untersuchen, ob bestimmte Anwendungen gezielt über den aktuell besseren Link geführt werden können.
Genau das möchte ich zuhause testen.
Nicht in einer Lab-Simulation.
Sondern auf einem Netzwerk, das tatsächlich täglich genutzt wird.
Was ich testen möchte
Das Projekt ist noch nicht abgeschlossen.
Das ist Absicht.
HomeLabNext soll nicht nur fertige Ergebnisse zeigen, sondern auch den Weg dorthin.
Für das Setup interessieren mich unter anderem folgende Fragen:
Wie schnell reagiert SD-WAN auf einen Ausfall?
Der bisherige klassische Failover lag ungefähr bei 15 Sekunden.
Mich interessiert, wie sich das mit SD-WAN verhält und welche Parameter dabei tatsächlich entscheidend sind.
Was passiert mit laufenden Sessions?
Besonders spannend sind Echtzeitanwendungen.
Also zum Beispiel:
- Microsoft Teams
- VoIP
- Videokonferenzen
- längere TCP-Verbindungen
Ein Failover ist für mich erst wirklich interessant, wenn ein Benutzer möglichst wenig davon mitbekommt.
Wie sinnvoll sind Path-Quality-Messungen im Heimnetz?
Latenz, Jitter und Packet Loss klingen auf dem Papier hervorragend.
Ich möchte sehen, wie zuverlässig sie mit zwei sehr unterschiedlichen Internetzugängen in der Praxis funktionieren.
Kann man Anwendungen sinnvoll auf beide Links verteilen?
Vielleicht ist Starlink nicht immer der Backup-Link.
Vielleicht ergibt es bei bestimmten Anwendungen mehr Sinn, abhängig von der aktuellen Leitungsqualität dynamisch zwischen beiden Verbindungen zu wählen.
Auch das möchte ich ausprobieren.
Wie stabil ist Starlink im Alltag?
Ein Speedtest alleine sagt wenig aus.
Mich interessieren eher Dinge wie:
- langfristige Stabilität
- kurze Unterbrechungen
- Latenzschwankungen
- Verhalten bei schlechtem Wetter
- Zusammenspiel mit der Firewall
- reale Auswirkungen auf Anwendungen
Warum überhaupt so viel Aufwand zuhause?
Natürlich braucht niemand zwingend eine Enterprise-Firewall und SD-WAN im eigenen Haus.
Darum geht es auch nicht.
Mein Homelab ist für mich gleichzeitig produktives Heimnetz und Testumgebung.
Viele Funktionen lassen sich theoretisch lesen oder in einer isolierten Testumgebung konfigurieren.
Interessanter finde ich aber die Frage:
Wie verhält sich die Technik, wenn sie tatsächlich benutzt wird?
Wenn gerade jemand streamt.
Wenn Home Assistant läuft.
Wenn ein Teams-Call aktiv ist.
Wenn mehrere VLANs und Geräte gleichzeitig Daten übertragen.
Und wenn dann plötzlich ein Internetzugang ausfällt.
Genau solche Situationen machen ein Homelab für mich interessant.
Wie es weitergeht
Das aktuelle Ziel sieht deshalb so aus:
Inexio / Kupfer + Starlink + Palo Alto SD-WAN
In einem der nächsten Beiträge möchte ich die konkrete Konfiguration zeigen.
Dabei geht es unter anderem um:
- WAN-Anbindung
- SD-WAN-Interfaces
- Path Quality Profiles
- Traffic Distribution
- Routing
- Failover-Tests
- Messwerte
- Probleme und Einschränkungen
Und natürlich auch darum, ob der ganze Aufwand am Ende wirklich einen spürbaren Vorteil gegenüber meinem bisherigen LTE-Fallback bringt.
Denn genau das ist für mich die entscheidende Frage.
Nicht:
Kann man es konfigurieren?
Sondern:
Funktioniert es im Alltag wirklich besser?