Standortvernetzung via (open)VPN mit Fallback auf LTE
-
Hallo zusammen
Folgendes Szenario:
4 Standorte - A B C D
Alle Standorte sollen auf das Netz an Standort A zugreifen können.
Also bauen entweder die Standorte B C D jeweils einen S2S Tunnel zu Standort A auf oder alternativ die PFSENSE an Standort A baut jeweils einen Tunnel zu Standort B C D.
Soweit so gut ...An Standort A gibt es 3 Telekom VDSL Anschlüsse die im Load Balancing Betrieb laufen (alle auf der gleichen Tier)
Wenn an Standort A aber mal das Telekom netz ausfallen würde dann brauche ich hier einen "PlanB" - ich dachte an einen einfachen LTE Router welcher an die PFSENSE von Standort A gehängt wird mit einer höheren Tier so dass dieser nur angesprochen wird wenn die anderen 3 VDSL´s ausfallen.
https://docs.netgate.com/pfsense/en/latest/multiwan/load-balance-and-failover.html
Soweit so gut - jetzt möchte ich aber dass die VPN Verbindungen dann auch über diesen LTE Anschluss laufen ...
Da das Szenario offen gesprochen hoffentlich nie eintritt will ich hier eigentlich keine spezial Sim besorgen mit einer festen öffentlichen IP...Technisch sollte der Failover klappen - nur das OpenVPN kommt ja über keine öffentliche IP mehr rein... - dann müsste quasi umgekehrt PFSENSE an Standort A 3 Verbindungen zu B C und D aufbauen ...
Gibts da irgendwas das schon erprobt ist bzw ein TODO für Failover bei VPN ?
CU
GTR -
@gtrdriver Moin,
Also bauen entweder die Standorte B C D jeweils einen S2S Tunnel zu Standort A auf oder alternativ die PFSENSE an Standort A baut jeweils einen Tunnel zu Standort B C D.
Das ist ja nur eine theoretische Frage/Betrachtungsweise. Rein technisch ist es egal und lediglich eine Punkt-zu-Punkt Verbindung :)
Da das Szenario offen gesprochen hoffentlich nie eintritt will ich hier eigentlich keine spezial Sim besorgen mit einer festen öffentlichen IP...
Dann wirst du Probleme mit der Erreichbarkeit von außen haben und wenn du via LTE ne Verbindung aufbauen willst, geht das nur als Client/Verbindungsinitiator ggü. der Gegenseite.
Gibts da irgendwas das schon erprobt ist bzw ein TODO für Failover bei VPN ?
Was soll es denn da genau geben? In welcher Richtung Verbindungen aufgebaut werden ist bei IPsec egal und bei OpenVPN nur für Unterscheidung Server/Client bei der Einrichtung relevant. Alles andere bleibt gleich. Man kann auch von A zu B,C,D einfach beide Verbindungen aufbauen lassen. Ist ja durch DynDNS und Co oft kein Problem mehr und bei Business Leitungen sollte auch IP4 kein Thema sein.
Am Ende des Tags braucht man für sinnvolles Failover zwei Gateways die man nutzen kann (pro Leitung). Und dann kann man darüber ne GW Gruppe oder OSPF legen und fein :)
Mit OpenVPN funktioniert das bei vielen Kunden bspw. bislang sehr solide. Beide Verbindungen dann als Interface zugewiesen und man bekommt entsprechend das GW das man für die FO-Gruppe bzw. für OSPF weiterverwenden kann.
Wie man das im Detail baut ist dann abhängig von den Gegebenheiten. Aber ansonsten mit multiplen OpenVPN Tunneln zu jedem Ziel und entsprechendem Routing darüber sollte es recht wenig Probleme geben.
Cheers
-
Hallo
danke für deine Einschätzung !
Ja - dass ich von außen her nicht auf das LTE Gateway komme da Vodafone das durch ein NAT jagt ist mir klar....
Die VPN Verbindungen könnten aber - wie du es ja schreibst - auch von A NACH B/C/D aufgebaut werden und das müsste über LTE funktionieren.
B/C/D haben ebenfalls FESTE IP´s...
OSPF habe ich mal angelesen aber noch nicht wirklich verstanden - soweit ich es verstanden habe geht es hier darum dass eine VPN Verbindung quasi über 2 Tunnel gleichzeitig aufgebaut wird und ein System dann prüft welches der "bessere" oder "Kürzere" weg ist ?!?
Es im "Desaster Fall" halt wichtig wäre ist dass ich von Außen irgendwie auf die PFSENSE an Standort A komme - auf das WEB interface....
Mangels fester IP geht das auf klassischem Weg nicht.
Ich überlege schon dauernd ob man ggfs eine "ausgehende" VPN / SSH Verbindung auf einen Root Server macht (der im netz steht) und dann quasi über den Root Server dann auf die PFSENSE kommt -
@gtrdriver said in Standortvernetzung via (open)VPN mit Fallback auf LTE:
OSPF habe ich mal angelesen aber noch nicht wirklich verstanden - soweit ich es verstanden habe geht es hier darum dass eine VPN Verbindung quasi über 2 Tunnel gleichzeitig aufgebaut wird und ein System dann prüft welches der "bessere" oder "Kürzere" weg ist ?!?
OSPF steht für "Open Shortest Path First" der einen Algo (Dijkstra) benutzt um in großen Topologien zu berechnen, welchen Weg ein Paket nehmen sollte, damit es den kürzesten/schnellsten Weg zum Ziel findet. Das kann man durch Gewichtungen etc. verändern, da es ja um den "Shortest Path" geht. Da der kürzeste nicht immer der schnellste ist kann man eben die Gewichtung verändern, damit man sich den praktischen Gegebenheiten anpasst.
Wenn man OSPF (via FRR) für VPN Tunnel nutzen würde, dann würde man bspw. an beiden Enden eines Tunnels auf den Sensen FRR mit OSPF installieren und die beiden OVPN Tunnel (Gateways) als "Strecken" hinzufügen. Die LTE Strecke macht man dann 10 oder 100x "schlechter" bzw. schwerer und schon wird der Algo zum Schluß kommen: "Oh, es geht von A nach B 2 Strecken, eine hat Wert 10, eine Wert 100, nimm den 10er bis er Weg ist und dann mach den 100er"
Da OSPF dann automagisch lernen kann, welche Netze wo anliegen und verfügbar sind, muss man selbst auch gar nicht mit händischen Routen rumkaspern, das erledigt OSPF für einen (wenn korrekt konfiguriert). Bei A muss man dann die jeweils 2 Strecken zu B, C & D adden und gewichten, auf den Außenseiten nur die beiden zu A, was recht einfach sein dürfte.
Wenn die Netze überall sauber getrennt aufgezogen sind wovon ich ausgehe, dann publishen die OSPF Instanzen selbstständig die Routen via dem entsprechenden Tunnel und sobald der wegbrechen sollte wechselt die Route selbständig auf die anderen Line UND zurück(!) Andere Failover Mechanismen sind da ja weniger gut im "zurückfallen", denn Failover-GW + Policy Based Routen sind ja durch States immer etwas "sticky" so dass man durchaus den Wechsel "mitbekommt" und beim Fallback es sein kann dass auf dem LTE Tunnel Dinge erstmal noch etwas kleben bleiben. Bei OSPF ist das nicht der Fall, da wir hier dann direkt System Routen haben die strikt befolgt werden. Somit bleibt kein Paket/Verbindung länger auf LTE als sie sein müsste.
Es im "Desaster Fall" halt wichtig wäre ist dass ich von Außen irgendwie auf die PFSENSE an Standort A komme - auf das WEB interface....
Ich überlege schon dauernd ob man ggfs eine "ausgehende" VPN / SSH Verbindung auf einen Root Server macht (der im netz steht) und dann quasi über den Root Server dann auf die PFSENSE kommtWenn die ~ 5€ im Monat verschmerzbar sind - go for it. Die Cloud Instanz sollte aber sauber abgesichert sein und sehr straightforward. Aber dann problemlos denkbar. Kann man Cloud als "E" mit reinnehmen, noch Einwahl VPN mit dranflanschen, das per OSPF propagieren etc.
Ich würde ja sagen, plant das einmal richtig und setzt das dann mit einem Dienstleister um
Aber ich darf ja keine Eigenwerbung machen - es gibt hier auch andere "Professionelle"
Trotzdem: gerade wenn man im Fehlerfall WAN1 down auf A dann sonst nicht mehr reinkommt und das gehen muss, sollte man hier einmal wirklich in die Architektur gehen, das sauber planen und durchstrukturieren und dann ggf. mit einem Partner umsetzen oder zumindest im Nachgang nochmal auditieren/drüberschauen lassen, damit man nicht was vergessen hat oder sich irgendwo ne Backdoor baut, die da nicht sein sollte :)Cheers
-
Hallo
Danke erstmal für die Ausführungen und Ideen....
Ich muss mir mal überlegen wie "tiefgreifend" ich das umsetzten will oder ob man die LTE Verbindung erstmal als "Desaster Plan" integriert so dass man zur Not von Außen drauf kommt (hab ich grad mal mit nem SSH Reverse Tunnel und fixen Schlüsselpaaren probiert - klappt).Dann könnte man ggfs die VPN´s per Hand auf das LTE Interface umschalten ...
Das OSPE möchte ich erstmal in einer Virtualisierten TEST Umgebung ausprobieren ...