Routing-Problem und VPN

[za0]

Hallo Debiangemeinde,

ich bitte Euch um Hilfestellung. Meine aufgesetzte VPN-Verbindung funktioniert im prinzip, jedoch komme ich nicht mit dem Client aus meinem Netz an die Clients hinter dem VPN Gateway (also ins LAN auf der Gegenseite). Das VPN-Gateway ist nicht das Netzwerkgateway (bzw. -router).

Struktur:

LAN Vorort
192.168.2.x

Entferntes LAN
Router IP: 192.168.11.1
Clients im LAN 192.168.11.x
VPN-Gateway VPN IP: 10.8.0.1; LAN IP:192.168.11.200

Ich verwende VPN im routing Modus, nicht bridge.

Hier die Konfigurationsdateien:
client.conf

client

dev tun

proto tcp

remote myvpn.server.xxl 2222

resolv-retry infinite

nobind

user openvpn
group openvpn

persist-key
persist-tun

ca ca.crt
cert client.crt
key client.key
dh dh1024.pem

ns-cert-type server

cipher DES-EDE3-CBC

comp-lzo

verb 3

Server: rc.local:

#!/bin/sh -e
#
# rc.local

route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.11.200
exit 0

server.conf

port 2222

proto tcp

dev tun

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.11.0 255.255.255.0"

# 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

keepalive 30 180

cipher DES-EDE3-CBC # Triple-DES

comp-lzo

max-clients 10

user openvpn
group openvpn

persist-key
persist-tun

status openvpn-status.log

verb 6

Bei der Option "client-to-client" bin ich mir nicht ganz sicher. Laut DOKU braucht man diese nur, wenn man andere Clients aus dem Netzwerk des Clients mit den Clients im LAN des Servers anknüpfen will. Ich habe es eben MIT ausprobiert. Es funktioniert immer noch nicht.

Hier das Routing (Server):

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.0 192.168.11.200 255.255.255.0 UG 0 0 0 eth0
192.168.11.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.11.1 0.0.0.0 UG 100 0 0 eth0

Hier das Routing (Client):

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.5 * 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.11.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
default 192.168.2.1 0.0.0.0 UG 0 0 0 eth0

Ich danke Euch.

[roli]

Hi,

Hier das Routing (Server):

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.0 192.168.11.200 255.255.255.0 UG 0 0 0 eth0

ohne es mir jetzt alles genau ansehen zu koennen stoert mich der doppelte Routingeintrag für dein 10.8'er Netz auf dem Server. Der zweite Eintrag kommt mir falsch vor.

[DynaBlaster]

Bei der Option "client-to-client" bin ich mir nicht ganz sicher

Diese Option ist dafür da, dass der VPN-Server eine Kommunikation der VPN-Clients untereinander ermöglicht. Dies betrifft also nur den Fall, wenn sich ein weiterer VPN-Client mit dem Server verbindet und sich dann 10.8.0.x und 10.8.0.y miteinander unterghalten können sollen. Für dein Szenario ist diese Option irrelevant.

In deinem Szenario fehlt dir schlicht die "Rück-Route" von 192.168.11.0/24 nach 192.168.2.0/24. Du hast zwar die entsprechende Route für den VPN-Client eingerichtet, aber ein x-beliebiger Client im LAN 192.168.11.0/24 weiss nicht, wie er auf Anfragen aus dem Netz 192.168.2.0/24 antworten soll, da sein Standard-GW auf 192.168.11.1 zeigt. Entweder du legst im Router 192.168.11.1 eine statische Route ins Netz 192.168.2.0/24 über 192.168.11.200 fest, oder du konfigurierst die entsprechende Route auf jedem Client in 192.168.11.0/24 manuell, oder du trägst bei allen Clients 192.168.11.200 als Standard-GW ein. Die letzte Möglichkeit wäre dann noch NAT mittels iptables und SNAT/MASQUERADE auf dem OpenVPN-Server, um den Clients in 192.168.11.0/24 vorzugaukeln, die Pakete aus 192.168.2.0/24 kämen von 192.168.11.200.

Das einfachste und schnellste ist definitiv das Eintragen der statischen Route auf dem DSL-Router 192.168.1.1.. Wenn es nicht anders geht durchsuch mal das Forum, da habe ich mehrfach entsprechende SNAT-Regeln gepostet.

Nachtrag: @ roli

Das liegt an der Zeile hier:

Code: Alles auswählen

#!/bin/sh -e
#
# rc.local
route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.11.200
exit 0

Und tatsächlich, der Eintrag ist tatsächlich überflüssig und erzeugt schlimmstenfalls eine Schleife.

[Duff]

Hatte das selbe Problem (und DynaBlaster hatte mir auch dort schon sehr gute Tipps gegeben) und habe es mit einer Rückroute auf dem Router gelöst.

[za0]

Hi Dynablaster, hi roli, hi Duff

erstmal vielen Dank für Eure Hilfe.

In deinem Szenario fehlt dir schlicht die "Rück-Route" von 192.168.11.0/24 nach 192.168.2.0/24. Du hast zwar die entsprechende Route für den VPN-Client eingerichtet, aber ein x-beliebiger Client im LAN 192.168.11.0/24 weiss nicht, wie er auf Anfragen aus dem Netz 192.168.2.0/24 antworten soll, da sein Standard-GW auf 192.168.11.1 zeigt. Entweder du legst im Router 192.168.11.1 eine statische Route ins Netz 192.168.2.0/24 über 192.168.11.200 fest, oder du konfigurierst die entsprechende Route auf jedem Client in 192.168.11.0/24 manuell, oder du trägst bei allen Clients 192.168.11.200 als Standard-GW ein. Die letzte Möglichkeit wäre dann noch NAT mittels iptables und SNAT/MASQUERADE auf dem OpenVPN-Server, um den Clients in 192.168.11.0/24 vorzugaukeln, die Pakete aus 192.168.2.0/24 kämen von 192.168.11.200.

Jetzt verstehe ich, warum es besser wäre, wenn WAN-Gateway/Router==VPN-Gateway. Wenn ich die Default Gateway auf den Rechnern ändere, dann kommen die nicht mehr ins WAN.

Ok, ich suche mal im Forum.

Danke nochmals.

EDIT: Die statische Route auf dem Router funktioniert leider nicht (Warum?). Destination Lan IP ist die 192.168.2.0/24, Netmask 255.255.255.0 Gateway 192.168.11.200 - oder bin ich jetzt ganz jeck geworden?

Scheinbar bleibt nur Vorschlag 3 : NAT/MASQUERADE.

[za0]

Habe jetzt

Code: Alles auswählen

iptables -t nat -A PREROUTING -s 10.0.8.0/24 -j DNAT --to 192.168.1.98

eingegeben. Pingen funktioniert. Aber ich habe zu spät gelesen, dass DAS Unfug sein soll.

Wie kriege ich das wieder raus?

EDIT: So habe die Route auf dem Router gesetzt und es funktioniert immer noch nicht.
10.8.0.0; 255.255.255.0; 192.168.11.200 .

[Duff]

Benutze bei mir auf dem Server u.a. folgendes Skript, um erstmals alle Regeln zu löschen, bevor ich sie dann neu anlege.

Code: Alles auswählen

#!/bin/bash
# /etc/mysysconfig/iptables_reset.sh
IPT=$(which iptables)

[ -z $IPT ] && (echo "iptables cannot be found!";exit)

# erstmal alles aktzeptieren
$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P POSTROUTING ACCEPT -t nat
$IPT -P PREROUTING ACCEPT -t nat
$IPT -P OUTPUT ACCEPT -t nat

# alle Regeln löschen
$IPT -F
$IPT -F -t nat

# alle benutzerdefinierten Regelketten löschen
$IPT -X

# kein IP-Forwarding (d.h. auch kein Masquerading)
#echo "0" > /proc/sys/net/ipv4/ip_forward
# IP-Forwarding enabled
echo "1" > /proc/sys/net/ipv4/ip_forward

Was für einen Router benutzt du denn?
Eventuell eine Fritzbox?

Du musst als Route dort das Netz vom VPN anlegen.

[DynaBlaster]

Wahrscheinlich ist ip_forward auf dem OpenVPN-Server ausgeschaltet. Wenn

Code: Alles auswählen

cat /proc/sys/net/ipv4/ip_forward

den Wert "0" anzeigt, dann musst du Forwarding aktivieren. Entweder den entsprechenden Teil in /etc/sysctl.conf aktivieren oder mittels

Code: Alles auswählen

echo "1" > /proc/sys/net/ipv4/ip_forward

aktivieren.

[DynaBlaster]

Wie kriege ich das wieder raus?

Code: Alles auswählen

iptables -t nat -D PREROUTING -s 10.0.8.0/24 -j DNAT --to 192.168.1.98

@ Duff

Du musst als Route dort das Netz vom VPN anlegen

Dann fehlt ihm aber immer noch die Route ins Netz 192.168.2.0/24. Wie gesagt, wahrscheinlich fehlt einfach nur das "Forwarding"

[Duff]

Mit dem kurzen und übersichtlichen iptables-Skript zum Löschen aller vorhandenen Routen aktiviere ich bei mir auch das Forwarding auf dem Server (siehe vorherigen Post von mir).

[za0]

Benutze bei mir auf dem Server u.a. folgendes Skript, um erstmals alle Regeln zu löschen, bevor ich sie dann neu anlege.


Was für einen Router benutzt du denn?
Eventuell eine Fritzbox?

Du musst als Route dort das Netz vom VPN anlegen.

Ich habe nen Linksys wrt54g3 oder so mit GPRM und UMTS.
Ich habe angeben: Destination LAN 10.8.0.0 ; 255.255.255.0 ; Gateway 192.168.11.200 (VPNServ)

[za0]

Wahrscheinlich ist ip_forward auf dem OpenVPN-Server ausgeschaltet. Wenn

Code: Alles auswählen

cat /proc/sys/net/ipv4/ip_forward

den Wert "0" anzeigt, dann musst du Forwarding aktivieren. Entweder den entsprechenden Teil in /etc/sysctl.conf aktivieren oder mittels

Code: Alles auswählen

echo "1" > /proc/sys/net/ipv4/ip_forward

aktivieren.

Ist aktiviert (beim Boot).

[za0]

Wie kriege ich das wieder raus?

Code: Alles auswählen

iptables -t nat -D PREROUTING -s 10.0.8.0/24 -j DNAT --to 192.168.1.98

@ Duff

Du musst als Route dort das Netz vom VPN anlegen

Dann fehlt ihm aber immer noch die Route ins Netz 192.168.2.0/24. Wie gesagt, wahrscheinlich fehlt einfach nur das "Forwarding"

Ja das Postrouting war gemeint.

Naja ich versuche nochmal die Backroute einzutragen.

[za0]

Hi,

ich hab' den Spass jetzt nochmal mit Bridging probiert - funktioniert auch nicht. Das ist echt nicht zu glauben ...
Jetzt sagt der hier

From 192.168.11.100 icmp_seq=2 Destination Host Unreachable

Ist denn jetzt auch schon beim Bridging Routing erforderlich?

Hah - ich kann nicht einmal mehr die VPN-Gateway anpingen im "bridge mode". Ist ja echt klasse!

[DynaBlaster]

Ich habe das Gefühl, dass wir durch die Ganze Rumprobiererei nicht mehr wissen, wo vorne und hinten ist. Ich würde deshalb vorschlagen, dass wir von deinem Anfangsposting ausgehen und dann noch einmal strukturiert von vorne anfangen.

Struktur:

LAN Vorort
192.168.2.x

Entferntes LAN
Router IP: 192.168.11.1
Clients im LAN 192.168.11.x
VPN-Gateway VPN IP: 10.8.0.1; LAN IP:192.168.11.200

Ich verwende VPN im routing Modus, nicht bridge.

Wie roli im ersten Antwortpost bereits beschrieben hat kann der Eintrag in rc.local auf dem Server zu Problemen führen. Überflüssig ist er allemal.

Wenn sich jetzt ein Client aus "LAN Vorort", meinetwegen 192.168.2.2, mit dem VPN-Gateway in "LAN Entfernt" verbindet, dann erhält nach deiner Konfiguration dieser Client eine weitere Schnittstelle tun0 mit der IP 10.8.0.x. Durch das "push-route"-Kommando auf dem Server sollte bei diesem Client zeitgleich eine zusätzliche Route für das Netz 192.168.11.0/24 über diese neue tun0-Schnittstelle erstellt werden.
Was jetzt auf jeden klappen sollte ist ein Ping von 192.168.2.2 auf 10.8.0.1. Ebenfalls ohne weitere Konfiguration muss ein ping von 192.168.2.2 auf 192.168.11.200 klappen. Erst wenn das soweit klappt, sollten wir uns um das Forwarding und die zusätzlichen Routen kümmern.

Der nächste Schritt wäre nun die Aktivierung von ip_forward auf dem Server 192.168.11.200 (siehe oben). Dann musst du auf dem Router 192.168.11.1 eine statische Route für 192.168.2.0/24 über 192.168.11.200 einrichten. Jetzt sollte eigentlich ein ping von 192.168.2.2 auf 192.168.11.1 klappen.

Wenn das nicht der Fall sein sollte, poste bitte nochmals die Ausgabe von "route -n" vom Server und Client, nachdem die o.g. Schritte ausgeführt hast.

PS: Ich gehe jetzt mal davon aus, dass bei deinen Tests kein Firewall aktiv ist - das könnte nämlich auch dazwischenfunken ...

[za0]

Hi Dynablaster,

sorry, ich war mit anderen Dingen beschäftigt. Nach 12h-VPN-Fehlersuche hat mir der kleine VPN-Urlaub auch gut getan .
Übrigends bin ich Dir sehr dankbar für Deine Hilfsbereitschaft. Mein Dank geht ebenfalls an Duff.

So, zu Deinem Posting: Ja, wir sollten uns ums Routing kümmern. Die Pings - wie Du es formuliert hast - funktionieren.
IPForwarding ist auch schon aktiviert (permanent). Ich habe jetzt mal einen Ubuntu Server 8.04 installiert und die Installation wiederholt. Dabei habe ich die alten Configs verwendet.

Dann musst du auf dem Router 192.168.11.1 eine statische Route für 192.168.2.0/24 über 192.168.11.200 einrichten. Jetzt sollte eigentlich ein ping von 192.168.2.2 auf 192.168.11.1 klappen.

Das ist gerade DAS, was nicht funktioniert. Der Router ist ein WRT54G3G von Linksys. Ich werde diesen Router bald in die Tonne kloppen (siehe auch https://www.debianforum.de/forum/viewto ... 0&t=103344). Ich denke, dass das bis dahin auch nicht funktionieren wird, weil der Router es einfach nicht zulässt.

Das Posting von "route -n" werde ich später machen. Das geht gerade nicht.

[za0]

Ein Client in meinem Netzwerk:

Code: Alles auswählen

Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.11.0    10.8.0.5        255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.2.250   0.0.0.0         UG    0      0        0 eth0

Das VPN-Gateway im anderen Netz:

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.11.1    0.0.0.0         UG    100    0        0 eth0

Auf dem linksys sieht die routing-Tab so aus:

Code: Alles auswählen

Destination LAN IP      Subnet Mask      Gateway      Interface
xxxxxx    255.255.255.255    0.0.0.0    WAN (Internet)
192.168.2.0    255.255.255.0    192.168.11.200    LAN & Wireless
192.168.11.0    255.255.255.0    0.0.0.0    LAN & Wireless
0.0.0.0    0.0.0.0    xxxxxx    WAN (Internet)

Wie gesagt, ich kann zwar vom Client aus die VPN-Gateway einmal über die 10er udn einmal über die 192er IP anpingen, aber die Clients, die sich hinter dem VPN-Gateway befinden - nada

EDIT: Firewall auf dem VPN gateway: iptables -L zeigt überhaupt nichts an.

[DynaBlaster]

Manchmal sieht man den Wald vor lauter Bäumen nicht

Auf dem VPN-Gateway fehlt noch die Route für das Netz 192.168.2.0/24 über die tun0-IP des Clients in deinem Netzwerk. Sonst weiss das VPN-Gateway nicht, das hinter der IP 10.0.8.4 (???) das Netz 192.168.2.0/24 liegt.

Einige Routing-Einträge sehen etwas komisch aus. IMHO müsste die Ausgabe des Cleints in deinem Netzwerk in etwa so aussehen:

Code: Alles auswählen

Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.11.0    10.8.0.1        255.255.255.0   UG    0      0        0 tun0 !!!!
0.0.0.0         192.168.2.250   0.0.0.0         UG    0      0        0 eth0

Bei entsprechendem Routing-Eintrag auf dem VPN-Gateway sollte das dann in etwa so aussehen:

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.2.0    10.8.0.5        255.255.255.0   UG    0      0        0 tun0 !!!
0.0.0.0         192.168.11.1    0.0.0.0         UG    100    0        0 eth0

Bei "192.168.2.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0" bin ich mir nicht zu 100% sicher. Ich würde mittels "ifconfig -a" die "richtige" IP-Adresse des tun0-Devices des VPN-Clients in deinem Netzwerk checken und diese dann verwenden. OpenVPN arbeitet intern irgendwie mit Punkt-zu-Punkt-Verbindungen. Deshalb beansprucht das VPN-Gateway auch für sein tun0-Device 10.0.8.1 und 10.0.8.2. Der erste Client nutzt dann irgendwie 10.0.8.3 und 10.0.8.4, usw.. Das ist aber gefährliches Halbwissen meinerseits und ich habe mich da nicht weitergehend mit beschäftigt ....