"Hochverfügbarkeit" mit zwei Lancom-Routern

[DirkK]

Hallo,

da mein Haupt-DSL-Provider sein Netzwerk nicht wirklich im Griff hat und es in den letzten Wochen und Monaten zu mehrfachen längeren DSL-Ausfällen geführt und die Performance mit 60MBit auch nicht wirklich berauschend ist, habe ich mir eine Telekom DSL Speedbox mit LTE-Flat geholt, die zum einen bei DSL-Ausfall einspringen soll, als auch im Loadbalancing für mehr Durchsatz sorgen soll. Das funktioniert mittlerweile auch recht passabel.

Ich möchte nun den Fall eines Komplettausfalles des Hauptrouters (1784VA) abdecken. Hierzu habe ich einen alten 1302acn reaktiviert und diesen per WLAN an die Speedbox angebunden, bzw. alternativ, falls auch das Telekom Mobilfunknetz gestört ist, an ein vordefiniertes Handy, welches dann den Internetanschluss per WLAN-Hotsprot dem 1302 zur Verfügung stellen soll. Der Ausfall soll per VRRP möglichst automatisiert abgedeckt werden. Zur Verdeutlichung das Schaubild.

Meine Fragen beziehen sich jetzt auf die Konfiguration der LAN-Seiten von 1784 und 1302 und hierbei besonders auf das DHCP und zusammenhängend das DNS.

Wie muss ich die beiden dann als DHCP-Server konfigurieren? Der 1784 soll der "Master" sein. Dort (so meine Vorstellung) mus DHCP-Server aktiviert: "Ja" angegeben werden. Muss auch DHCP-Cluster angehakt sein? Beim 1302 müsste demnach DHCP-Server aktiviert: "Automatisch" angegeben und DHCP-Cluster auf jeden Fall angehakt werden. Richtig?
Ich verwende ausschließlich vorreservierte DHCP-verteilte IP-Adressen, welche ich in der DHCP-Stationsliste des 1784 eintrage.
Muss ich diese DCHP-Stationsliste ebenso im 1302 eintragen, damit dieser im Fehlerfall sauber die IP-Adressen wie gewohnt verteilt?
Alle anderen DHCP-Einstellungen des 1302 würde ich dann vom 1784 übernehmen (IP-Adressrange Gateway, DNS- und NBNS-Server), wobei Gateway und DNS-Server auf die virtuelle IP des VRRP-Routers zeigen würden. Richtig?
Ebenso würde ich die DNS-Server und -Weiterleitungen des 1784 in den 1302 übernehmen und zuletzt ein Minimalset bzgl. der Firewallregeln syncronisieren, um den Pflegeaufwand bei Firewalländerungen nicht zu sehr in die Höhe zu treiben. Oder gibt es eine geschickte Möglichkeiten Firewallregeln über beide Geräte zu syncronisieren?

Was habe ich bei meinen Überlegungen noch vergessen? Es geht hier nicht um eine komplette Hochverfügbarkeitslösung, sondern um einen im Fehlerfall möglichst automatischen Weiterbetrieb bzgl. Internet aus dem LAN. Eingehende VPN-Verbindungen z.B. sind im Fehlerfall zweitrangig.

Danke und Grüße
Dirk

[backslash]

Hi DirkK,

der DHCP-Cluster arbeitet passiv, d.h. er lauscht nur mit, was im Netz passiert und hält alles nach. Welcher DHCP-Server verwendet wird, legt einzig der Client fest - er wählt sich einen Server aus dem Cluster aus...

Daher muß auf allen beteilitgten Geräten den DHCP-Server exakt gleich konfiguriert sein, d.h. überall muß der DHCP-Server auf "ein" stehen - "auto" sorgt dafür, daß der Server abgeschaltet wird, sobald ein anderer Server im Netz erkannt wird - was den Clusterbetrieb aushebelt... Auch die statische Adreßzuweisung muß auf allen Geräten konfiguriert sein, denn sonst würden alle Server unterschiedliche Adressen ausliefern

Gruß
Backslash

[DirkK]

Hi backslash

Daher muß auf allen beteilitgten Geräten den DHCP-Server exakt gleich konfiguriert sein, d.h. überall muß der DHCP-Server auf "ein" stehen - "auto" sorgt dafür, daß der Server abgeschaltet wird, sobald ein anderer Server im Netz erkannt wird - was den Clusterbetrieb aushebelt...

Uiiii, gut, dass ich nachgefragt habe. In dieser Klarheit war mir das nicht bewusst!

Viele Grüße
Dirk

[DirkK]

So, mit Script Ex- und Import die DHCP- und DNS-Einstellungen vom 1784 in den 1302 geschoben, hierbei den 1302 abgeschossen, da es Parameter im 1784 gibt, an denen sich der 1302 verschluckt , aber nach Reset und Restore, sowie anpassen des Import-Skripts alles soweit drüben und .... funktioniert ... dachte ich ... naja, viel, aber nicht alles ....

Neues Problem scheint der DNS-Server auf der virtuellen VRRP-IP zu sein. Aber eben nicht für alle Clients nur für ein einziges, die "Nuki-Bridge", eine WLAN-Bluetooth-Bridge für ein smartes Türschloss.

Ich habe jetzt nochmals intensiv das Kapitel 17.2 Backup-Lösungen und Load-Balancing mit VRRP im Referenzhandbuch durchgelesen.
Dort steht, dass DNS-Anfragen auf virtuelle (VRRP) IP's nicht RFC-konform sind und eigentlich verworfen werden. Um trotzdem, die VRRP-IP verwenden zu können muss man den VRRP-Schalter "interne Dienste" aktivieren. Das habe ich auch gemacht und im DHCP-Server ist dann als DNS-Server die VRRP-IP eingetragen.

Mit dieser Einstellung bekommen alle Clients auch eine DNS-Auflösung hin, nur eben die Nuki-Bridge nicht.
Wenn ich die reale IP des 1784 eintrage, dann findet auch die Nuki-Bridge wieder den Weg ins Internet.

Die Frage ist nun, woran kann das noch liegen und wie kann ich das lösen?
Bringt es was als ersten DNS-Server den Haupt-Router 1784 einzutragen und als zweiten DNS-Server den Backup-Router? Wie ist das denn dann im Fehlerfall, da der DNS-Server ja idR Round-Robin abgefragt wird gibt's dann doch vermutlich "Hänger"?

Viele Grüße
Dirk

[backslash]

Hi DirkK,

Bringt es was als ersten DNS-Server den Haupt-Router 1784 einzutragen und als zweiten DNS-Server den Backup-Router?

du kannst es gerne ausprobieren - dennoch frage ich mich, woran die Nuki-Bridge erkennen soll, daß sie die Anfrage an die VRRP-Adresse stellt und wieso sie die Antwort nicht akzeptiert...

Aber wenn nur die Nuki-Bridge betroffen ist, dann solltest du ggf. für diese ein neues Netz aufspannen (oder gleich eins für alle IOT-Geräte, denn die sind oft von jahrelang ungepatchten Sicherheitslücken betroffen) und nur in diesem Netz die beiden physikalischen Adressen zuweisen, statt der VRRP-Adressen.
Ich frage mich aber schon, wieso die Nuki-Bridge überhaupt DNS-Anfragen machen sollte - oder muß sie immer "nach hause telefonieren"?

Gruß
Backslash

[DirkK]

Hi backslash

dennoch frage ich mich, woran die Nuki-Bridge erkennen soll, daß sie die Anfrage an die VRRP-Adresse stellt und wieso sie die Antwort nicht akzeptiert...

Exakt!!! Mir eben auch unverständlich. Kann nur sagen, dass es reproduzierbar ist: DNS mit physikalischer IP -> Verbindung ins Internet, mit VRRP-IP -> keine Verbindung.

Aber wenn nur die Nuki-Bridge betroffen ist, dann solltest du ggf. [...] gleich eins für alle IOT-Geräte, [...]

Bin das auch schon mal angegangen, allerdings gab es da irgendeinen Showstopper (weiß jetzt nicht mehr genau was), wo ich dann eben nicht alle IoT-Geräte in ein Netz packen konnte, sondern es wäre ein Mischbetrieb geworden. Und dafür war mir dann der Aufwand zu hoch.

Ich frage mich aber schon, wieso die Nuki-Bridge überhaupt DNS-Anfragen machen sollte - oder muß sie immer "nach hause telefonieren"?

Die braucht die Cloud-Verbindung zum Hersteller um von Remote Zugriff auf den Status, sowie Berechtigungen und Funktionen zu haben. Mit HomeKit-Zugang funktioniert nur das allernötigste.

Viele Grüße
Dirk