OpenVPN Client bei Multi-WAN kommt nicht hoch.
-
Servus,
ich mach bei Multi-WAN gerade meine ersten Gehversuche. Ich habe eine pfS mit Multi-WAN auf der ein OpenVPN-Client läuft.MultiWAN ist in zwei GW-Groups konfiguriert:
1. GW A Tier 1
GW B Tier 22. GW B Tier 1
GW A Tier 2So hatte ich mir das aus einem How2 gefischt und es funzt soweit auch alles prächtig. Nur OpenVPN, welches ja an ein Interface gebunden werden muss, geht mir auf die Nerven. Manuell umgestellt auf die jeweilige GW-Group funzt alles super. Nur bei Ausfall eines GW kommt OpenVPN nicht mehr hoch. Auch mit nur einer GW-Group gehts nicht.
Ist das Ding etwas nicht für Failover gedacht? Das wäre ja gruselig :o
Grüße
-
Ich bin einen Schritt weiter. Aus irgendwelchen Gründen läufts jetzt ;D Geändert hab ich soweit nichts mehr, nur ein Reboot war mal dazwischen.
Was mir aber aufgefallen ist: Nachm Umschalten kommt der Tunnel zwar hoch, der Ping vom Rechner aus B nach Rechner aus A kommt das erste Mal aber nicht mehr zurück. Erst nach einem States Reset läuft er wieder. Sobald das einmal geschehen ist, kann man beliebig hin und herschalten, er kommt immer wieder.
Der Arpinger scheint irgendwie auch nicht ganz zuverlässig zu sein. Die Monitore stehen auf 8.8.8.8 und 8.8.4.4 jeweils auf Packet Loss. Ich musste Arpinger schon manuell neustarten, erst dann wurde der GW als down identifiziert.
Das kann doch nicht normal sein ???
-
In System > Advanced > Miscellaneous gibt es die Einstellung "State Killing on Gateway Failure".
Dort der Haken gesetzt und die States werden automatisch gekillt.
;)Die Frage, warum das nicht von Vornherein gesetzt ist, kann ich dir auch nicht beantworten. Ist vermutlich nicht immer ein Vorteil.
-
Servus,
den Haken kenne ich. Ich lese das allerdings so, dass der gesetzte Haken genau diese Funktion deaktiviert ??? -
Ich auch. Verwirrend.
Ich nutze auf meinen Installationen nur jeweils ein Gateway und kann es daher nicht testen. Soweit ich das in Threads hier mitbekommen habe funktioniert es aber, also wenn der Haken dann offenbar nicht gesetzt ist.
-
Also ich kann auch bestätigen, dass die States bei Multiwan im Failover Betrieb rumzicken.
Ich musste mir aus diesem Grund schon ein Cronjob einrichten, der Nachts 3 Minuten nach der DSL Zwangstrennung nochmal die States killt.
Es gibt zwar eine versteckte Funktion der die States nach einem IP Wechsel automatisch killen soll, aber das funktioniert bei mir nicht.
Der Haken "State Killing on Gateway Failure" ist bei mir übrigens auch nicht gesetzt. Aber das alles funktioniert leider nicht hundertprozentig.Auch ein trägeres Reagieren des Apingers durch anpassen der Gateways (Probe Interval usw.) bringt bei mir keine Lösung.
-
Also irgendwie kanns das ja nicht dauerhaft sein. Es nutzen doch sicher viele die Funktionen mit Loadbalancing / Failover und die würden sich doch vermutlich nicht damit zufrieden geben ???
Bei mir zickt wieder alles rum. Ist der eine GW weg, reagiert das System fast nicht mehr. Die Seitenwechsel in der Konfig dauern bis zu einer Minute bzw. zum Browser-Timeout. OpenVPN baut sich nicht mehr auf.
Ich habe gerade eine neue Installation angelegt und mit der Konfig versehen. Alles sehr seltsam :-\
-
Kann mir bitte mal jemand meine Erwartungen kommentieren. Ich erwarte nämlich folgendes Verhalten:
1. Beim Umschalten von GW A auf B kommt es zu kurzen Unterbrechungen bestehender Verbindungen
2. Ein ping -t www.google.de von einem Client aus kommt nach kurzer Unterbrechung wieder von selbst hoch
3. Der OpenVPN-Tunntel baut sich erneut auf
4. Ping -t auf einen Rechner am anderen Endes Tunnels kommt wieder hoch
5. Ist GW A wieder online, schaltet alles wieder zurück von B auf A
6. Beim Abschalten von GW B dürfte folglich gar nichts passierenFolgendes passiert OHNE Eingreifen meinerseits (State Reset):
1. Jupp
2. Nope. Ping kommt nicht selbstständig hoch
3. Jupp, 5 Pings Aussetzer und schon gehts weiter.
4. Jupp, 5 Pings Aussetzer und schon gehts weiter.
5.
a)Ping -t aus 2. kommt wieder. Es wurde also keine neue Route gesucht
b)Ein Ping Verlust und der Tunnel steht wieder, Ping läuft
6. JuppFolgendes passiert MIT Eingreifen meinerseits (State Reset):
1. Jupp
2. Nope. Ping kommt nicht selbstständig hoch
3. a) Tunnel steht wieder, Ping geht weiterState Reset:
3. b) Ping -t www.google.de ist nach State Reset wieder da
4.Tunnel läuft immer noch
5. Tunnel schaltet zurück auf GW A, ein Ping Verlust. ping -t www.google.de läuft weiter.
6. ping -t www.google.de läuft wieder nicht! Ping hat also NICHT auf GW A umgeschalten.Folgende Konfig:
Aktuelle pfS mit zwei static WAN. Haken bei "State Killing one Gateway Failure" ist drin (default)
Folgende Konfig:
Aktuelle pfS mit zwei static WAN.
1. GW A Tier 1
GW B Tier 22. GW B Tier 1
GW A Tier 2