[PROLOG]
Traurig aber wahr: Auf der Arbeit dümpeln wir mit einer miserablen Internetbandbreite herum. Wir haben zwar keine wirklich großen Anforderungen, da unsere Datenmengen eher überschaubar sind, aber eine 24 MB große Email ist mit 1Mbit/s Upload nicht „mal eben schnell“ verschickt und die Zukunft steht ja auch irgendwie vor der Tür und wird mehr Bandbreite fordern.
Dann endlich war es so weit und ein Provider kann uns einen Glasfaseranschluss bereitstellen, diesen wollen wir aus bestimmten Gründen allerdings nur zusätzlich als Hauptleitung nutzen. Die bestehende Leitung soll seine „bestimmten Aufgaben“ behalten und zusätzlich als Failover dienen. Kurze Rücksprache mit unserem externen IT-Dienstleister… dieser sagt dass dies und das und jenes mit dem Provider und der hier eingesetzten Firewall-/ Routerlösung (die Lizenzen kosten richtig viel Kohle!) nicht so richtig funktioniert und es auch offiziell nicht supported wird. WTF? Es geht hier doch nur darum den OVPN Server an diesem (CGNAT) Anschluss zu betreiben und ein Multi-WAN (Failover) einzurichten?!
Also kurzer Prozess: Der Anschluss wird bestellt, entweder läuft das dann oder die hochpreisige Super-Software wird durch OPNsense ersetzt, hier ist das alles nämlich kein Problem!
Angefangen wird natürlich beim Multi-WAN, dessen Einrichtung ich in diesem Artikel beschreibe. Im nachfolgenden Artikel über die Erstellung eines OpenVPN Servers werde ich auch kurz auf das Multi-WAN im Zusammenspiel mit OVPN eingehen.
[VORBEREITUNGEN]
Bevor es an das Multi-WAN Setup geht müssen natürlich die erforderlichen WAN-Interfaces funktionsfähig konfiguriert sein, im Nachfolgenden behandeln wir zwei Interfaces (Glasfaser WAN und LTE). Dabei spielt es keine entscheidende Rolle, ob das Interface über Ethernet oder z.B. direkt über eine Erweiterungskarte angebunden ist.
Durchaus eine entscheidende Rolle spielt hier aber IPv6, denn IPv6 und Multi-WAN funktioniert nur, wenn die Interfaces eine statische IPv6 Adresse haben, was zumindest im fortschrittlichen Deutschland auch in 2022 noch kein Standard ist. Aber keine Sorge: Für den Failover-Betrieb ist IPv4 heute noch völlig ausreichend, weshalb wir das Multi-WAN Failover nur für IPv4 einrichten, IPv6 funktioniert im Failover-Betrieb dann halt nicht mehr. Sollte man das Multi-WAN als Lastverteilung nutzen wollen, so würde eben nur IPv4 Traffic verteilt werden, während IPv6 Traffic statisch auf einem Interface bleibt.
Es bleibt also festzuhalten: IPv6 muss nicht deaktiviert werden!
[EINRICHTUNG DES MULTI-WAN]
Gateways konfigurieren
Insbesondere für ein Failover ist es erforderlich, dass die WAN-Interfaces überwacht werden, damit ein Ausfall erkannt wird und auf die Ersatzleitung umgeschwenkt werden kann. Dies geschieht mit den Monitor-IPs, welche in definierbaren Abständen angepingt werden um die Funktion der Verbindung zu überprüfen. Dazu gehen wir nach System / Gateways / Single und bearbeiten das erste WAN-Interface (im Beispiel LTE) mit dem Stift-Symbol.
Hier nehmen wir den Haken bei „Disable Gateway Monitoring“ raus und geben bei “Monitor IP“ eine beliebige IP eines im Internet erreichbaren (DNS-)Servers ein. Ich verwende hier den Google-DNS Server 8.8.8.8. Der Grund, weshalb ich DNS-Server nehme folgt…
Achtung:
Die hier angegebene IP Adresse ist nur dann erreichbar, wenn das Gateway aktiv, also in Verwendung ist! In diesem Fall ist 8.8.8.8 also nur erreichbar, wenn das WAN-Interface / die Verbindung ausgefallen ist. Daher sollten als Monitor IP nur IPs verwendet werden, die man sonst nicht nutzen / erreichen möchte. Dies gilt nicht für die Lastverteilung, allerdings wird der angegebene Server hier ausschließlich von dem entsprechenden Gateway angesprochen.
Außerdem stellen wir die Gateway-Priorität ein. Da es sich hier um das LTE Interface handelt, welches nur zweitrangig genutzt werden soll, wird ein recht hoher Wert (niedrige Prio) eingestellt. Auf eine Lastverteilung hat dies keine Auswirkung. Dann werden die Einstellungen gespeichert.
Dies wird nun für das andere WAN-Interface wiederholt, allerdings muss eine anderere Server IP verwendet werden (ich nehme hier Quad 9: 9.9.9.9) und die Gateway-Priorität wird auf einen niedrigeren Wert (höhere Prio) eingestellt als beim LTE-Interface.
Nun übernehmen wir die Einstellungen. Nicht von der im Screenshot gezeigten Gateway-IP beirren lassen, bei mir auf dem Testsystem haben beide Interfaces das gleiche Gateway.
Jetzt aktualisieren wir die Seite im Browser und bekommen den aktuellen Status der Gateways angezeigt: Das WAN-Gateway ist mit „(active)“ gekennzeichnet was bedeutet, dass dies das Gateway (die Verbindung) ist, das verwendet wird. Das liegt an der höheren Priorität und dem “online” Status. Würde die angegebene Monitor-IP nicht mehr erreichbar sein, wechselt der Status zu „offline“ und es wird das nächste Gateway verwendet.
Natürlich würde das Gateway auch als “offline” markiert werden, wenn der angegebene Server Probleme hat, daher sollten unbedingt zuverlässige Server verwendet werden.
DNS-Server festlegen / Gateway switching aktivieren
Um unter bestimmten Bedingungen bzw. Setups nicht in Probleme zu laufen, empfiehlt es sich nun, den Gateways jeweils einen eigenen, externen DNS Server zuzuweisen. Je nachdem welches Gateway aktiv ist, verwendet OPNsense diese Server für die Auflösung seiner eigenen Anfragen und je nach DNS-Setup des Systems werden diese Server unter Umständen auch anderweitig verwendet (z.B. via DHCP den Clients mitgeteilt).
Dazu gehen wir nach System / Settings / General und geben die gewünschten DNS-Server an. Hier im Beispiel entsprechen diese den Monitor-IPs des jeweiligen Gateways. Dadurch, dass wir bereits DNS-Server bei den Monitor-IPs verwenden, schränken wir uns etwas weniger ein und verursachen auch etwas weniger Einträge im Routing table.
Außerdem aktivieren wir die Funktion „Allow default gateway switching“, die es erlaubt, dass automatisch auf ein anderes Gateway gewechselt werden darf, wenn eins ausfällt. Die Einstellungen werden anschließend gespeichert.
Das Multi-WAN Setup für Failover ist nun fertig, auch wenn andere Anleitungen, wie auch die von OPNsense, nun noch weitere Maßnahmen beschreiben. Mehr dazu im nächsten Abschnitt, der für die Einrichtung einer Lastverteilung zwingend erforderlich ist.
[POLICY BASED ROUTING]
Für ein Failover Setup kann es unter Umständen erforderlich oder gewünscht sein mit einem regelbasierten Routing zu arbeiten. Dabei wird nicht alles blind und gradlinig über das aktive Gateway geleitet, sondern man kann mit Firewallregeln selbst bestimmten, welcher Traffic über welches Gateway geroutet werden soll. In meinem Fall soll z.B. ein Server ausschließlich über die Leitung arbeiten, die ansonsten nur im Fehlerfall verwendet wird.
Achtung:
Bei vorgeschalteten Routern oder Modems, welche aus dem LAN erreichbar sein sollen, muss zwingend das regelbasierte Routing verwendet werden und es wird eine weitere Regel erforderlich, die den Traffic für das Gerät über das richtige Gateway schickt!
Wie so oft wird es an dieser Stelle aber zu individuell, um Näheres zu beschreiben. Daher hier nur die grundlegenden Maßnahmen für das regelbasierte Routing, welches für eine Lastverteilung essentiell ist. Individuelle Details können gerne im Forum diskutiert werden.
Gatewaygruppe erstellen
Wir gehen zu System / Gateways / Group und erstellen mit dem Plus-Symbol eine neue Gruppe.
Dieser geben wir einen entsprechenden Namen und eine Beschreibung. Dann wählen wir für die aufgeführten Gateways, in welcher Reihenfolge sie verwendet werden sollen. „Tier 1“ ist dabei das Gateway, das primär verwendet wird, erst wenn dies keine Verbindung hat wird „Tier 2“ verwendet usw.. Das WAN Gateway wird also “Tier 1” und das LTE Gateway wird “Tier 2”.
Für eine Lastverteilung verwenden wir „Tier 1“ für beide Interfaces.
Wichtig: Die Einrichtung erfolgt in diesem Fall für IPv4, daher darf keinesfalls ein IPv6 Gateway gewählt werden, dies bleibt auf „never“ stehen.
Die Einstellungen werden gespeichert und auf der anschließenden Übersicht final übernommen.
Gatewaygruppe in Firewallregel verwenden
Die erstellte Gatewaygruppe hat zunächst keinerlei Funktion, wird also nicht verwendet. Damit sie verwendet wird, muss die “Default allow LAN to any rule” auf dem LAN, also die Regel, die sämtlichen Traffic im LAN erlaubt, so angepasst werden, dass die Gatewaygruppe statt das derzeit aktive Gateway verwendet wird. Dies und Nachfolgendes trifft nicht nur auf das LAN zu, sondern auf alle Interfaces, die die Gatewaygruppe verwenden sollen (z.B. Gäste WLAN, etc).
Wir gehen also nach Firewall / Rules / LAN und bearbeiten die entsprechende Regel mit dem Stift-Symbol.
Ziemlich weit unten wählen wir nun bei „Gateway“ die zuvor erstellte Gatewaygruppe und speichern die Einstellungen.
Übrigens: Die Standardeinstellung für das Gateway „default“ bewirkt, dass die default-Route aus dem Routing table verwendet wird, welche automatisch auf das aktive Gateway gesetzt wird.
Nun wird es wieder zu individuell um eventuell erforderliche, weitere Regeln zu beschreiben. In anderen Anleitungen wird nun z.B. die Erstellung einer Regel für DNS als essentiell dargestellt, obwohl dies nicht auf jedes Setup zutrifft.
Die Firewallregeln werden final gespeichert und das Setup für Failover ist endgültig fertig. Für eine Lastverteilung muss gleich noch eine Kleinigkeit eingestellt werden, dazu gehen wir nach Firewall / Settings / Advanced und setzen den Haken bei „Sticky connections“. Damit wird sichergestellt, dass eine bestehende Verbindung immer über das selbe Interface geroutet wird, da sich die Gegenstelle daran stören könnte, wenn sich dies dauernd ändert.
Die Einstellung wird natürlich noch gespeichert, damit ist dann auch die Lastverteilung grundlegend eingerichtet.
Erweiterte Einstellungen
Grundlegend sollten Failover oder Lastverteilung jetzt funktionieren, wir können aber noch an ein paar Parametern schrauben, wenn wir wollen. Dazu sehen wir uns die Gateways an und bearbeiten das gewünschte Gateway mit dem Stift-Symbol, dann klappen wir ganz unten die erweiterten Einstellungen auf.
Der Wert „Weight“ ist besonders bei einer Lastverteilung interessant. Hier wird quasi das Verhältnis eingestellt, wie stark ein Gateway gegenüber dem anderen belastet werden soll. Stellt man den Wert z.B. für das WAN auf 3 und für das LTE auf 1, dann wird dreimal so viel Traffic auf WAN verteilt, wie auf LTE.
Auf die Werte darunter will ich jetzt nicht im Detail eingehen, hier kann man unter anderem einstellen, wie genau das Monitoring erfolgt und unter welchen Bedingungen ein Gateway als offline gekennzeichnet werden soll. Bei meinem LTE Gateway habe ich entsprechend unsensiblere Einstellungen getroffen, die dafür sorgen, dass nicht durch jeden kleinen „Aussetzter“ wie eine zu hohe Antwortzeit das Gateway als offline markiert wird.
„Data Length“ bestimmt wie viele Bytes bei jedem Ping mitgesendet werden. Hier ist normalerweise keine Einstellung erforderlich, wenn es aber Probleme gibt (z.B. wird das Gateway oft zu unrecht als offline markiert) kann hier ein Wert von 1 oder 2 Abhilfe schaffen.
[FUNKTIONSTEST]
Keine Einrichtung ist ohne Funktionstest abgeschlossen, also prüfen wir natürlich einmal, ob auch alles so klappt wie gewünscht. Wichtig dabei: Insbesondere beim Failover / Ausfall einer Verbindung muss etwas tiefer geprüft werden, ob alles so funktioniert wie erwartet. Natürlich kann keine Telefonie funktionieren, wenn die Leitung mit dieser ausgefallen ist. Die erforderlichen, tieferen Tests sind wieder je nach Setup sehr individuell. Grundsätzlich sollte einmal der Ausfall jeder Leitung geprüft werden. Dazu die Verbindung am besten physisch trennen und / oder in einem eventuell vorgeschalteten Router blockieren. Je nach erweiterter Einstellung muss das Gateway dann nach kurzer Zeit als offline und das andere Gateway als aktiv markiert sein. Auf www.wieistmeineip.de kann man prüfen, ob man nun auch wirklich mit dem richtigen Provider im Internet unterwegs ist.
Die Lastverteilung lässt sich am besten prüfen, indem von mehreren Clients viele möglichst große Downloads gestartet werden, am Besten von IPv4 Quellen (wir erinnern uns: IPv6 wird hier nicht verteilt). Die Verteilung der Last lässt sich unter Reporting / Traffic prüfen. Dazu werden oben rechts nur die beiden interessanten Interfaces ausgewählt. Je nachdem wie das Verhältnis der Verteilung eingestellt ist, sollte sich dies hier optisch darstellen.
[EPILOG]
Und dann ist es schon erledigt, ziemlich simpel! Etwas spannender könnte das Thema „Dynamischer DNS“ sein, wenn man für jeden Anschluss eine eigene DDNS-Adresse haben möchte, denn die Prüfung, welche IP zu hinterlegen ist, erfolgt immer über das aktive Gateway und im Fall einer Lastverteilung sogar wahllos, was auch zu einer Sperre beim DDNS Provider führen kann. Hier kommt wieder das regelbasierte Routing ins Spiel, womit vorgegeben wird, über welches Gateway die Anfragen gehen sollen. Auch spannend wird der Fernzugriff über VPN, damit geht es dann im nächsten Artikel weiter.
---
Vielen Dank an den User tiermutter für diese Anleitung!