Verkehrsrouting mit unzuverlässigen Verbindungen

Ich habe eine Gruppe von Büros, die alle über DSL-Verbindungen am anderen Ende mit dem Hauptbüro verbunden sind, um Kosten zu sparen. (Wir sind ein gemeinnütziger Verein, fragen Sie nicht)

In der Vergangenheit gab es bemerkenswerte Probleme mit der Verbindung zwischen dem ISP, der unsere Remote-Standorte verwaltet, und dem ISP, der die T1-Leitungen verwaltet, auf denen unser OpenVPN ausgeführt wird. Daher werden diese Verbindungen häufig unterbrochen.

Die öffentliche Schnittstelle unseres Mailservers befindet sich im Netzwerk des ersten Anbieters, hat also einwandfrei funktioniert, ist aber viel langsamer, da es auch DSL ist.

Um die Probleme mit der Unzuverlässigkeit des Upstream-Netzwerks zu beheben, habe ich ein Skript geschrieben, das einfach die DNS-Einträge an den Remotestandorten so ändert, dass sie auf die interne IP verweisen, wenn der Tunnel aktiv ist, oder auf die öffentliche IP, wenn der VPN-Tunnel zum Hauptstandort nicht verfügbar ist.

Wie kann ich dies auf elegantere Weise tun, die sofort (anstelle meiner Cron-gesteuerten Skripte) und für die Benutzer transparent ist?

Bearbeiten: Remote-Büros: Ubuntu 9.10 LTSP-Server, auf denen verschiedene vom Hersteller bereitgestellte Actiontecs & Motorola und einige mit Netgears- und Linksys-Firewall ausgeführt werden. Hauptgeschäftsstelle: Fast 100% Linux (in diesem Fall CentOS) mit mehreren Firewalls der Netgear FVS318 / 338-Serie mit individuellen Firewalls für jede IP auf unserer / 27. (Ein anderer fragt nicht, es war bevor ich hier ankam)

OpenVPN sollte in der Lage sein, Befehle beim Erstellen und Beenden von Tunneln auszuführen. Anstatt diesen Job in einem Cron auszuführen, können Sie den DNS-Eintrag durch diese Ereignisse mischen lassen. Dann müssen Sie nur noch etwas über die unzuverlässige Verbindung überwachen, um zu wissen, wann der VPN-Tunnel neu gestartet werden muss.

Das hängt von Ihrem Budget ab. IP SLA von Cisco (und definitiv anderen) macht genau das. Hier ist ein ausgezeichneter Ausgangspunkt

Möglicherweise können Sie das ohne irgendetwas anderes durchziehen. Ich gehe davon aus, dass der DNS Ihrer Benutzer auf den Router Ihres Remote-Standorts verweist. Im Router Ihres Remote-Standorts können Sie das primäre DNS Ihres ersten Anbieters und das sekundäre DNS Ihres zweiten Anbieters hinzufügen. Die meisten Router sind heutzutage clever genug, um nach dem Ausfall des primären Routers auf die sekundäre zu scheitern.

BEARBEITEN: Um fair zu sein, können Sie je nach DSL einen gebrauchten Cisco-Router ab 60 US-Dollar finden. Da IP SLAs seit 12.3 (14) T unterstützt werden