12
VPN Fallback bzw. Failover zu 2 Endpunkten
Wir benötigen die Anbindundung von externen Rechnern an unser zentrales Rechnersystem mittels VPN via Festnetz-DSL und VPN via Satellit.
Guten Tag,
da ich neu in diesem Forum bin, bitte ich mögliche Formfehler oder ähnliches zu entschuldigen und hoffe, dass Ihr mir bei diesem schon seit fast einem Jahr bestehenden Problem helfen könnt.
Eine kurze Zusammenfassung zu Beginn:
Gibt es eine Möglichkeit bei Lancom-Routern oder anderen Router-Herstellern folgendes Szenario zu realisieren:
Router x möchte einen VPN-Tunnel zu Router y über IP1 aufbauen, ist dieser so nicht erreichbar, versuche es über IP2.
Wie gesagt, externe Rechner benötigen einen Zugriff zu unserem Rechnersystem. Der Vergleich hinkt zwar etwas, aber am besten lässt es sich so vorstellen, dass verschiedene Rechner in Filialen zur Zentrale Kontakt aufnehmen.
Das Rechnersystem in der Zentrale hat 2 Internetanbindungen: DSL und Satellit. Die beiden Anschlüsse soll ein Router verwalten (voraussichtlich LANCOM 7100 VPN) und bildet quasi den Endpunkt der VPN-Tunnel. Er ist also über 2 IP-Adressen erreichbar.
Das Problem liegt allerdings auf Kundenseite.
Liegen dort ebenfalls 2 DSL-Anschlüsse vor, so kann den Routern (Lancom 1721) eine Backup-Verbindung eingetragen werden.
Viele Filialen haben aber nur 1 DSL-Anschluß, trotzdem soll die Redundanz auf Seiten der Zentrale genutzt werden.
D.h. Ist der Zentral-Router über IP1(Festnetz-DSL) nicht erreichbar, soll es über IP2(Sat-DSL) versucht werden.
Wie es scheint benötigt der Lancom 1721 für eine Backup-Verbindung immer auch einen zweiten Anschluß-Port, dies ist ziemlich ungeschickt, da das interne Modem verwendet werden soll um filialseitig eine Mehrgeräte-Lösung zu vermeiden.
Wir sitzen wirklich schon lange an diesem Problem, hatten zunächst mit Signallaufzeiten der Satellitenverbindung zu kämpfen und dachten eigentlich, dass diese Fallback-Funktion mehr oder weniger Standard ist, aber irgendwie sind wir noch zu keiner Lösung gekommen. (Es müssen keine Lancom-Geräte sein)
Es wäre nett, wenn Ihr mir weiterhelfen könntet.
Peter
da ich neu in diesem Forum bin, bitte ich mögliche Formfehler oder ähnliches zu entschuldigen und hoffe, dass Ihr mir bei diesem schon seit fast einem Jahr bestehenden Problem helfen könnt.
Eine kurze Zusammenfassung zu Beginn:
Gibt es eine Möglichkeit bei Lancom-Routern oder anderen Router-Herstellern folgendes Szenario zu realisieren:
Router x möchte einen VPN-Tunnel zu Router y über IP1 aufbauen, ist dieser so nicht erreichbar, versuche es über IP2.
Wie gesagt, externe Rechner benötigen einen Zugriff zu unserem Rechnersystem. Der Vergleich hinkt zwar etwas, aber am besten lässt es sich so vorstellen, dass verschiedene Rechner in Filialen zur Zentrale Kontakt aufnehmen.
Das Rechnersystem in der Zentrale hat 2 Internetanbindungen: DSL und Satellit. Die beiden Anschlüsse soll ein Router verwalten (voraussichtlich LANCOM 7100 VPN) und bildet quasi den Endpunkt der VPN-Tunnel. Er ist also über 2 IP-Adressen erreichbar.
Das Problem liegt allerdings auf Kundenseite.
Liegen dort ebenfalls 2 DSL-Anschlüsse vor, so kann den Routern (Lancom 1721) eine Backup-Verbindung eingetragen werden.
Viele Filialen haben aber nur 1 DSL-Anschluß, trotzdem soll die Redundanz auf Seiten der Zentrale genutzt werden.
D.h. Ist der Zentral-Router über IP1(Festnetz-DSL) nicht erreichbar, soll es über IP2(Sat-DSL) versucht werden.
Wie es scheint benötigt der Lancom 1721 für eine Backup-Verbindung immer auch einen zweiten Anschluß-Port, dies ist ziemlich ungeschickt, da das interne Modem verwendet werden soll um filialseitig eine Mehrgeräte-Lösung zu vermeiden.
Wir sitzen wirklich schon lange an diesem Problem, hatten zunächst mit Signallaufzeiten der Satellitenverbindung zu kämpfen und dachten eigentlich, dass diese Fallback-Funktion mehr oder weniger Standard ist, aber irgendwie sind wir noch zu keiner Lösung gekommen. (Es müssen keine Lancom-Geräte sein)
Es wäre nett, wenn Ihr mir weiterhelfen könntet.
Peter
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 129305
Url: https://administrator.de/contentid/129305
Printed on: April 26, 2024 at 12:04 o'clock
12 Comments
Latest comment
So direkt mit Bordmitteln ist das nicht möglich. Der Grund ist eigentlich auch logisch: Der VPN Client Prozess bekommt entweder einen Hostnamen oder eine dedizierte IP Adresse mit für den Tunnelendpunkt. Folglich wird auch immer nur diese IP Adresse angesprochen.
Leider beschreibst du dein VPN Protokoll nur sehr oberflächlich und wir müssen hier nun leider raten welches Protokoll (IPsec, PPTP, L2TP, SSL etc.) du für dein VPN verwendest
Als Beispiel z.B. bei IPsec ist der Hostname oder die Tunnel IP Teil des Authentifizierungsprozesses. Aus diesem Grund schliesst sich eine Alternativ Anfrage an einen anderen Tunnelendpunkt schon per se aus.
Natürlich gibt es aber eine oder besser zwei einfache Lösungen für das Problem:
1.) Du machst ein DNS Load Balancing wenn du mit Hostnamen arbeitest. Hat deine Tunnelendpunkt also den z.B. Hostnamen vpn.meine-firma.de dann kannst du dem DNS Server sagen wechselseitig unterschiedliche IPs dafür rauszugeben. Mehr oder weniger ist das aber ein Load Balancing und kein Failover denn m.E. hat der DNS Server keine Möglichkeit die Erreichbarkeit des Tunnelendpunktes zu prüfen
2.) Ist die Verwendung eines Load Balancers vor dem VPN Router. Dieser hat eine virtuelle IP die den Tunnelendpunkt darstellt aber der Load Balancer verteilt dann die eingehenden VPN Sessions auf die realen VPN Server, sprich also deine beiden IP Adressen. Im Gegensatz zu der o.a. Lösung macht so ein LB aber eine Verfügbarkeitsprüfung.
D.h. fällt eine Tunnel IP aus oder ist nicht erreichbar, dann schickt er eingehende Sessions nur auf den verfügbaren Tunnelendpunkt.
Letztlich ist die Lösung 2 die technisch bessere und wird in der IT in der Regel zum Lösen dieser Anforderung sehr häufig verwendet.
Leider beschreibst du dein VPN Protokoll nur sehr oberflächlich und wir müssen hier nun leider raten welches Protokoll (IPsec, PPTP, L2TP, SSL etc.) du für dein VPN verwendest
Als Beispiel z.B. bei IPsec ist der Hostname oder die Tunnel IP Teil des Authentifizierungsprozesses. Aus diesem Grund schliesst sich eine Alternativ Anfrage an einen anderen Tunnelendpunkt schon per se aus.
Natürlich gibt es aber eine oder besser zwei einfache Lösungen für das Problem:
1.) Du machst ein DNS Load Balancing wenn du mit Hostnamen arbeitest. Hat deine Tunnelendpunkt also den z.B. Hostnamen vpn.meine-firma.de dann kannst du dem DNS Server sagen wechselseitig unterschiedliche IPs dafür rauszugeben. Mehr oder weniger ist das aber ein Load Balancing und kein Failover denn m.E. hat der DNS Server keine Möglichkeit die Erreichbarkeit des Tunnelendpunktes zu prüfen
2.) Ist die Verwendung eines Load Balancers vor dem VPN Router. Dieser hat eine virtuelle IP die den Tunnelendpunkt darstellt aber der Load Balancer verteilt dann die eingehenden VPN Sessions auf die realen VPN Server, sprich also deine beiden IP Adressen. Im Gegensatz zu der o.a. Lösung macht so ein LB aber eine Verfügbarkeitsprüfung.
D.h. fällt eine Tunnel IP aus oder ist nicht erreichbar, dann schickt er eingehende Sessions nur auf den verfügbaren Tunnelendpunkt.
Letztlich ist die Lösung 2 die technisch bessere und wird in der IT in der Regel zum Lösen dieser Anforderung sehr häufig verwendet.
Hallo aqui,
vielen Dank für Deine Antwort.
Wusste nicht, dass das Protokoll der Verschlüsselung ausschlaggebend ist. Es hätte eigentlich IPSec verwendet werden sollen. Wir sind da noch flexibel, wenn es etwas besseres gibt.
Zu Deinen beiden Lösungen:
Zu 1) Ich habe gerade in der Konfiguration des Lancoms 1721 nachgesehen, der lässt bei der Auflösung der Namen nur einen Eintrag zu.
Problematisch ist generell die Sache mit dem Namen, da die Applikation, die in den Außenstellen läuft IP-Adressen verwendet.
Müsste man mal sehen, ob die Software insoweit geändert werden kann.
Zu 2) Darüber haben wir natürlich auch schon nachgedacht. Richtig, wäre natürlich die beste Variante.
Nur kommen wir da von der Finanzierung nicht hin. Ein Load-Balancer kostet meines Wissens 2000,- Eur aufwärts, der Lancom um die 400,-.
Bei 50 Außenstellen ist der Unterschied schon erheblich.
Nochmal zu 1, d.h. wir benötigen einen Router (auf dem der DNS-Server läuft), bei dem man verschiedene IPs für einen Hostnamen eintragen kann.
Gibt es Geräte, bei denen hier eine Haupt- und eine Alternativ-Verbindung eingetragen werden kann, sodass es immer auf eine IP zurückfällt?
Danke,
Peter
vielen Dank für Deine Antwort.
Wusste nicht, dass das Protokoll der Verschlüsselung ausschlaggebend ist. Es hätte eigentlich IPSec verwendet werden sollen. Wir sind da noch flexibel, wenn es etwas besseres gibt.
Zu Deinen beiden Lösungen:
Zu 1) Ich habe gerade in der Konfiguration des Lancoms 1721 nachgesehen, der lässt bei der Auflösung der Namen nur einen Eintrag zu.
Problematisch ist generell die Sache mit dem Namen, da die Applikation, die in den Außenstellen läuft IP-Adressen verwendet.
Müsste man mal sehen, ob die Software insoweit geändert werden kann.
Zu 2) Darüber haben wir natürlich auch schon nachgedacht. Richtig, wäre natürlich die beste Variante.
Nur kommen wir da von der Finanzierung nicht hin. Ein Load-Balancer kostet meines Wissens 2000,- Eur aufwärts, der Lancom um die 400,-.
Bei 50 Außenstellen ist der Unterschied schon erheblich.
Nochmal zu 1, d.h. wir benötigen einen Router (auf dem der DNS-Server läuft), bei dem man verschiedene IPs für einen Hostnamen eintragen kann.
Gibt es Geräte, bei denen hier eine Haupt- und eine Alternativ-Verbindung eingetragen werden kann, sodass es immer auf eine IP zurückfällt?
Danke,
Peter
Nur nochmal zur Klarstellung:
Die Lösung 1.) ist eine reine DNS Server Lösung. Es hat nichts mit Routern usw. zu tun sondern ist eine Funktion auf dem DNS Server selber !
Der muss in der Lage sein ein DNS Round Robin Reply zu machen, was moderne DNS Daemons aber ohne Probleme können heutzutage.
Der VPN Client Prozess muss den Hostnamen ja erst in eine IP auflösen bevor er den Tunnel establishen kann. D.h. er macht erst einen normalen DNS Request an den DNS Server dafür. Daher wird auch klar das diese Lösung NUR mit Hostnamen als Tunnelendpunkt funktionieren kann und nicht mit den realen IPs. Klar denn da ist dann gar kein DNS mehr involviert !
Und am DNS Server kommt dann der o.a. DNS Mechanismus ins Spiel.
Die Problematik für dich fängt dann an, wenn du auf dem Lancom schon nur einen DNS konfigurieren kannst was leider bei billigeren Lösungen of der Fall ist. Der DNS Server sollte dann natürlich unter seiner IP redundant sein (klar du kannst ja keinen 2ten defineren). Ansonsten hast du bei einem evtl. Ausfall gar nichts gewonnen, denn du verschiebst das Redundanz Problem nur !
Zweitens kann er keine Erreichbarkeits- oder verfügbarkeitsprüfung machen, was natürlich gegenüber der LB Lösung ein weiterer Nachteil ist.
Wie bereits gesagt. Technisch gesehen ist die LB Lösung die beste.
Nochwas zur Applikation:
Es ist völlig unerheblich was deine Applikation in den Außenstellen macht. Ob die IP nutzt oder nicht oder ob er Brötchen backen kann oder was auch immer.
Der VPN Tunnelaufbau hat mit der Applikationsnutzung im VPN Tunnel nicht das Geringste zu tun !!
Was du an Applikation über den Tunnel überträgst und wie, spielt keinerlei Rolle für den Tunnelaufbau selber !! Das sind 2 völlig unterschiedliche Baustellen !
Nicht das du hier was in den falschen Hals bekommen hast in puncto VPN ??!!
Ggf. solltest du mal über ein ganz anderes Konstrukt nachdenken. Z.B. das du generell immer beide VPN Tunnel aufbaust und ein dynamisches Routing Protokoll wie z.B. OSPF über diese Links fährst. Dadurch ersparst du dir diese Redundanz Frickelei und lässt OSPF sich um die Wegewahl automatisch kümmern. Am allerbesten wäre es dann noch die beiden Tunnel auf 2 unterschiedliche VPN Router zu terminieren. Damit hast du noch eine erheblich höhere Ausfallredundanz.
Das ist mit den Mitteln die du hast erheblich einfacher und preiswerter zu realisieren !
Die Lösung 1.) ist eine reine DNS Server Lösung. Es hat nichts mit Routern usw. zu tun sondern ist eine Funktion auf dem DNS Server selber !
Der muss in der Lage sein ein DNS Round Robin Reply zu machen, was moderne DNS Daemons aber ohne Probleme können heutzutage.
Der VPN Client Prozess muss den Hostnamen ja erst in eine IP auflösen bevor er den Tunnel establishen kann. D.h. er macht erst einen normalen DNS Request an den DNS Server dafür. Daher wird auch klar das diese Lösung NUR mit Hostnamen als Tunnelendpunkt funktionieren kann und nicht mit den realen IPs. Klar denn da ist dann gar kein DNS mehr involviert !
Und am DNS Server kommt dann der o.a. DNS Mechanismus ins Spiel.
Die Problematik für dich fängt dann an, wenn du auf dem Lancom schon nur einen DNS konfigurieren kannst was leider bei billigeren Lösungen of der Fall ist. Der DNS Server sollte dann natürlich unter seiner IP redundant sein (klar du kannst ja keinen 2ten defineren). Ansonsten hast du bei einem evtl. Ausfall gar nichts gewonnen, denn du verschiebst das Redundanz Problem nur !
Zweitens kann er keine Erreichbarkeits- oder verfügbarkeitsprüfung machen, was natürlich gegenüber der LB Lösung ein weiterer Nachteil ist.
Wie bereits gesagt. Technisch gesehen ist die LB Lösung die beste.
Nochwas zur Applikation:
Es ist völlig unerheblich was deine Applikation in den Außenstellen macht. Ob die IP nutzt oder nicht oder ob er Brötchen backen kann oder was auch immer.
Der VPN Tunnelaufbau hat mit der Applikationsnutzung im VPN Tunnel nicht das Geringste zu tun !!
Was du an Applikation über den Tunnel überträgst und wie, spielt keinerlei Rolle für den Tunnelaufbau selber !! Das sind 2 völlig unterschiedliche Baustellen !
Nicht das du hier was in den falschen Hals bekommen hast in puncto VPN ??!!
Ggf. solltest du mal über ein ganz anderes Konstrukt nachdenken. Z.B. das du generell immer beide VPN Tunnel aufbaust und ein dynamisches Routing Protokoll wie z.B. OSPF über diese Links fährst. Dadurch ersparst du dir diese Redundanz Frickelei und lässt OSPF sich um die Wegewahl automatisch kümmern. Am allerbesten wäre es dann noch die beiden Tunnel auf 2 unterschiedliche VPN Router zu terminieren. Damit hast du noch eine erheblich höhere Ausfallredundanz.
Das ist mit den Mitteln die du hast erheblich einfacher und preiswerter zu realisieren !
Hallo aqui,
gut, dann kommt der Lancom zumindest für die DNS-Server Lösung mal nicht infrage.
Man kann zwar eine RoundRobin-Liste anlegen, allerdings nur für ISDN-Backupverbindungen.
Mit dem VPN-Tunnel und der Applikation hatte ich wohl tatsächlich was durcheinander gebracht.
Das mit 2 stehenden VPN-Kanälen ist auf jeden Fall eine Alternative.
Der Lancom (Baujahr 09) unterstützt allerdings nur RIP-2, oder ist dies lediglich eine andere Bezeichnung für OSPF?
Nächste Woche werden wir, bevor wir in diese Richtung weitere Überlegungen anstellen, noch folgender, gerade eingegangener Aussage von Lancom nachgehen:
Im Router können "weitere entfernte Gateways" eingetragen werden. Laut Lancom hat dies nichts mit RIP zu tun, der Lancom baut beide Kanäle auf, und benützt denjenigen, der in der Liste als erster steht und auch funktioniert.
Bei Interesse kann ich gerne von Erfolg oder.... naja, bei Misserfolg werde ich mich sowieso wieder melden
Peter
gut, dann kommt der Lancom zumindest für die DNS-Server Lösung mal nicht infrage.
Man kann zwar eine RoundRobin-Liste anlegen, allerdings nur für ISDN-Backupverbindungen.
Mit dem VPN-Tunnel und der Applikation hatte ich wohl tatsächlich was durcheinander gebracht.
Das mit 2 stehenden VPN-Kanälen ist auf jeden Fall eine Alternative.
Der Lancom (Baujahr 09) unterstützt allerdings nur RIP-2, oder ist dies lediglich eine andere Bezeichnung für OSPF?
Nächste Woche werden wir, bevor wir in diese Richtung weitere Überlegungen anstellen, noch folgender, gerade eingegangener Aussage von Lancom nachgehen:
Im Router können "weitere entfernte Gateways" eingetragen werden. Laut Lancom hat dies nichts mit RIP zu tun, der Lancom baut beide Kanäle auf, und benützt denjenigen, der in der Liste als erster steht und auch funktioniert.
Bei Interesse kann ich gerne von Erfolg oder.... naja, bei Misserfolg werde ich mich sowieso wieder melden
Peter
Mmmmhhh, komische (und auch unverständliche) Aussage von Lancom !! Was hat das mit einem redundanten VPN Tunnelendpunkt zu tun ??
Da hat wohl der Support vermutlich nicht wirklich verstanden was du eigentlich willst oder war etwas überfordert.
Vermutlich meinen sie mit ihrer Aussage die Konfiguration 2er default Gateway IPs. Das ist aber für dein Szenario vollkommen irrelevant, denn es geht dir ja nicht um ein redundantes next Hop Gateway (für den die Lancom Aussage zweifelsohne stimmt) sondern um einen redundanten Tunnel Endpunkt, also etwas völlig anderes. Dafür ist die Aussage dann wieder vollkommen sinnfrei....nunja.
Was dein Wissen um Routing Protokolle angeht hast du ziemliche Defizite was deine Frage von oben klar belegt.
Für einen Netzwerker wäre das so als wenn du sagen würdest "Ist Rakete eine andere Bezeichnung für Dreirad...??"
Also besser mal etwas lesen:
http://de.wikipedia.org/wiki/Open_Shortest_Path_First
und
http://de.wikipedia.org/wiki/RIPv2
Das sollte dir weiterhelfen !!
Soviel:
RIPv2 geht auch, erfordert aber etwas Tuning ! Die Konvergenzzeiten sind schlechter und RIP ist ein Distance Vector Protocol während OSPF ein Link State ist. Will heissen der Overhead bei RIP ist größer, was aber ggf. tolerabel ist bei dir sofern du nicht 100 und mehr IP Netze hast !
Generell ist die dyn.Routing Lösung einfacher zu implementieren und zu warten, deshalb wird sie in der Praxis auch öfter verwendet.
Da hat wohl der Support vermutlich nicht wirklich verstanden was du eigentlich willst oder war etwas überfordert.
Vermutlich meinen sie mit ihrer Aussage die Konfiguration 2er default Gateway IPs. Das ist aber für dein Szenario vollkommen irrelevant, denn es geht dir ja nicht um ein redundantes next Hop Gateway (für den die Lancom Aussage zweifelsohne stimmt) sondern um einen redundanten Tunnel Endpunkt, also etwas völlig anderes. Dafür ist die Aussage dann wieder vollkommen sinnfrei....nunja.
Was dein Wissen um Routing Protokolle angeht hast du ziemliche Defizite was deine Frage von oben klar belegt.
Für einen Netzwerker wäre das so als wenn du sagen würdest "Ist Rakete eine andere Bezeichnung für Dreirad...??"
Also besser mal etwas lesen:
http://de.wikipedia.org/wiki/Open_Shortest_Path_First
und
http://de.wikipedia.org/wiki/RIPv2
Das sollte dir weiterhelfen !!
Soviel:
RIPv2 geht auch, erfordert aber etwas Tuning ! Die Konvergenzzeiten sind schlechter und RIP ist ein Distance Vector Protocol während OSPF ein Link State ist. Will heissen der Overhead bei RIP ist größer, was aber ggf. tolerabel ist bei dir sofern du nicht 100 und mehr IP Netze hast !
Generell ist die dyn.Routing Lösung einfacher zu implementieren und zu warten, deshalb wird sie in der Praxis auch öfter verwendet.
Hallo,
ich habe ein solches Setup mit Funkwerk-Routern produktiv im Einsatz seit ca. 3 1/2 Jahren.
Jede Filiale startet zwei VPN-Tunnel - einen zu jeweils einer der "Zentralen-IPs".
Über die VPNs hinweg kann dann via Loadbalancing oder Routingprioritäten auch die Auslastung gesteuert werden.
Filialseitig ist die zweite Leitung nicht dauerhaft aktiv, sondern wird nur im Failoverfall aktiv geschaltet. Bei den "kleinen" Funkwerk-Routern ist es auch überhaupt kein Problem, mehrere Leitungen anzusprechen.
Der entscheidende Punkt ist einfach, dass es zwei VPN-Kanäle pro Filiale gibt.
Phil
ich habe ein solches Setup mit Funkwerk-Routern produktiv im Einsatz seit ca. 3 1/2 Jahren.
Jede Filiale startet zwei VPN-Tunnel - einen zu jeweils einer der "Zentralen-IPs".
Über die VPNs hinweg kann dann via Loadbalancing oder Routingprioritäten auch die Auslastung gesteuert werden.
Filialseitig ist die zweite Leitung nicht dauerhaft aktiv, sondern wird nur im Failoverfall aktiv geschaltet. Bei den "kleinen" Funkwerk-Routern ist es auch überhaupt kein Problem, mehrere Leitungen anzusprechen.
Der entscheidende Punkt ist einfach, dass es zwei VPN-Kanäle pro Filiale gibt.
Phil
Hallo,
noch einmal dankeschön für Eure Antworten.
Zunächst vielleicht, nein, es wars noch nicht ganz. Unser Test wird sich leider bis nächste Woche verzögern, erst dann kann ich wirklich konkrete Aussagen machen. Grund dafür ist, dass die Zentralen "unbemannt" sind und immer eine kleine Reise bedeuten.
aqui:
Die Sache mit den Routing-Protokollen ist nach wie vor interessant (da habe ich in der Tat wenig Ahnung, musste ich bislang auch nicht, danke für die Links! ), dennoch wäre mir die andere Variante lieber, wenn sie funktioniert, da aus meiner Sicht weniger Aufwand.
Wenn der Router auf Zentral-Seite mit einem Port und fester IP am Festnetz hängt, mit einem anderen Port mit fester IP am Sat-Zugang, dann sollte doch dem Filialrouter 2 Gateways als Endpunkte eingetragen werden können, auch wenn diese eigentlich physikalisch nur ein Gerät sind.
Wie gesagt, würde ich dazu allerdings erst unseren Test abwarten wollen.
Phil:
Das mit den Funkwerk-Routern hört sich gut an, habe mich auf deren Seite einmal etwas schlau gemacht.
Hört sich sowohl technisch als auch preislich nach einer echten Alternative an. Da allerdings müsste noch geklärt werden, wie diese Geräte mit langen Signallaufzeiten (250ms aufwärts) zurechtkommen. Das ist auch noch so eine Sorge, die bei Lancom auch noch nicht so ganz gelöst ist, wenn dort die Laufzeit zu groß wird, bricht der VPN ab. (Ein Ping von über 1000ms ist nichts ungewöhnliches)
Du hast nicht zufällig auch irgendwo eine Satellitenstrecke im Einsatz?
Danke und Gruß,
Peter
noch einmal dankeschön für Eure Antworten.
Zunächst vielleicht, nein, es wars noch nicht ganz. Unser Test wird sich leider bis nächste Woche verzögern, erst dann kann ich wirklich konkrete Aussagen machen. Grund dafür ist, dass die Zentralen "unbemannt" sind und immer eine kleine Reise bedeuten.
aqui:
Die Sache mit den Routing-Protokollen ist nach wie vor interessant (da habe ich in der Tat wenig Ahnung, musste ich bislang auch nicht
, danke für die Links! ), dennoch wäre mir die andere Variante lieber, wenn sie funktioniert, da aus meiner Sicht weniger Aufwand.Wenn der Router auf Zentral-Seite mit einem Port und fester IP am Festnetz hängt, mit einem anderen Port mit fester IP am Sat-Zugang, dann sollte doch dem Filialrouter 2 Gateways als Endpunkte eingetragen werden können, auch wenn diese eigentlich physikalisch nur ein Gerät sind.
Wie gesagt, würde ich dazu allerdings erst unseren Test abwarten wollen.
Phil:
Das mit den Funkwerk-Routern hört sich gut an, habe mich auf deren Seite einmal etwas schlau gemacht.
Hört sich sowohl technisch als auch preislich nach einer echten Alternative an. Da allerdings müsste noch geklärt werden, wie diese Geräte mit langen Signallaufzeiten (250ms aufwärts) zurechtkommen. Das ist auch noch so eine Sorge, die bei Lancom auch noch nicht so ganz gelöst ist, wenn dort die Laufzeit zu groß wird, bricht der VPN ab. (Ein Ping von über 1000ms ist nichts ungewöhnliches)
Du hast nicht zufällig auch irgendwo eine Satellitenstrecke im Einsatz?
Danke und Gruß,
Peter
OK, dann bleibt dir in der Tat nur der Doppeltunnelweg wie ihn derPhil ja auch erfolgreich einsetzt. Ist ja auch für einen Test schnell aufzusetzen.
Die langen Laufzeiten sind aber generell problematisch nicht nur speziell für dieses Design.
Letztlich kannst du aber etwas an den VPN Timern drehen (sofern deine Hardware sowas zulässt im Featureset bzw. Konfig) damit sollte man das allemal in den Griff bekommen.
OK, dann harren wir mal der Ergebnisse die da kommen sollen....
Die langen Laufzeiten sind aber generell problematisch nicht nur speziell für dieses Design.
Letztlich kannst du aber etwas an den VPN Timern drehen (sofern deine Hardware sowas zulässt im Featureset bzw. Konfig) damit sollte man das allemal in den Griff bekommen.
OK, dann harren wir mal der Ergebnisse die da kommen sollen....
Hallo zusammen,
wir haben unseren Test jetzt soweit durchgeführt.
Generell ist das Szenario mit den "weiteren Gateways" möglich, es werden 2 Tunnelendpunkte eingetragen.
Der Router baut dann den VPN-Kanal bei Bedarf zum "Hauptendpunkt" auf, ist dieser nicht verfügbar, dann zum "Ersatzendpunkt".
Soweit ist dies also durchaus möglich.
Allerdings wird immer nur 1 Tunnel aufgebaut, ob der 2te verfügbar ist, sieht man leider nicht. Schade, die von aqui vorgeschlagene Lösung mit 2 stehenden Tunneln wäre schon ansprechender.
Zu diesem Thema habe ich jetzt auch bei Funkwerk nachgefragt, bin gespannt auf die Nachricht.
Möchte mich noch einmal für Eure Hilfe / Anregungen bedanken!!
Gruß,
Peter
wir haben unseren Test jetzt soweit durchgeführt.
Generell ist das Szenario mit den "weiteren Gateways" möglich, es werden 2 Tunnelendpunkte eingetragen.
Der Router baut dann den VPN-Kanal bei Bedarf zum "Hauptendpunkt" auf, ist dieser nicht verfügbar, dann zum "Ersatzendpunkt".
Soweit ist dies also durchaus möglich.
Allerdings wird immer nur 1 Tunnel aufgebaut, ob der 2te verfügbar ist, sieht man leider nicht. Schade, die von aqui vorgeschlagene Lösung mit 2 stehenden Tunneln wäre schon ansprechender.
Zu diesem Thema habe ich jetzt auch bei Funkwerk nachgefragt, bin gespannt auf die Nachricht.
Möchte mich noch einmal für Eure Hilfe / Anregungen bedanken!!
Gruß,
Peter
Hallo,
leider ist der Funktwerksupport seit ein paar Monaten sehr Träge. Ich hoffe, Du bekommst trotzdem Antworten.
Ich setze keine Sat-Verbindungen ein. Das "Exotischste" sind ISDN-Internet-Wahlverbindungen aus AT und CH. Dabei habe ich Latenzen bis ca. 1000ms und keine Verbindungsabbrüche. Ich wüsste ehrlich gesagt auch nicht, warum Latenzen ein Problem sein sollten.
Bei Funkwerk kann man auch die Abbruchbedingung anhand eines Heartbeats frei konfigurieren.
Wenn Du mein "konkretes" Szenatio umsetzen willst, kannst Du mir gerne eine PM schicken, dann kann ich Dir leichter helfen.
Phil
leider ist der Funktwerksupport seit ein paar Monaten sehr Träge. Ich hoffe, Du bekommst trotzdem Antworten.
Ich setze keine Sat-Verbindungen ein. Das "Exotischste" sind ISDN-Internet-Wahlverbindungen aus AT und CH. Dabei habe ich Latenzen bis ca. 1000ms und keine Verbindungsabbrüche. Ich wüsste ehrlich gesagt auch nicht, warum Latenzen ein Problem sein sollten.
Bei Funkwerk kann man auch die Abbruchbedingung anhand eines Heartbeats frei konfigurieren.
Wenn Du mein "konkretes" Szenatio umsetzen willst, kannst Du mir gerne eine PM schicken, dann kann ich Dir leichter helfen.
Phil
Hallo Phil,
Danke für die Nachricht.
Funkwerk war eigentlich schon schnell, habe am Freitag bereits 2 R3000 für eine Test-Stellung bekommen,
alles innerhalb einer Woche.
Allerdings sieht die Webconfiguration schon erheblich anders aus, als bei der Konfigurationssoftware von Lancom, gut dass wird immer so sein und ist ja auch weniger wichtig.
Werde gerne auf Dein Angebot zurückkommen, vielleicht können wir uns ja ein wenig an dein Szenario anlehnen.
Gruß,
Peter
Danke für die Nachricht.
Funkwerk war eigentlich schon schnell, habe am Freitag bereits 2 R3000 für eine Test-Stellung bekommen,
alles innerhalb einer Woche.
Allerdings sieht die Webconfiguration schon erheblich anders aus, als bei der Konfigurationssoftware von Lancom, gut dass wird immer so sein und ist ja auch weniger wichtig.
Werde gerne auf Dein Angebot zurückkommen, vielleicht können wir uns ja ein wenig an dein Szenario anlehnen.
Gruß,
Peter