OpenVPN Client IP Problem

Hallo,

ich habe OpenVPN nach der Anleitung von Jan Karres installiert http://jankarres.de/2013/05/raspbe…r-installieren/ .

Raspberry IP: 192.168.178.31

OpenVPN Client IP: 10.8.0.6

Soweit läuft alles, jedoch habe ich folgendes Problem:

Bin ich per OpenVPN eingewählt und bewege ich in meinem HausLAN, bin ich mit der IP des Raspberry "unterwegs" und nicht mit der OpenVPN-Client IP.
Also greife ich beispielsweise auf das Webinterface meiner Fritzbox zu wird angezeigt, dass sich die IP 192.168.178.31 (Raspberry) verbunden hat - hier sollte aber 10.8.0.6 stehen.

Woran kann das liegen bzw. wie bekomme ich es dahingehend geändert, dass die wirkliche Client-IP nach aussen (also ins HausLAN) geht?

Serverconfig:

dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0"
persist-key
persist-tun
status /var/log/openvpn-udp-status.log
verb 3
client-to-client
push "redirect-gateway def1 bypass-dhcp"
#set the dns servers
push "dhcp-option DNS 192.168.178.1"
#push "dhcp-option DNS 8.8.8.8"
#push "dhcp-option DNS 8.8.4.4"
log-append /var/log/openvpn
comp-lzo
duplicate-cn
keepalive 10 120

Client:

dev tun
client
proto udp
remote xxxxxxx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca "c:\\temp\\ovpn\\homevpn\\RaspberryPI\\ca.crt"
cert "c:\\temp\\ovpn\\homevpn\\RaspberryPI\\client1.crt"
key "c:\\temp\\ovpn\\homevpn\\RaspberryPI\\client1.key"
comp-lzo
verb 3

Danke für jeden Tip.

Quote from rpi444

Deine Informationen sind etwas unklar und nicht ausreichend. Warum ist für die das HausLAN schon aussen? Von welchem VPN-Client machst Du die Verbindung per VPN ins HausLAN bzw. wo befindet sich dieser VPN-Client?

Ja das ist die Frage - keine Ahnung, warum er das HausLAN als "aussen" betrachtet.

Also: Der VPN-Client ist mein Smartphone. Ich wähle mich vom Smartphone aus (via Mobilfunknetz) per OpenVPN-Client auf dem Raspberry ein.
Ping vom Smartphone aus wüsste ich jetzt nicht wie, gibt es noch eine andere Möglichkeit zum Testen ?

Ich vermute mal, es hängt damit zusammen (aus der Anleitung von Jan Karres):

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

[font="Monaco, Andale Mono, Courier New, Courier, monospace"]Im Endeffekt wird doch damit alles, was aus dem 10.8'er Netz kommt und über die Schnittstelle wieder raus geht maskiert, oder ? Also auch ins interne LAN..oder verstehe ich das falsch?[/font]

[font="Monaco, Andale Mono, Courier New, Courier, monospace"]Wenn dem so ist bräuchte ich eine Einstellung, welche nur Pakete die ins Internet gehen maskiert.[/font]
Automatisch zusammengefügt:
Nachtrag: Hier die gewünschten Infos:

pi@raspberrypi ~ $ ip r
default via 192.168.178.1 dev wlan0  metric 303
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.31  metric 303
pi@raspberrypi ~ $ sudo iptables -nvx -L -t nat
Chain PREROUTING (policy ACCEPT 76899 packets, 10466848 bytes)
   pkts      bytes target     prot opt in     out     source               destination


Chain INPUT (policy ACCEPT 29008 packets, 1914179 bytes)
   pkts      bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 31889 packets, 2237192 bytes)
   pkts      bytes target     prot opt in     out     source               destination


Chain POSTROUTING (policy ACCEPT 32489 packets, 2273272 bytes)
   pkts      bytes target     prot opt in     out     source               destination
    665    56202 MASQUERADE  all  --  *      wlan0   10.8.0.0/24          0.0.0.0/0

Quote from rpi444

Das verstehst Du schon richtig, denn die IP-Adresse 192.168.178.31 (dein PI) ist das gateway aus dem VPN ins Subnetz 192.168.178.0/24 (LAN des PI) und das ist auch OK so.

Warum hast Du ein Problem damit, welche IP-Adresse von den Geräten im LAN des PI, von diesen als source-IP gesehen wird, wenn die Anfrage/Verbindung zu diesen Geräten durch das VPN kommt?

Ich brauche die tatsächlichen Client-IPs (10.x) im LAN, momentan kommen alle mit der IP des PI daher.

Das 10er Netz sollte also sozusagen geroutet und nicht maskiert werden, maskierung soll nur ins Internet stattfinden.

Das ist die Frage, wie ich das hinbekommen kann.

Quote from rpi444

Im LAN oder auf den einzelnen Geräten im LAN des PI? ... denn im LAN hast Du die ja, der PI (als gateway) kennt ja die einzelne VPN-IP der Clients.

BTW: Kannst Du uns evtl. verraten, warum die Geräte im LAN des PI, die VPN-IP der VPN-Clients brauchen? Evtl. gibt es alternative Lösungen?

Die Frage verstehe ich nicht ganz. Ja, der PI kennt die IPs der VPN-Clients, aber im LAN kommen die Geräte alle mit der IP des PI daher - und genau das möchte ich nicht.

Ich brauche die IPs für verschiedene Anwendungen bzw. Szenarien, in welchen eben einzelne Geräte identifizierbar sein müssen (u.a. für meine Hausautomation)

Das maskieren intern im LAN finde ich davon abgesehen auch einfach unnötig/unschön. Allein schon am Beispiel der Fritzbox. Verbindet man sich von Smartphone1, Tablet2 oder Laptop3 auf das Fritzbox-Webinterface, sieht man immer nur, dass der Zugriff von 192.168.178.31 (PI) erfolgte. Der Zugriff ist somit nicht einem einzelnen Gerät/Benutzer zuzuordnen.

Ich hätte daher wirklich gerne die "Routing"-Lösung, keine Alternative.

Hm...also ich hoffe ich habe mein Vorhaben verständlich ausgedrückt...? Wenn noch infos benötigt werden, bitte bescheid sagen...

Ich fasse es vielleicht nochmal zusammen.

Ich habe auf dem PI nur ein Interface (wlan0) und eben die virtuellen Interfaces von OpenVPN.
Ich möchte, dass der Traffic des OpenVPN-Subnets (10.8.x) NUR für ausgehenden Internettraffic maskiert wird. Für internen LAN-Traffic (Ziel = 192.168.x) soll KEINE Maskierung stattfinden, sondern einfach durchgeroutet werden.

Im Endeffekt bräuchte ich etwas wie (siehe ** am Ende)

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o wlan0 -j MASQUERADE **EXCEPT 192.168.178.0/24

Das muss doch irgendwie gehen? Für Hilfe wäre ich echt dankbar.

Quote from rpi444

Wenn keine "Maskierung" stattfinden soll, wie können deiner Meinung nach, die Datenpakete (aus dem LAN) dann den Rückweg ins VPN (wieder) finden?

Durch ganz normales Routing. Alle Clients im LAN haben die Fritzbox als Gateway. In der Fritzbox ist eine statische IPV4-Route angelegt:

Ziel: 10.8.0.0/24 GW 192.168.178.31 (PI)

Der Rückweg wäre also bekannt. Nur bekomme ich das halt auf dem PI nicht hin, dass er einfach nur ins LAN routet anstatt zu "natten" oder zu "maskieren" (bin mir nicht sicher was jetzt der richtige Begriff dafür ist, sorry wenn ich da evt. was durcheinander bringe)

Quote

EDIT:

Evtl. wäre OpenVPN mit Ethernet bridge (TAP), das Richtige für deine Konstellation/Bedürfnisse?

Leider benötige ich zwingend TUN, da TAP auf einem nicht-gerootetem Android-Smartphone nicht funktioniert.

EDIT: Nur zur Info bzw. Vollständigkeit - ich hatte vorher meinen OpenVPN Server auf der Fritzbox selbst laufen (mit Freetz). Da hat es genauso out-of-the-box funktioniert wie von mir gewünscht. Alle VPN-Clients kamen mit ihrer 10er IP ins interne LAN und wurden nur ins Internet genattet. Extra einstellen musste ich dafür nichts. Das hätte ich halt jetzt gerne genau so auf dem PI, da ich es auf der Fritzbox nicht mehr laufen lassen kann.

Quote from rpi444

Die Geräte im LAN des PI werden Antworten auf Anfragen/Verbindungen aus dem VPN, nicht an ihr default gateway (die FritzBox) senden. D. H., die statische Route in der FB ist wirkungslos.

Das stimmt nicht. Anfragen in Netze ausserhalb des eigenen gehen doch meines Wissens nach immer an default gateway, sofern keine statische Route auf dem selbigen Gerät definiert ist.
Ich kann es ganz einfach mit einem tracert von einem Windows-PC aus nachstellen ..

C:\windows\system32>tracert 10.8.0.6


Routenverfolgung zu 10.8.0.6 über maximal 30 Abschnitte


  1     9 ms     5 ms     7 ms  192.168.178.31
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.

Dieser Windows-PC hat selbst keinerlei Route für 10.8.x eingetragen, er schickt die Anfrage ans Gateway (Fritzbox) und hier zieht die eingetragene, statische Route.

Die restlichen Vorschläge die Du gemacht hast kann ich irgendwie nicht nachvollziehen.

Nochmal zum Gegenseitigen Verständnis:

- Der PI hat nur eine Schnittstelle (wlan0). Der PI hat die IP 192.168.178.31.

- Die Fritzbox hat 192.168.178.1

- Alle Geräte im LAN haben 192.168.178.x und als Gateway die Fritzbox (192.168.178.1)

- Auf der Fritzbox ist eine statische Route ins 10.8.x Netz hinterlegt

- Auf dem PI ist noch die MASQUERADE Regel für das 10.8.x Netz angelegt, keine statische Route

Soweit ich Dich jetzt verstanden habe, könnte ich jetzt die MASQUERADE Regel entfernen und eine statische Route auf dem PI für das 192.168.178.x Netz anlegen.

Wenn das funktioniert, verliere ich damit aber den Internetzugriff für die VPN-Clients ... ?

Ein weiteres Problem scheint zu sein (am Beispiel oben zu sehen) - der Rückweg aus dem 192.168.178.x Netz ins 10.8.0.x Netz ist zwar bekannt, aber die Anfragen gehen nicht durch. Hier blockt wahrscheinlich noch die Firewall des PI die Anfragen aus dem 192.168.178.x Netz ?
Umgekehrt geht es... VOM VPN-Client aus kann ich einen PC im 192.168.178.x Netz anpingen. Umgekehrt geht es nicht.

Puh...ja und nach wie vor stehe ich halt vor dem Problem - es braucht NAT bzw. MASQUERADE für den Internetzugriff der VPN-Clients UND statisches Routing fürs interne LAN (192.168.178.x)

Anders wird es nicht gehen. Die Frage ist nur, wie...und ob das mit einer einzigen Schnittstelle auf dem PI überhaupt machbar ist. Aber eigentlich müsste das gehen, als der OpenVPN Server noch auf der Fritzbox lief ging es ja auch..wie auch immer..

Zwischendurch mal ein "Danke!" für deine Mühe und das Du noch dabei bist.

Quote from rpi444

Doch das stimmt, denn ich habe das testet, mit Linux-Geräten auf denen ich tcpdump gestartet habe.

Das ist die Theorie, die wie man mit tcpdump sehen kann, hier nicht für das Subnetz 10.8.0.0/24 (oder gleichwertig) gilt.

Wie bzw. wo erkennst Du, dass der Windows-PC die Anfrage/Antwort, über seine default route an die FritzBox (gateway) sendet? Evtl. mal Wireshark auf dem Windows-PC laufen lassen.

Falsch, denn für die Tests mit dem Routing, ist die MASQUERADE-Regel fehl am Platz. D. h. sie wird nicht benötigt bzw. stört.

Nein, ... wo habe ich das geschrieben, mit der statischen Route auf dem PI für das Netz 192.168.178.x?

Ich habe geschrieben, dass Du auf den Geräten im LAN des PI (... d. h. die Geräte die Du per VPN über den PI erreichen willst) eine definierte Route in das Netz 10.8.0.0/24 mit dem PI oder mit der FritzBox als gateway, konfigurieren sollst/kannst.

Display More

Also sorry aber Du bist da einfach falsch informiert. Natürlich gehen Pakete, die an ein entferntes Netz adressiert sind IMMER an das Standardgateway, es sei denn, es ist eine statische Route definiert die anderes vorgibt. Das sind Grundlagen von TCP/IP ...

Ich glaube, wir beide kommen hier nicht weiter. Trotzdem danke.

Wenn noch jemand anderes was dazu sagen könnte, würde ich mich freuen.

Gesendet von meinem GT-I9305 mit Tapatalk

Quote from rpi444

Ja, aber 10.8.0.0/24 ist kein "entferntes" Netz. Das hat mit (nicht) informiert sein nicht zu tun, ich habe es getestet.
Z. B.:

Code

~ $ sudo tcpdump -vvveni eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:41:22.339450 00:1b:77:40:ca:3b > b8:27:eb:11:42:30, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 11494, offset 0, flags [DF], proto ICMP (1), length 84)
   10.8.0.1 > 192.168.178.24: ICMP echo request, id 15064, seq 1, length 64
13:41:23.333106 00:1b:77:40:ca:3b > b8:27:eb:11:42:30, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 11567, offset 0, flags [DF], proto ICMP (1), length 84)
   10.8.0.1 > 192.168.178.24: ICMP echo request, id 15064, seq 2, length 64
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Kannst Du mir sagen warum die Antwort (echo reply) auf den Ping (der mit der source-IP 10.8.0.1 aus dem VPN kommt), hier nicht an die FritzBox (default gateway) geleitet wird? ,,, obwohl in diesem Gerät (mit der IP 192.168.178.24) die routing-Tabelle so aussieht:

Code

~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

Willst Du jetzt ernsthaft behaupten, dass 10.8.0.x für einen Rechner, der sich in 192.168.178.x befindet kein entferntes Netz ist? Ernsthaft?

Keine Ahnung was Du da treibst, aber
as Du da sonst schreibst hat nichts mehr mit meinem Problem zu tun.

Sorry,aber Du kannst mir nicht helfen und wir können die Diskussion hier beenden.

Gesendet von meinem GT-I9305 mit Tapatalk

Quote from rpi444

Teste mal selber wenn Du es nicht glaubst. Das ist die identische Konstellation wie Du sie auch hast. Ich schreibe nur das, was ich bei den Ergebnissen des Tests festgestellt habe.

Du hast offenbar weder mein Anliegen verstanden, noch grundlegende Kenntnisse von TCP/IP. Das macht weitere Diskussionen hier sinnlos. Ich meins nicht böse, aber Du kannst mir nicht helfen. Ich bin aus der Diskussion mit Dir raus.

Falls noch jemand anderes den Thread entdeckt und etwas sinnvolles beitragen kann - bitte melden.

Gesendet von meinem GT-I9305 mit Tapatalk

Quote from rpi444

Die Formulierungen bzw. die Wortwahl in deinen letzten Beiträgen zeigt, dass Du von dieser Materie leider keine Ahnung hast, oder Du hast deinen "Fehler" längst erkannt und deshalb reagierst leider so (... um abzulenken).

Ist das ein Witz oder trollst Du einfach gerne? Unglaublich...ich befürchte, Du meinst das tatsächlich ernst xD

Jetzt muss ich doch echt mal kucken, ob es hier eine Ignore-Funktion gibt.

Gesendet von meinem GT-I9305 mit Tapatalk