ubuntuusers.de

OpenVPN Routing Probleme

Status: Gelöst | Ubuntu-Version: Server 14.04 (Trusty Tahr)
Antworten |

loewe.xy

Anmeldungsdatum:
8. Juni 2012

Beiträge: 165

Hallo Zusammen,

ich versuche gerade einen OpenVPN Server aufzusetzen, der es mir erlaubt unterwegs auf Resourcen in meinem Heimnetzwerk zuzugreifen. Die Einrichtung habe ich nach der Anleitung im Wiki gemacht, soweit funktioniert der Server auch und ich kann mich mit einem Client verbinden. Aber jetzt habe ich doch recht masive Probleme beim Routing.

Die entstehende Routingtabelle am Client sieht so aus, bei diesem Test war der Client über WLAN Tethering über das Smartphone am Internet. Zu dem Smartphone Hotspot gehört das 192.168.43.0 Netz. Das Heimnetz hat die IP 192.168.15.0. Und der VPN Server soll das 192.168.14.0 Netz verwenden.

~$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.43.1    0.0.0.0         UG    0      0        0 wlan0
81.27.126.106   192.168.43.1    255.255.255.255 UGH   0      0        0 wlan0
192.168.14.0    192.168.14.5    255.255.255.0   UG    0      0        0 tun0
192.168.14.5    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.43.0    0.0.0.0         255.255.255.0   U     9      0        0 wlan0

Ich verstehe nicht was die 192.168.14.5 Adresse hier soll, und welches Gerät das sein soll. Vom Client kann ich weder 192.168.14.1 noch 192.168.14.5 anpingen. Meinem Verständniss nach sollte die Tabelle eher so aussehen...

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.43.1    0.0.0.0         UG    0      0        0 wlan0
81.27.126.106   192.168.43.1    255.255.255.255 UGH   0      0        0 wlan0
192.168.14.0    0.0.0.0         255.255.255.0   UG    0      0        0 tun0
192.168.43.0    0.0.0.0         255.255.255.0   U     9      0        0 wlan0

Meine /etc/openvpn/server.conf sieht so aus:

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 1194

# TCP or UDP server?
proto udp

# Create routed tunnel
dev tun

# Configure Keys
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/home.dyndns.lukas-metzger.com.crt
key ./easy-rsa2/keys/home.dyndns.lukas-metzger.com.key  # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
#   openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys. 
dh ./easy-rsa2/keys/dh2048.pem

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 192.168.14.0 255.255.255.0

# Maintain a record of client <-> virtual IP address
# associations in this file.  If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt

# Push routes to the client to allow it
# to reach other private subnets behind
# the server.  Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.0.0 255.255.0.0"

# Push DNS Server
push "dhcp-option DNS 192.168.15.3"

# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
client-to-client

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo

# Set Permissions
user openvpn
group openvpn

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 4

Mir ist klar das ich mit der Config momentan das 192.168.15.0 Netz noch nicht erreichen kann. Aber zunächst möchte ich mal die Verbindung bis zum VPN Server zum funktionieren bekommen.

Vielen Dank schonmal für eure Bemühungen.

Gruß Lukas

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

loewe.xy schrieb:

Ich verstehe nicht was die 192.168.14.5 Adresse hier soll, und welches Gerät das sein soll. Vom Client kann ich weder 192.168.14.1 noch 192.168.14.5 anpingen.

Diese zusätzlichen Adressen sind normal (interne Routinggeschichte?) und können normalerweise einfach ignoriert werden. Bei mir auch so.

Client:

$ route -n
10.0.42.0       10.0.42.5       255.255.255.0   UG    0      0        0 tun0
10.0.42.5       0.0.0.0         255.255.255.255 UH    0      0        0 tun0

$ ip route
10.0.42.0/24 via 10.0.42.5 dev tun0 
10.0.42.5 dev tun0  proto kernel  scope link  src 10.0.42.6 

$ ip addr
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.0.42.6 peer 10.0.42.5/32 scope global tun0

Server:

$ route -n
10.0.42.0       10.0.42.2       255.255.255.0   UG    0      0        0 tun0
10.0.42.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0

$ ip route
10.0.42.0/24 via 10.0.42.2 dev tun0 
10.0.42.2 dev tun0  proto kernel  scope link  src 10.0.42.1 

$ ip addr
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.0.42.1 peer 10.0.42.2/32 scope global tun0

Anpingen lassen sich diese peers (.2 und .5) bei mir auch nicht. Trotzdem funktioniert alles so wie soll (.1 und .6 sehen sich).

Das netzübergreifende Routing hab ich mir gespart, bei mir hängt einfach alles direkt am VPN. 😉 Ist natürlich nicht immer eine Option...

loewe.xy

(Themenstarter)

Anmeldungsdatum:
8. Juni 2012

Beiträge: 165

Ich kann vom Client aber auch den Server nicht anpingen also die 192.168.14.1...

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Hast du noch eine Firewall oder sowas was dazwischenfunken könnte? Hast du nur Ping probiert oder auch SSH o.ä.?

Daß eine VPN-Verbindung besteht (also sichtbares & konfiguriertes tun0 Device) aber dann nichts weiter geht, das hatte ich noch nicht... einen Fehler seh ich da jetzt direkt auch nicht.

Du könntest mal mit tcpdump schauen ob überhaupt ein Paket auf die Leitung rausgeht und dementsprechend auf der anderen Kiste ankommt...

loewe.xy

(Themenstarter)

Anmeldungsdatum:
8. Juni 2012

Beiträge: 165

Verstehe ich jetzt zwar nicht ... aber jetzt funktioniert der Ping an die 192.168.14.1.

zusätzlich habe ich jetzt folgende Zeile einkommentiert.

push "route 192.168.0.0 255.255.0.0"

Ein Ping an 192.168.15.15 (ip des VPN Servers im lokalen Netz) funktioniert. Andere IPs aus dem 192.168.15.0/24 Subnetz allerdings nur manchmal und nicht alle. IP Forwarding am Server habe ich aber eigentlich an.

~$ sysctl net/ipv4/ip_forward
net.ipv4.ip_forward = 1

Und der Server hat auch eine Route für dieses Subnetz.

~$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.15.1    0.0.0.0         UG    0      0        0 eth0
192.168.14.0    192.168.14.2    255.255.255.0   UG    0      0        0 tun0
192.168.14.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

Möglicherweise liegt das aber auch daran, dass die Internetverbindung meines Clients grade über schlechtes EDGE Handynetz geht. Ich habe teilweise Ping Zeiten von 20 Sekunden und mehr. Ich werde das mal noch heute oder morgen mit einem besseren Internetzugang testen und dann berichten.

Danke auf jeden fall schonmal für die Hilfe.

Gruß Lukas

loewe.xy

(Themenstarter)

Anmeldungsdatum:
8. Juni 2012

Beiträge: 165

Also nachdem ich jetzt noch auf TCP gewechselt bin, da UDP auf Port 1194 bei meiner Hochschule im WLAN blockiert wird. Habe ich jetzt nochmal getestet und stelle ein ziemlich komisches Verhalten fest, nochmal zur Zusammenfassung.

192.168.14.0/24 Subnetz für das VPN 192.168.15.0/24 Subnetz für das Heimnetz

Wenn ich mich jetzt von Extern mit dem VPN Verbinde kann ich nicht alle Hosts im Heimnetz anpingen. Und zwar funktioniert ein Ping auf den Netzwerkdrucker mit der IP .30 und meinen Desktop mit der IP .40. Auch der VPN-Server ist mit seiner Internen IP 192.168.15.15 erreichbar.

Die Fritzbox 192.168.15.1 und auch meine Server von 192.168.15.2-192.168.15.13 sind nicht erreichbar. Der VPN-Server hat eigentlich ein Route für das ganze Subnetz.

~$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.15.1    0.0.0.0         UG    0      0        0 eth0
192.168.14.0    192.168.14.2    255.255.255.0   UG    0      0        0 tun0
192.168.14.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

Wenn ich mich auf dem VPN Server per SSH einlogge kann ich von dort aus auch alle Server anpingen ...

Ich bin jetzt ziemlich ratlos an was das noch liegen könnte, ich hoffe von euch hat noch jemand eine Idee.

Viele Grüße

Lukas

methyphobia

Avatar von methyphobia

Anmeldungsdatum:
19. Oktober 2013

Beiträge: 6

Wohnort: Saarland

Ist auf dem Standardgateway des Heimnetzes (vermutlich die Fritzbox) auch die Rückroute zu 192.168.14.0/24 auf den Next-Hop 192.168.15.15 eingetragen? Das würde erklären, warum der VPN-Server aus dem VPN erreichbar ist (er kennt ja den Weg zu 192.168.14.0/24, da directly-connected), aber der Rest vom LAN nicht.

loewe.xy

(Themenstarter)

Anmeldungsdatum:
8. Juni 2012

Beiträge: 165

Ich hab das Problem gelößt die Route für 192.168.0.0/16 an den VPN Server 192.168.15.15 wird eigentlich vom DHCP Server verteilt, die Server hatten seit der Änderung am DHCP keinen Reboot und deshalb keine neuen Infos. Mein Rechner und der Drucker schon, ein kompletter Reboot aller Server hat das Problem gelöst.

Vielen Dank für euere Hilfe

Antworten |