OpenVPN Netzwerk hinter Client erreichen

P

pfaelzer

Neuling
Thread Starter
Mitglied seit
26.08.2012
Beiträge
133
Hallo zusammen,

ich habe schon einmal begonnen mein Problem im UTM Unterforum zu posten, ich denke jedoch, dass das Problem eher am OpenVPN bzw. an den Routen des Clients liegen. hier

Folgender Aufbau

Home
Netz 192.168.178.0/24
UTM 192.168.178.254
Gateway 192.168.178.254

VPN SSL
UTM (Server) 10.242.2.1
Raspi (Client) 10.242.2.2

Entferntes Netz
Netz 192.168.0.0/24
Gateway 192.168.0.1

Router 192.168.0.1
Raspi 192.168.0.2 (VPN SSL 10.242.2.2)

Was funktioniert?
Vom entfernten Netz (192.168.0.0/24) erreiche ich mein komplettes Homenetz (192.168.178.0/24 (sofern ich die Firewallregel in der UTM aktiviere)

Was funktioniert nicht?
Vom Homenetz erreiche ich nur den VPN Client 192.168.0.2 (10.242.2.2) ansonsten keine Verbindung zu anderen Geräten in diesem entfernten Netz

Was habe ich schon gemacht, das minimaler Erfolg brachte?
Ich habe auf dem Router im entfernten Netzwerk eine Route gesetzt
Destination Network Subnet Mask Default Gateway
192.168.178.0 255.255.255.0 192.168.0.2

mit dieser Route habe ich nun zusätzlich Ping-Zugriff auf den Router selbst. Die Weboberfläche lässt sich jedoch im Homenetz nicht laden.

Tracert vom Homenetzwerk zum Router (192.168.0.1) des entfernten Netzwerkes
1. 192.168.178.254
2. 10.242.2.2
3. 192.168.0.1
erfolgreich

Tracert vom Homenetzwerk zum Raspi (VPN Client / 192.168.0.2 // 10.242.2.2) des entfernten Netzwerkes
1. 192.168.178.254
2. 192.168.0.2
erfolgreich

Tracert vom Homenetzwerk zum einem Accesspoint (192.198.0.10) des entfernten Netzwerkes
1. 192.168.178.254
2. 10.242.2.2
3. Zeitüberschreitung
NICHT erfolgreich

Das sagt mir doch eigentlich, dass die Pakete zum VPN Client geschickt werden und da verloren gehen. Ich denke, dass ich dem Client Routen geben muss?
So sieht aktuell seine Tabelle aus:
raspberrpiroute.JPG
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
nein, ich habe lediglich schon einmal folgendes aktiviert
net.ipv4.ip_forward=1

Ich werde mir den link einmal genauer anschauen.
Wenn du oder jemand anderes da schon genaue Tips habt, gerne her damit :)
 
Also ich habe einen pi als openvpn Server zuhause am laufen. Wenn ich heute abend zuhause bin kann ich dir die iptable regeln mal raussuchen die da gesetzt werden.

Gesendet von meinem Nexus 5X mit Tapatalk
 
Wie sieht den die Routingtable an den beiden Routern sowie den Clients aus?

Normal müsste es wie folgt aussehen:

- im Netz 192.168.178.0/24
Route 192.168.0.0/24 via 192.168.178.254

- im Netz 192.168.0.0/24
Route 192.168.178.0/24 via 192.168.0.2
Route 10.242.2.0/? via 192.168.0.2

Habe ähnliche Variante bei mir am laufen allerdings mit mehreren Sites und dem VPN Server extern in Form eines Rootservers.

pi@raspberrypi ~ $ ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:aa:ed:24
inet addr:192.168.0.22 Bcast:192.168.0.255 Mask:255.255.255.0

tap0 Link encap:Ethernet HWaddr d6:49:2f:0a:e1:e1
inet addr:192.168.10.20 Bcast:192.168.10.255 Mask:255.255.255.0


pi@raspberrypi ~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 202 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
192.168.6.0 192.168.10.9 255.255.255.0 UG 0 0 0 tap0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.170.0 192.168.10.10 255.255.255.0 UG 0 0 0 tap0

pi@raspberrypi ~ $ traceroute 192.168.170.1
traceroute to 192.168.170.1 (192.168.170.1), 30 hops max, 60 byte packets
1 thinkserver.local (192.168.10.10) 150.352 ms 151.435 ms 152.155 ms
2 fritz.box.local (192.168.170.1) 151.653 ms 151.553 ms 151.013 ms
Zum Vergrößern anklicken....

Firewallregeln (iptables) sind dabei erstmal nicht nötig sofern FORWARD auf ACCEPT steht net.ipv4.ip_forward=1 aktiviert ist
 
Zuletzt bearbeitet:
So sieht es auf dem entfernten pi aus
root@raspberrypi:/home/pi# ifconfig
eth0 Link encap:Ethernet Hardware Adresse b8:27:eb:4b:fc:45
inet Adresse:192.168.0.2 Bcast:192.168.0.255 Maske:255.255.255.0

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0

tun0 Link encap:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:10.242.2.2 P-z-P:10.242.2.2 Maske:255.255.255.0

root@raspberrypi:/home/pi# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 202 0 0 eth0
10.242.2.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
XX.XXX.XXX.XXX 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
192.168.178.0 10.242.2.1 255.255.255.0 UG 0 0 0 tun0


root@raspberrypi:/home/pi# traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
1 10.242.2.1 (10.242.2.1) 270.191 ms 270.151 ms 270.143 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C
Zum Vergrößern anklicken....

So sieht es am entfernten Router aus

Ziel Subnet Mask Gateway
XX.XX.XX.XX 255.255.255.0 0.0.0.0 WAN
192.168.178.0 255.255.255.0 192.168.0.2 LAN & WLAN
192.168.0.0 255.255.255.0 0.0.0.0 LAN & WLAN
10.242.2.0 255.255.255.0 192.168.0.2 LAN & WLAN
0.0.0.0 0.0.0.0 XX.XX.XX.XX WAN
Zum Vergrößern anklicken....

und so sieht es an der heimischen UTM aus, leider ziemlich unübersichtlich

default via XXX.X.XXX.XX dev ppp0 table 200 proto kernel onlink
default via XXX.X.XXX.XX dev ppp0 table default proto kernel metric 20 onlink
10.10.32.0/24 dev eth0 proto kernel scope link src 10.10.32.254
10.242.2.0/24 dev tun0 proto kernel scope link src 10.242.2.1
127.0.0.0/8 dev lo scope link
172.16.0.0/24 dev wlan1 proto kernel scope link src 172.16.0.1
172.16.1.0/24 dev wlan2 proto kernel scope link src 172.16.1.1
172.16.2.0/24 dev wlan3 proto kernel scope link src 172.16.2.1
172.16.28.0/24 dev wlan0 proto kernel scope link src 172.16.28.1
192.168.0.0/24 via 10.242.2.1 dev tun0 proto 41
192.168.0.0/24 via 192.168.178.254 dev eth7 proto static metric 1
192.168.2.0/24 via 10.242.2.1 dev tun0 proto 41
192.168.178.0/24 dev eth7 proto kernel scope link src 192.168.178.254
XXX.X.XXX.XX dev ppp0 proto kernel scope link src YY.YYY.YYY.YYY
broadcast 10.10.32.0 dev eth0 table local proto kernel scope link src 10.10.32.254
local 10.10.32.254 dev eth0 table local proto kernel scope host src 10.10.32.254
broadcast 10.10.32.255 dev eth0 table local proto kernel scope link src 10.10.32.254
broadcast 10.242.2.0 dev tun0 table local proto kernel scope link src 10.242.2.1
local 10.242.2.1 dev tun0 table local proto kernel scope host src 10.242.2.1
broadcast 10.242.2.255 dev tun0 table local proto kernel scope link src 10.242.2.1
local YY.YYY.YYY.YYY dev ppp0 table local proto kernel scope host src YY.YYY.YYY.YYY
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.16.0.0 dev wlan1 table local proto kernel scope link src 172.16.0.1
local 172.16.0.1 dev wlan1 table local proto kernel scope host src 172.16.0.1
broadcast 172.16.0.255 dev wlan1 table local proto kernel scope link src 172.16.0.1
broadcast 172.16.1.0 dev wlan2 table local proto kernel scope link src 172.16.1.1
local 172.16.1.1 dev wlan2 table local proto kernel scope host src 172.16.1.1
broadcast 172.16.1.255 dev wlan2 table local proto kernel scope link src 172.16.1.1
broadcast 172.16.2.0 dev wlan3 table local proto kernel scope link src 172.16.2.1
local 172.16.2.1 dev wlan3 table local proto kernel scope host src 172.16.2.1
broadcast 172.16.2.255 dev wlan3 table local proto kernel scope link src 172.16.2.1
broadcast 172.16.28.0 dev wlan0 table local proto kernel scope link src 172.16.28.1
local 172.16.28.1 dev wlan0 table local proto kernel scope host src 172.16.28.1
broadcast 172.16.28.255 dev wlan0 table local proto kernel scope link src 172.16.28.1
broadcast 192.168.178.0 dev eth7 table local proto kernel scope link src 192.168.178.254
local 192.168.178.254 dev eth7 table local proto kernel scope host src 192.168.178.254
broadcast 192.168.178.255 dev eth7 table local proto kernel scope link src 192.168.178.254
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101
local ::1 dev lo table local proto unspec metric 0
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
rayze schrieb:
Normal müsste es wie folgt aussehen:

- im Netz 192.168.178.0/24
Route 192.168.0.0/24 via 192.168.178.254

- im Netz 192.168.0.0/24
Route 192.168.178.0/24 via 192.168.0.2
Route 10.242.2.0/? via 192.168.0.2
Zum Vergrößern anklicken....

Diese Routen auf der UTM sowie auf dem entfernten Router haben leider nichts geändert.
 
ich habs schon im anderen thread geschrieben:

Deine Geräte müssen jeweils den Rechner als Gateway nehmen, der den VPN Tunnel bereitstellt.
Oder das andere Gateway hat eine entsprechende Route, die auf den VPN Rechner verweist.
 
ich würde gerne (natürlich nur wenn es geht) das Gateway der Geräte im entfernten Netz unverändert auf den Router des entfernten Netzes zeigen lassen.

Wie sollte die zweite Variante aussehen?
das andere Gateway bedeutet, das Standard Gateway des entfernten Netzwerkes?
Dh. im Router des entfernten Netzwerks eine Route
192.168.0.0 via 192.168.0.2
eintragen?
 
Genau, diese Route habe ich schon eine weile im entfernten Router, damit konnte ich zusätzlich zum pi den Router per ping erreichen, die weboberflache lässt sich jedoch nicht laden. Die weiteren Geräte lassen sich damit nicht erreichen
 
Zuletzt bearbeitet:
So Leute, ich hab es endlich geschafft.

wenn ich
Enable Forwarding to Reach the Internet

Enable IPv4 forwarding

sudo sysctl -w net.ipv4.ip_forward=1

Enable NAT

sudo iptables -t nat -A POSTROUTING -j MASQUERADE
Zum Vergrößern anklicken....

eingebe funktioniert es.

Quelle

Nach neustart muss ich allerdings den Befehl wieder eingeben. Dieser muss wohl noch irgendwo eingetragen werden. Das muss ich noch genau schauen. Wenn es jemand direkt weiß kann er es aber auch gerne schreiben :)
 
Mit "MASQUERADE ->( ... maskieren, der Router soll also seine eigene Adresse als Quelladresse setzen)" Nattet dein Router allerdings. Im Normalfall reicht reines Routen aus. Da dies bei dir allerdings nicht funktioniert hat gibt/gab es Problem mit den Routen oder einer Firewall. Sofern du jetzt alles erreichst wie du es vor hattest kannst du natürlich in Zukunft das ganze auch über NAT fahren.

Wie in der Quelle auch zu lesen wird NAT nur für den Zugang ins Internet daher LAN -> WAN benötigt weil du WAN-Seitig natürlich nur eine IP-Adresse hast im Gegensatz zur LAN-Seite
 
Zuletzt bearbeitet:
Hmmm, ok.
Aber als Standard ist bei dem pi ja keine Firewall aktiv, oder? Und die Firewall am Router habe ich aktuell ausgeschaltet.
Routen habe ich einige getestet, kam jedoch nie zum Erfolg.
 
So, im Autostart ist die Sache nun auch.

1. Enable IPv4 forwardingb (evtl. nicht nötig)
sudo sysctl -w net.ipv4.ip_forward=1
Zum Vergrößern anklicken....
2. Enable NAT
sudo iptables -t nat -A POSTROUTING -j MASQUERADE
Zum Vergrößern anklicken....
3. iptables speichern (um die Eingaben festhalten zu können und im Anschluss neustarten zu können)
sudo bash -c 'iptables-save > /etc/network/iptables'
Zum Vergrößern anklicken....

4. die Datei /etc/network/iptables bei einem Neustart laden

4.1 Datei "iptables" in /etc/network/if-pre-up.d mit folgendem Inhalt anlegen
#!/bin/sh
/sbin/iptables-restore /etc/network/iptables
Zum Vergrößern anklicken....
4.3 Damit das Skript ausgeführt werden kann müssen Sie die Zugriffsrechte entsprechend anpassen
sudo chmod +x /etc/network/if-pre-up.d/iptables
Zum Vergrößern anklicken....

fertig

Quelle1
Quelle2
Quelle3
 
Ist auf dem Accesspoint überhaupt ein Gateway eingetragen gewesen? :)
 
Auf welchem Accesspoint?
Auf dem entfernten Router? Der ist ja in dem entfernten Netzwerk der "Master" und alle Geräte weisen manuell auf diesen.
Dh. alle Geräte haben eine Manuelle Ip mit dem Gateway des entfernten Routers.
 
Anmelden, um zu antworten.

Ähnliche Themen

J
OpenVPN Client auf Debian: Network is unreachable bei Verbindungsaufbau
Antworten
0
Aufrufe
442
justinh999
J
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh