OpenVPN Gateway Fallback

R2-D2199 · 13. Mai 2013

Hallo zusammen,

ich hätte da mal ein Problem.

Ausgangssituation:
vServer im Internet als OpenVPN Server
Raspberry zu Hause mit OpenVPN Client und OSCAM Server
Gateway 1 (192.168.1.1) zu Hause, Internet per Richtfunk
Gateway 2 (192.168.1.3) zu Hause, Internet per UMTS

Clients verbinden sich auf den vServer, welcher die Anfragen per Tunnel zum Raspberry weiterleitet.
Da die Internetverbindung von Gateway 1 schon mal für ein paar Minuten abbricht, besonders bei schlechtem Wetter, wollte ich nun ein Fallback auf Gateway 2 einrichten.

Ich habe mir einen Skript gebastelt, welcher prüft ob das Internet (8.8.8.8) über Gateway 1 erreichbar ist, wenn nein, schalte openVPN aus, ändere das default Gateway auf Gateway 2 und stelle die VPN Verbindung wieder her.

Das klappt auch so weit, allerdings dauert es ca. 30 Sekunden bis die Verbindung komplett auf das jeweils andere Gateway gewechselt ist und sich wieder Clients verbinden können.

Ich suche eine Lösung die schneller reagiert, ggf. so schnell das die Clients es nicht merken.
Ist es vielleicht möglich 2 Tunnel aufzubauen und dann je nach Verfügbarkeit der Tunnel die Daten zu verschicken?

Vielen Dank im Voraus

pr0j3ctx · 15. Mai 2013

AW: OpenVPN Gateway Fallback

Hallo.

Ich habe zu Hause zwei Internetverbindungen 1x DSL und 1x UMTS. Damit ich eine schnelle Umschaltung habe und diese kaum merke nutze ich dafür zwei OpenVPN Verbindungen. Pro Internetverbindung eine. Das routen überlasse ich olsr. Der schaltet die Verbindungen sehr schnell um. Da ich immer über meine vServer IP rausgehe gehen eigentliche keine Pakete verloren, da ich immer über die eine ext. IP am root-Server erreichbar bin.

Kurz zum Aufbau: (Optimal wären zwei IP´s am vServer)

DSL Router 192.168.0.1
UMTS Router 192.168.0.2

vServer IP1: 5.5.5.5
vServer IP2: 5.5.5.6

Nun lässt du einen OpenVPN Server auf 5.5.5.5 und einen auf 5.5.5.6 laufen. Vom Raspberry baust du dann zwei Tunnel auf. Bevor du diese aber aufbaust setzt du zwei routen. Undzwar:
5.5.5.5 über 192.168.0.1 und
5.5.5.6 über 192.168.0.2

Dann setzt du auf beiden Servern olsr ein. OLSR routet dann entsprechend der besseren Leitung die Pakete über den einen oder den anderen Weg. In der Konfiguration kannst du aber auch noch Prioritäten setzen falls du eine Leitung bevorzugst.

Bei ein paar Tests sind bei mir im Schnitt beim Wegfall einer LEitung ca 1-2 Pakete (beim ping) verloren gegangen.

Schöne Grüße
pr0

R2-D2199 · 15. Mai 2013

AW: OpenVPN Gateway Fallback

Danke schon mal.
Das werde ich mir auf jeden Fall mal angucken.

Ich kann bloß beim vServer keine weitere IPv4 dazubuchen, nur ein IPv6 Subnetz. Keiner der beiden Zugänge unterstützt IPv6.
Und wie soll die Portweiterleitung auf dem vServer funktionieren?
Der vServer hat im VPN die 192.168.200.1 der Raspberry die 192.168.200.2.
Der vServer leitet alle Anfragen auf einem bestimmten Port der WAN-Adresse auf die 192.168.200.2 weiter.

pr0j3ctx · 15. Mai 2013

AW: OpenVPN Gateway Fallback

Hi.

Bei nur einer IP gibt es eine Möglichkeit über iptables. Suche ich dir morgen raus.

Grüsse

Gesendet von meinem GT-S7562 mit Tapatalk 2

pr0j3ctx · 16. Mai 2013

AW: OpenVPN Gateway Fallback

Hallo.

wie schon geschrieben, mit einer IP geht es auch. Dafür brauchen wir iptables und iproute2. Eigentlich bei jedem Linux dabei.

Grobe Schritte:
1. Dafür setzt du auf dem vServer zwei VPN Server auf. Einmal Port 1194 und 1195.
2. Auf dem Raspberry mit iptables die Pakete markieren die über 1194 gehen und die über 1195 gehen.
3. Die entsprechend markierten Pakete über die entsprechende routing Tabelle schicken

Nun hast du zwei VPN-Verbindungen die über unterschiedliche Gateways gehen. Hier gibt es auch noch eine kleine BEschreibung. Musst du halt anpassen.

Sie müssen registriert sein, um Links zu sehen.

Was die Portweiterleitung betrifft:
Das olsr wird dir Routen setzen, die du vorher festlegst.
-Auf dem Raspberry eine default-route über den vServer.
-Auf dem vServer wird dann eine Route auf den Raspberry gesetzt, aber nicht auf die Tunnel-IP´s sondern auf die Raspberry IP die er im lokalen Netz bei dir hat.
Auf diese IP setzt du dann die Portweiterleitung. Natürlich auf dem vServer noch NAT, damit das Raspberry auch raustelefonieren kann.

Falls du weitere Fragen hast oder detaillierte Konfigurationen benötigst, sag einfach bescheid. Am besten schickst du dann aber auch ein paar IP´s mit. ALso von den Routern und dem Raspberry + Tunnel-IP´s. Die vServer IP kann eine ausgedachte sein. Aber es ist dann einfacher das ganze zu beschreiben.

Grüße
pr0

R2-D2199 · 22. Mai 2013

AW: OpenVPN Gateway Fallback

Also momentan sieht es so aus.
Meinen vServer nennen wir jetzt einfach mal 1.1.1.1
Der Raspberry Pi hat die 192.168.1.10.
Der normale Router die 192.168.1.1 und der UMTS Router die 192.168.1.3
Der Raspberry hat auf dem ersten VPN Interface die 192.168.200.2 und auf dem zweiten die 192.168.201.2 (der Server jeweils die .1)
Auf dem vServer laufen 2 OpenVPN Server.

OpenVPN auf 1194

## server.ovpn ##
port 1194
proto udp
dev tap
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh1024.pem
server 192.168.200.0 255.255.255.0
client-to-client
push "route 192.168.200.0 255.255.255.0"
keepalive 10 120
comp-lzo
max-clients 50
persist-key
persist-tun
status openvpn-status.log
verb 3

OpenVPN auf 1195

## server.ovpn ##
port 1195
proto udp
dev tap
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh1024.pem
server 192.168.201.0 255.255.255.0
client-to-client
push "route 192.168.201.0 255.255.255.0"
keepalive 10 120
comp-lzo
max-clients 50
persist-key
persist-tun
status openvpn-status.log
verb 3

Der Raspberry Pi ist mit beiden Servern verbunden.

Client auf 1194

clientfloat
dev tap
proto udp
remote 1.1.1.1 1194
tls-remote vpn
ca /etc/openvpn/config/ca.crt
cert /etc/openvpn/config/client.crt
key /etc/openvpn/config/client.key
auth SHA1
nobind
comp-lzo
persist-key
persist-tun
verb 0
route 192.168.200.0 255.255.255.0

Client auf 1195

clientfloat
dev tap
proto udp
remote 1.1.1.1 1195
tls-remote vpn
ca /etc/openvpn/config/ca.crt
cert /etc/openvpn/config/client.crt
key /etc/openvpn/config/client.key
auth SHA1
nobind
comp-lzo
persist-key
persist-tun
verb 0
route 192.168.201.0 255.255.255.0

Die beiden Verbindungen gehen auch wie du beschrieben hast über die unterschiedlichen Gateways raus.

Muss jetzt nur auf dem Server olsr eingerichtet werden oder muss das auch auf dem Raspberry gemacht werden?
Wie muss olsr konfiguriert werden?

pr0j3ctx · 24. Mai 2013

AW: OpenVPN Gateway Fallback

Hi,

olsr muss auf beiden eingerichtet werden. Das push route erstmal überall auskommentieren.

olsrd.conf Raspberry

# If set to 0 the daemon runs in the background
DebugLevel 0

# IP version to use (4 or 6)
IpVersion 4

# FIBMetric ("flat", "correct", or "approx")
FIBMetric "flat"

# Clear the screen each time the internal state changes
ClearScreen yes

# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"
AllowNoInt yes

# Update default-routes in routing-table default
RtTableDefault 253

# Announce fixed ip-ranges
Hna4
{
# Push "fixed ip-ranges" route-information available through this router

# Entweder gantes Heimnetz oder nur Raspberry vom vServer erreichbar machen.

# 192.168.1.10 255.255.255.255
192.168.1.0 255.255.255.0
}

# Allow processes like the GUI front-end to connect to the daemon.
IpcConnect
{
# Disable IPC
MaxConnections 0
}

# Wether to use hysteresis or not
# Hysteresis adds more robustness to the link sensing but delays neighbor regist ration.
UseHysteresis no

# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
LinkQualityLevel 2

# Polling rate in seconds(float).
# Default value 0.05 sec
Pollrate 0.05

# Interval to poll network interfaces for configuration
# changes.
NicChgsPollInt 3.0

# Specifies how much neighbor info should be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
TcRedundancy 2

# Specifies how many MPRs a node should try select to reach every 2 hop neighbor
# Can be set to any integer > 0
MprCoverage 3

# !!CHANGE THE INTERFACE LABEL(s) TO MATCH YOUR INTERFACE(s)!!
# (eg. wlan0 or eth1):
Interface "tun1"
{
AutoDetectChanges yes
Ip4Broadcast 192.168.200.1

HelloInterval 2.0
HelloValidityTime 6.0

TcInterval 5.0
TcValidityTime 15.0

MidInterval 5.0
MidValidityTime 15.0

HnaInterval 5.0
HnaValidityTime 15.0
Weight 1
}
Interface "tun2"
{
AutoDetectChanges yes
Ip4Broadcast 192.168.201.1

HelloInterval 2.0
HelloValidityTime 6.0

TcInterval 5.0
TcValidityTime 15.0

MidInterval 5.0
MidValidityTime 15.0

HnaInterval 5.0
HnaValidityTime 15.0
Weight 9
}

olsrd.conf vServer

# If set to 0 the daemon runs in the background
DebugLevel 1

# IP version to use (4 or 6)
IpVersion 4

# FIBMetric ("flat", "correct", or "approx")
FIBMetric "flat"

# Clear the screen each time the internal state changes
ClearScreen yes

# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"
AllowNoInt yes

# Announce fixed ip-ranges
Hna4
{
# Push "Default-Gateway" route-information
0.0.0.0 0.0.0.0
}

# Allow processes like the GUI front-end to connect to the daemon.
IpcConnect
{
# Disable IPC
MaxConnections 0
}

# Wether to use hysteresis or not
# Hysteresis adds more robustness to the link sensing but delays neighbor registration.
UseHysteresis no

# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
LinkQualityLevel 2

# Polling rate in seconds(float).
# Default value 0.05 sec
Pollrate 0.05

# Interval to poll network interfaces for configuration
# changes.
NicChgsPollInt 3.0

# Specifies how much neighbor info should be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
TcRedundancy 2

# Specifies how many MPRs a node should try select to reach every 2 hop neighbor
# Can be set to any integer > 0
MprCoverage 3

LoadPlugin "/root/olsrd-0.6.3/lib/httpinfo/olsrd_httpinfo.so.0.1" {
PlParam "Host" "0.0.0.0 0.0.0.0"
PlParam "port" "8080"
}
# !!CHANGE THE INTERFACE LABEL(s) TO MATCH YOUR INTERFACE(s)!!
# (eg. wlan0 or eth1):
Interface "tun1"
{
AutoDetectChanges yes
Ip4Broadcast 192.168.200.2

HelloInterval 2.0
HelloValidityTime 6.0

TcInterval 5.0
TcValidityTime 15.0

MidInterval 5.0
MidValidityTime 15.0

HnaInterval 5.0
HnaValidityTime 15.0
Weight 1
}
Interface "tun2"
{
AutoDetectChanges yes
Ip4Broadcast 192.168.201.2

HelloInterval 2.0
HelloValidityTime 6.0

TcInterval 5.0
TcValidityTime 15.0

MidInterval 5.0
MidValidityTime 15.0

HnaInterval 5.0
HnaValidityTime 15.0
Weight 9
}

Über Weight ganz unten kannst du eine Leitung bevorzugen.

Grüße
pr0

pr0j3ctx · 11. Juni 2013

AW: OpenVPN Gateway Fallback

Und klappt es?

R2-D2199 · 17. Juli 2013

AW: OpenVPN Gateway Fallback

Da in letzter Zeit mehrere Ausfälle auf der Richtfunkstrecke waren (Gewitter und Hitze) wurde ein Test überflüssig
Klappt alles wie gewünscht, die meisten Clients verlieren noch nicht mal die Verbindung.

pr0j3ctx · 17. Juli 2013

AW: OpenVPN Gateway Fallback

Ok super

Gesendet von meinem GT-I9082 mit Tapatalk 2

OpenVPN Gateway Fallback

R2-D2199

Newbie

pr0j3ctx

Ist oft hier

R2-D2199

Newbie

pr0j3ctx

Ist oft hier

pr0j3ctx

Ist oft hier

R2-D2199

Newbie

pr0j3ctx

Ist oft hier

pr0j3ctx

Ist oft hier

R2-D2199

Newbie

pr0j3ctx

Ist oft hier

Ähnliche Themen

OpenVPN Gateway Fallback

Newbie

Ist oft hier

Newbie

Ist oft hier

Ist oft hier

Newbie

Ist oft hier

Ist oft hier

Newbie

Ist oft hier

Ähnliche Themen

Datenschutz & Transparenz

Datenschutz & Transparenz