PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenVPN - Denkfehler?



iscariot
30.11.10, 21:20
Hallo Gemeinde! :)

Ich kaempfe zur Zeit ein wenig mit OpenVPN, Zertifikaten und mehreren Clients. Hab hier ein kleines Netz mit Maske (255.255.255.0) zu Hause, das etwa so aussieht:
192.168.42.1 Speedport von der Telekom und momentan Default GW
192.168.42.2 eth0 vom Fileserver
192.168.42.3 eth1 vom Fileserver
192.168.42.4 Erster Client
...
192.168.42.8 Letzter Client
192.168.42.130-150 Virtuelle Maschinen auf 192.168.42.2
Alles ist mit allem ueber einen Switch erreichbar (Ja, ich weiss, dass das grauselig ist...)

Port 1194 wird vom Speedport an 192.168.42.2 weitergeleitet. Das klappt auch alles wunderbar. Auf dieser Maschine soll auch die Verbindung in mein Netz stattfinden. Ich will mich mit meinem Laptop, Handy, Firmenrechner, bei meinem Vater, etc... mit dem VPN verbinden.

Momentan sieht meine Konfiguration so aus und ich vermute, dass mein Problem bei den zwei Zeilen in Fettschrift liegt:

port 1194
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
server 192.168.42.0 255.255.255.0
push "route 192.168.42.0 255.255.255.255.0"
status openvpn-status.log
verb 3

tun0 nimmt sich automatisch 192.168.42.1 als IP-Adresse, was aber bereits die IP-Adresse von meinem Router ist. Kann man das irgendwie aendern oder hab' ich irgendein Konzept gerade nicht begriffen?

Natuerlich bekomme ich im Syslog auch eine Fehlermeldung:

Nov 30 12:11:07 helios ovpn-openvpn[19023]: WARNING: potential TUN/TAP adapter subnet conflict between local LAN [192.168.42.0/255.255.255.0] and remote VPN [192.168.42.1/255.255.255.255]
Nov 30 12:11:07 helios ovpn-openvpn[19023]: ROUTE default_gateway=192.168.42.1
Nov 30 12:11:07 helios kernel: tun0: Disabled Privacy Extensions
Nov 30 12:11:07 helios ovpn-openvpn[19023]: TUN/TAP device tun0 opened
Nov 30 12:11:07 helios ovpn-openvpn[19023]: TUN/TAP TX queue length set to 100
Nov 30 12:11:07 helios ovpn-openvpn[19023]: /sbin/ifconfig tun0 192.168.42.1 pointopoint 192.168.42.2 mtu 1500
Nov 30 12:11:07 helios ovpn-openvpn[19023]: WARNING: potential route subnet conflict between local LAN [192.168.42.0/255.255.255.0] and remote VPN [192.168.42.0/255.255.255.0]
Nov 30 12:11:07 helios ovpn-openvpn[19023]: /sbin/route add -net 192.168.42.0 netmask 255.255.255.0 gw 192.168.42.2
Nov 30 12:11:07 helios ovpn-openvpn[19023]: ERROR: Linux route add command failed: external program exited with error status: 7

Eigentlich wollte ich, dass sich dann bei den Clients ueber das Routing auf die entsprechenden Maschinen (oben) verwiesen wird.

Die IP-Adresse von meinem Laptop: 192.168.4.5
Die IP-Adresse von meinem Handy: 192.168.155.3
Die IP-Adresse vom PC meines Vaters: 192.168.0.2

Jeder Rechner aus jedem Netz sollte auch auf jeden Rechner aus jedem Netz zugreifen koennen. Ich dachte ich waere da auf dem richtigen Weg, bin ich aber anscheinend nicht.
Wo genau liegt mein Denkfehler? Was hab ich falsch gemacht?

Bitte erleuchtet mich! :)

iscariot
01.12.10, 01:33
Jeder Rechner aus jedem Netz sollte auch auf jeden Rechner aus jedem Netz zugreifen koennen.
Korrektur: Ich meinte natuerlich, dass jeder Rechner auf alle Rechner im Netz 192.168.42.0/255.255.255.0 zugreifen soll.

honkstar
01.12.10, 09:19
Hallo,

du hast recht, in den fettgedruckten ist ein Fehler.
Mit der Server-Direktive gibst du an, welches Netz für VPN genommen werden soll. Dass sollte besser ein anderes sein, als das, was du in deinem LAN nutzt (also evtl. den Standard 10.8.0.0/24)
Genau das steht auch in den Logs:
WARNING: potential route subnet conflict between local LAN [192.168.42.0/255.255.255.0] and remote VPN [192.168.42.0/255.255.255.0]

Ausserdem solltest du überlegen, ob dein Fileserver wirklich auf zwei NICs IPs aus dem gleichen Subnetz haben sollte. Ich rate da eher von ab.

HTH

iscariot
01.12.10, 10:03
Erstmal vielen Dank fuer die Antwort. Hab mir schon langsam die Haare ausgerauft.


Mit der Server-Direktive gibst du an, welches Netz für VPN genommen werden soll. Dass sollte besser ein anderes sein, als das, was du in deinem LAN nutzt (also evtl. den Standard 10.8.0.0/24)
Das ist allerdings nicht das was ich wollte. Ich wollte, dass jeder sein Subnetz behaelt, aber auf 192.168.42.0/24 zugreifen kann.

Wenn ich folgendes aendere:

server 10.8.0.0 255.255.255.0
push "route 10.8.0.0 255.255.255.255.0"
Dann kann ich mich mit dem Server verbinden, bekomme aber keine direkte Verbindung zu anderen Maschinen in diesem Netz. :(
Was mach ich da denn jetzt falsch?


Ausserdem solltest du überlegen, ob dein Fileserver wirklich auf zwei NICs IPs aus dem gleichen Subnetz haben sollte. Ich rate da eher von ab.
Das ist ne andere strenggeheime ;) Sache, die dahinter steckt und ist so schon ok.

honkstar
01.12.10, 13:09
Aber wenn du

push "route 192.168.42.0 255.255.255.255.0"
nimmst, funktioniert das besser

Das 10er Netz ist nur für VPN, per push .... wird auf deinen Client eine Route geschrieben, die die Kommunikation mit dem eigentlichen LAN ermöglicht

iscariot
01.12.10, 15:28
Das 10er Netz ist nur für VPN, per push .... wird auf deinen Client eine Route geschrieben, die die Kommunikation mit dem eigentlichen LAN ermöglicht
Ah... OK. Danke. Das erklaert zumindest mal Einiges. Meine Konfiguration sieht nun so aus:


port 1194
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
server 10.8.0.0 255.255.255.0
push "route 192.168.42.0 255.255.255.0"
status openvpn-status.log
verb 3

Auf meinem Client hab ich jetzt folgende Konfiguration:

client
dev tun
proto tcp

remote xxx 1194
resolv-retry infinite
pull

persist-key
persist-tun

ca ca.crt
cert ipx.crt
key ipx.key

comp-lzo
verb 3

Jetzt kann ich mich mit 192.168.42.2 und 192.168.42.3 verbinden, aber mit allen anderen Hosts nicht. Mein erster Gedanke geht jetzt gen iptables/NAT. Lieg' ich da richtig oder muss ich an der Konfiguration weitere Aenderungen vornehmen?


Nochmals Danke fuer deine Muehen! :)

iscariot
01.12.10, 15:47
Was mich auch noch stutzig macht ist, dass im Serverlog folgendes steht:

ovpn-openvpn[28000]: TUN/TAP device tun0 opened
ovpn-openvpn[28000]: TUN/TAP TX queue length set to 100
ovpn-openvpn[28000]: /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
ovpn-openvpn[28000]: /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2


und auf dem Client bekomm ich sowas:

Wed Dec 1 15:39:11 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.42.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.
...

Wed Dec 1 15:39:11 2010 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Wed Dec 1 15:39:11 2010 /sbin/route add -net 192.168.42.0 netmask 255.255.255.0 gw 10.8.0.5
Wed Dec 1 15:39:11 2010 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.5

Ich dachte mein Gateway fuer 192.168.42.0 muesste nun 10.8.0.1 und nicht 10.8.0.5 sein?

honkstar
01.12.10, 20:58
Jetzt kann ich mich mit 192.168.42.2 und 192.168.42.3 verbinden, aber mit allen anderen Hosts nicht.
Verm. hast du keine sauberen Routen in das entsprechende Netz von den anderen Clients aus.
Das du die IPs .2 und .3 erreichst, hast du dir verdient. du wolltest ja unbedingt zwei IPs im selben Subnetz auf einer Maschine ;-)
Das macht die Fehlersuche etwas komplizierter. Die IPs gehen, weil auf dem Rechner gleichzeitig der OpenVPN-Server läuft und daher die Routen automatisch passen.
Guck dir die Routingtabellen auf dem Server an und vergleiche die mit denen auf den anderen Clients im Netz. Vermutlich siehst du dann schon, was dir fehlt.


Ich dachte mein Gateway fuer 192.168.42.0 muesste nun 10.8.0.1 und nicht 10.8.0.5 sein?
Nicht ganz doof, dein Gedanke, aber OpenVPN baut im Endeffekt eine Point2Point-Verbindung auf, daher ist das GW egal.
Müsstest du auch sehen können, wenn du ifconfig tun0 abfragst, da steht imho irgendwo p2p, ich hab gerade nix zum nachgucken zur Hand.

iscariot
02.12.10, 00:25
Guck dir die Routingtabellen auf dem Server an und vergleiche die mit denen auf den anderen Clients im Netz. Vermutlich siehst du dann schon, was dir fehlt.

Also soweit ich das sehe ist das korrekt:

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.42.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0



Ich werde mal deinen Rat befolgen und das zweite Interface anders anlegen... Mal schaun ob das was aendert... :(

honkstar
02.12.10, 21:40
OK, das war die Routingtable vom Server, wie sehen die von den anderen Clients aus?
Da fehlen verm. die Routen ins 192.168.42.0 Netz...

iscariot
02.12.10, 21:52
OK, das war die Routingtable vom Server, wie sehen die von den anderen Clients aus?
Da fehlen verm. die Routen ins 192.168.42.0 Netz...
Das war ein Auszug aus der Routingtabelle des Clients.


Auf dem Server sieht es exakt so aus:

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.42.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.42.1 0.0.0.0 UG 0 0 0 br0


Ich glaub's zwar nicht, aber kann das vielleicht an der Bridge zu den KVM-Maschinen liegen?