• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

openvpn, wie weiter ins interne Netz vom VPN Server[solved]

F

fritzbee21

Hacker
ich häng hier an nem Problem und komme einfach nicht weiter.

2 PCs bauen übers I-Net eine VPN Verbindung auf (openvpn), das funzt

der Server bekommt die 10.90.0.1 - der Client die 10.90.0.3

der Server hat 2 Netzwerkkarten, die Interne hat die IP Adresse 10.88.0.5 / 255.255.255.0
-> darf das so sein oder muss die zwangsläufig 255.0.0.0 sein ?

an der internen Netzwerkkarte hängt ein Gerät mit der 10.88.0.6, auf dieses möchte ich nun vom client aus zugreifen.

Am Client kann ich den Server pingen (ping 10.90.0.1), wenn ich die 10.88.0.5 pinge kommt nix - ich vermute weil die route fehlt - dementsprechend kann ich auch die 10.88.0.6 nicht erreichen.


per openvpn geht das komplette Subnetz 10.0.0.0 in den Tunnel (route 10.0.0.0 255.255.255.224), d.h. die Anfrage nach der 10.88.0.6 geht durch den Tunnel zur 10.90.0.1 bleibt dort aber hängen.

Nun habe ich dort mal eine Route eingetragen und zwar

route add -host 10.88.0.6 gw 10.90.0.1 dev tun0

ich dachte der host 10.88.0.6 soll über den Gateway 10.90.0.1 (VPN IP) erreichbar sein, leider funzt das aber nicht. Wenn ich diese route eintrage, kann ich direkt auf dem server die 10.88.0.6 nicht mehr anpingen. geschweige denn vom client durch den VPN Tunnel.

Wie muss denn die richtige Route für diesen Fall aussehen ?
 
S

stka

Guru
Dein routing wird so nie klappen. Wenn du soetwas machst, solltes du dich vorher etwas mit IP-Adressen, Subnetzen und routing auseinander setzen. Ließ mal das hier:
http://www.linux-club.de/viewtopic.php?t=45793&highlight=vpn
 
nbkr

nbkr

Guru
fritzbee21 schrieb:
der Server hat 2 Netzwerkkarten, die Interne hat die IP Adresse 10.88.0.5 / 255.255.255.0
-> darf das so sein oder muss die zwangsläufig 255.0.0.0 sein ?
Zum Vergrößern anklicken....

Das darf so sein.

per openvpn geht das komplette Subnetz 10.0.0.0 in den Tunnel (route 10.0.0.0 255.255.255.224), d.h. die Anfrage nach der 10.88.0.6 geht durch den Tunnel zur 10.90.0.1 bleibt dort aber hängen.
Zum Vergrößern anklicken....

Mit dem Routingkommando schickt der Client nicht alle Pakete die das Ziel 10.irgendwas in den Tunnel. Dann müsste die Subnetzmaske in dem Kommando nämlich 255.0.0.0 sein.

Nun habe ich dort mal eine Route eingetragen und zwar

route add -host 10.88.0.6 gw 10.90.0.1 dev tun0

ich dachte der host 10.88.0.6 soll über den Gateway 10.90.0.1 (VPN IP) erreichbar sein, leider funzt das aber nicht. Wenn ich diese route eintrage, kann ich direkt auf dem server die 10.88.0.6 nicht mehr anpingen. geschweige denn vom client durch den VPN Tunnel.

Wie muss denn die richtige Route für diesen Fall aussehen ?
Zum Vergrößern anklicken....

Auf dem Server musst Du im Prinzip erstmal gar kein Routen eintragen - vorausgesetzt ich hab das jetzt mit der Netzaufteilung richtig verstanden. Der Rechner bei dir ist ja an beide Netze angeschlossen. D.h. er weiß schon wo er was hinrouten muss. Du musst eigentlich nur noch das IP Forwarding aktivieren und sicherstellen das die FW nicht dazwischen funkt.
 
OP
F

fritzbee21

Hacker
so nachdem ich mich gestern Abend längere Zeit damit rumgeschlagen hatte, hab ich per Zufall ein recht gutes Wiki gefunden, was ich geschrieben habe ist wohl ziemlicher Quatsch, also nochmal neu ;-)


der Anfang bleibt so gleich

2 PCs bauen übers I-Net eine VPN Verbindung auf (openvpn), das funzt

der Server bekommt die 10.90.0.1 - der Client die 10.90.0.3

der Server hat 2 Netzwerkkarten, die Interne hat die IP Adresse 10.88.0.5 / 255.255.255.0

an der internen Netzwerkkarte hängt ein Gerät mit der 10.88.0.6, auf dieses möchte ich nun vom Client aus zugreifen.

client
Code: 
remote 82.xxx.xxx.xxx 1199
port 1199
dev tun0
proto tcp-client
ifconfig 10.90.0.3 10.90.0.1
secret static.key
keepalive 10 60
ping-timer-rem
persist-key
persist-tun
route 10.88.0.0 255.255.255.0

damit schiebe ich alles was für das Netz 10.88.0.0 kommt in den Tunnel. Der Gateway des Clients bleibt auf dem DSL Gateway (Fritzbox) zum Internetsurfen.

Der Server verwendet folgende Config

Code: 
port 1199
dev tun0
proto tcp-server
ifconfig 10.90.0.1 10.90.0.3
secret static.key
keepalive 10 60
ping-timer-rem
persist-key
persist-tun


Jetzt muss ich im Servernetz noch eine Route eintragen, damit die Packete für das Netz 10.90.0.0 auch den Weg wieder zurück finden.
Deswegen habe ich folgende Route eingetragen

Code: 
route add -net 10.90.0.0 netmask 255.255.255.0 gw 10.88.0.5

d.h. der Gateway für das Netz 10.90.0.0 ist die 10.88.0.5


Routingtabelle auf dem Server schaut folgendermassen aus

Code: 
Destination    Gateway     Genmask         Flags Metric Ref    Use Iface
10.90.0.2       *               255.255.255.255 UH    0      0        0 tun1
10.90.0.3       *               255.255.255.255 UH    0      0        0 tun0
10.90.0.0       mir.site      255.255.255.0    UG    0      0        0 eth1
10.88.0.0       *               255.255.255.0    U     0      0         0 eth1
82.xxx.xx.0    *               255.255.255.0   U     0      0         0 eth0
link-local        *               255.255.0.0       U     0      0         0 eth0
loopback        *               255.0.0.0           U     0      0         0 lo
default         gi9-1.xxx01.xxx 0.0.0.0         UG    0      0        0 eth0

Wenn ich jetzt vom Client aus pinge, erreiche ich die 10.90.0.1 (Server) und die 10.88.0.5 (interne Netzwerkkarte).
die 10.88.0.6 kann ich nicht pingen, da bekomme ich immer den Fehler:

Antwort von 10.90.0.1: Zielprotokoll ist nicht erreichbar

umgekehrt vom Server aus (10.90.0.1) kann ich die 10.90.0.3 (client) pingen. Wenn ich mich auf dem 10.88.0.6 einlogge, kann ich zwar die 10.88.0.5 und die 10.90.0.1 pingen, die 10.90.0.3 (die andere Seite des Tunnels erreiche ich aber nicht).
Ich weis jetzt nicht wo der Fehler sein soll, denn eigentlich sollte ja alles richtig sein oder ?

auf dem Windows Client schaut die Routingtabelle so aus:

Code: 
Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
0.0.0.0             0.0.0.0                   82.xxx.xx.1    82.xxx.xx.5      20
10.88.0.0         255.255.255.0         10.90.0.1       10.90.0.2       1
10.90.0.0         255.255.255.252     10.90.0.2       10.90.0.2       30
10.90.0.2         255.255.255.255     127.0.0.1       127.0.0.1       30

Testweise habe ich mal die FW auf dem Server ausgeschaltet, bringt aber auch nichts, nur bekomme ich dann beim Ping von 10.88.0.6 nen Timeout und keinen Protokollfehler mehr.

Ob mit Linux Client oder Windows Client, geht beides nicht.

Der Server fungiert auch als Router vom internen Netz ins I-Net, d.h. IP Weiterleitung ist aktiviert.
 
nbkr

nbkr

Guru
10.90.0.0 mir.site 255.255.255.0 UG 0 0 0 eth1
Zum Vergrößern anklicken....

Das kann nicht stimmen. Der Server darf die Pakete für den Tunnel nicht über die physikalische Netzwerkkarte schicken. Lösch die Route am besten mal ganz vom Server. Sind ja noch die Hostrouten für die beiden anderen VPNs da.
 
OP
F

fritzbee21

Hacker
ok die route ist raus:

aktuell

Destination Gateway Genmask Flags Metric Ref Use Iface
10.90.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.88.0.0 * 255.255.255.0 U 0 0 0 eth1
82.xxx.xx.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default gi9-1.xxr01.xxx 0.0.0.0 UG 0 0 0 eth0


hm nur Änderung bringt mir das Keine, es geht weder von der einen Richtung zur anderen noch zurück.
 
OP
F

fritzbee21

Hacker
suse Firewall Punkt 23:

"yes"


und schon gehts, auch ohne routen im server einzutragen.

Dummerweise stand das in keinem WIKI
 
OP
F

fritzbee21

Hacker
Code: 
# 23.)
# Allow same class routing per default?
# REQUIRES: FW_ROUTE
#
# Do you want to allow routing between interfaces of the same class
# (e.g. between all internet interfaces, or all internal network interfaces)
# be default (so without the need setting up FW_FORWARD definitions)?
#
# Choice: "yes" or "no", if not set defaults to "no"
#
# Defaults to "no" if not set
#
FW_ALLOW_CLASS_ROUTING="yes"
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben