openvpn auf debian-Server einrichten

[DynaBlaster]

push “route 192.168.178.0 255.255.255.0″
...
echo "1" >> /proc/sys/net/ipv4/ip_forward

Das "push"-Kommando fügt eine entsprechende Route für das "Server-Netz" in der Routing-Tabelle des OpenVPN-Clients ein - damit kann der OpenVPN-Client dieses Netz erreichen. Das Problem mit dem "Rückweg" bleibt aber bestehen. Die Rechner im "Server-Netz" müssen ebenfalls mitgeteilt bekommen, wie sie das VPN-Netz kontaktieren können, sonst schicken sie ihre Antwort-Pakete nicht an den OpenVPN-Server, der diese dann weiterleitet, sondern an ihr Standard-Gateway.

Das Hinzufügen einer statischen Route für das OpenVPN-Netz im Konfigurationsmenü der FritzBox muss also weiterhin erfolgen. Oder man "nattet" (iptables -t nat -A POSTROUTING -o eth0 ... -j SNAT --to 192.168.1.98) den kompletten VPN-Traffic, sodass dem "Server-Netz" vorgegaukelt wird, dieser Traffic käme vom OpenVPN-Server ...

[Duff]

Danke, danke.

Werde mir auf jeden Fall mal anschauen, wie ich eine statische Route in der Fritzbox hinzufügen kann.

Wie genau muss diese denn dann lauten?

[DynaBlaster]

Das Zielnetz ist natürlich das VPN-Netz, also 10.0.8.0/24. Das Gateway ist der Rechner mit seiner IP im "Server-Lan", der die Verbindung zum VPN-Netz hat, also der Debian-OpenVPN-Server. Als Gateway-Adresse müsstest du bei deinem Netz-Aufbau also 192.168.1.98 eintragen.

Im ersten oder zweiten Posting dieses Threads steht, dass auf dem Debian-OpenVPN-Server eth0 die IP 192.168.1.98 hat und eth1 die IP 192.168.1.99 - das führt zu Verwirrungen in der Routing-Tabelle. 2 Netzwerkkarten im gleichen Netzwerk-Bereich geht aber nicht - ausser über Bonding natürlich. Ich würde also vorschlagen, eth1 vorerst zu deaktivieren - um eine weitere potentielle Fehlerquelle auszuschließen.

[Huck Fin]

Danke, danke.

Werde mir auf jeden Fall mal anschauen, wie ich eine statische Route in der Fritzbox hinzufügen kann.

Wie genau muss diese denn dann lauten?

Hi Duff,
also ich würde zuerst mal schauen, dass du eine Verbindung hinbekommst von A nach B.
Das mit den Routen kannst du machen, wenn die Verbindung steht.
Da kannst du nach belieben dann rumprobieren.

Wenn du möchtest, dass die PCs sich alle gegenseitig sehen, solltest du eventuell die Netze später angleichen, also alle im gleichen Netz, nur unterschiedliche IPs.

[Duff]

Wenn du möchtest, dass die PCs sich alle gegenseitig sehen, solltest du eventuell die Netze später angleichen, also alle im gleichen Netz, nur unterschiedliche IPs.

Also ich kann vom Client aus eine Verbindung über openvpn zum Server herstellen. Ich kann dann auch den Server mit der IP 10.8.0.1 vom Client aus anpingen. Nur möchte ich gerne auch auf die anderen Rechner im Netzwerk vom OpenVPN-Server (192.168.1.98(server), Netz 192.168.1.0) zugreifen können, was aber noch nicht funktioniert und wohl am Routing liegt (wie es DynaBlaster erläutert hat).

Und gerade dass ich alle Rechner im gleichen Netz habe (Client und Server und Rest im 192.168.1.0), ist doch, sowie ich es verstanden habe, mein großes Problem!?

[Huck Fin]

Solange du nicht die gleichen IPs verwendest, ist das so sogar besser, wenn alle im gleichen Netz sind.

[Duff]

Solange du nicht die gleichen IPs verwendest, ist das so sogar besser, wenn alle im gleichen Netz sind.

Also ich habe es im Thread so verstanden, dass das gerade die Routing-Probleme verursacht.
Jetzt bin ich ein wenig verwirrt

[DynaBlaster]

Solange du nicht die gleichen IPs verwendest, ist das so sogar besser, wenn alle im gleichen Netz sind.

Also ich habe es im Thread so verstanden, dass das gerade die Routing-Probleme verursacht.
Jetzt bin ich ein wenig verwirrt

Und das zu Recht !

Wenn wir die grafische Darstellung weiter oben im Thread zur Grundlage nehmen und Netz A anstatt 192.168.2.0/24 weiter 192.168.1.0/24 nutzt, dann sähe die Routing-Tabelle auf Client A wie folgt aus:

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.8.0        0.0.0.0         255.255.255.0   U    0    0      0    tun0
192.168.1.0     10.0.8.1        255.255.255.0    U    0    0       tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Wie soll denn Client A jetzt bitte unterscheiden, ob IP 192.168.1.X über eth0 oder über tun0 erreichbar ist? Das geht einfach nicht, mal abgesehen davon, dass die Routing-Tabelle von oben nach unten "abgearbeitet" wird, sprich der erste passenden Routing-Eintrag wird genutzt.

Und bevor jetzt jemand daherkommt und erzählt das ginge doch: Ja, das geht! Aber dann muss man für OpenVPN nicht das tun-Device nutzen, sondern das tap-Device. Und das tap-Device müsste anschließend mit eth0 zu einer Bridge zusammengefasst werden. Siehe dazu auch die offizielle OpenVPN-Doku: http://openvpn.net/index.php/documentat ... ml#vpntype

[Huck Fin]

Sorry, dann hab ich da was verwechselt bezüglich gleicher IPs.
Wie gesagt, ich realisiere solche Zugriffe anders.

Hier mal ein nützlicher Link, der mir weitergeholfen hat.
http://www.henningdippel.de/vpn/install ... n-servers/

Da ist das auch sehr schön und in deutsch erklärt.

[Duff]

Ja, der Link sieht sehr interessant aus Huck Fin.

Ich werde aber auch noch mal die Variante von DynaBlaster ausprobieren, indem ich mein Client-Netz auf 192.168.2.0 umstelle.


Werde mich dann die Tage noch mal melden...

[Duff]

So, melde mich nun seit langem nochmal zurück zu diesem Thema, da ich eben erst das Netzwerk von 192.168.1.0 auf 192.168.2.0 (Client-Seite) umgestellt habe.

Aber trotzdem kann ich nur bis zum tun-device des Servers pingen. An Geäte hinter dem Server komme ich nicht...

Code: Alles auswählen

daniel@daniel-laptop:~$ route -n
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 eth2
192.168.1.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth2
daniel@daniel-laptop:~$ ping -c3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2009ms

Jetzt kann ich auch schon nicht mehr bis zum Server pingen. Im Logfile des Server finde ich solche Einträge:

Code: Alles auswählen

hu Aug 14 16:07:10 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Thu Aug 14 16:07:12 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Thu Aug 14 16:07:13 2008 80.137.71.31:62690 Re-using SSL/TLS context
Thu Aug 14 16:07:13 2008 80.137.71.31:62690 LZO compression initialized
Thu Aug 14 16:07:13 2008 80.137.71.31:62690 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)
Thu Aug 14 16:07:13 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Thu Aug 14 16:07:13 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)

Mmh..........

[Duff]

Sorry, aber vielleicht kann mir ja nochmal jemand weiterhelfen?

Kann es sein, dass ich noch (weiß nicht genau wie) eine statische Route auf der fritzbox einrichten muss (im LAN des OpenVPN-Servers)?

Aktuell sieht meine Netzwerktopologie so aus (soll später noch ein wenig verändert werden):

[stinkstiefel]

Ich möchte vorweg nehmen das ich mir nicht alles durchgelesen habe, aber für mich sieht das mit den zwei ifs am Server nach Unfug aus oder welche genauen Zweck soll die zweite NIC haben?
Edit: Habe den Beitrag grad noch etwas überflogen. Warum soll der Roadwarrior eigentlich eine IP aus 10.8.0.0/24 bekommen?

[Duff]

Zur Zeit habe ich noch diese Variante mit den 2 NIC's am Server, da ich noch den Server noch nicht als Server und Gateway/Router einsetzen möchte.

Wenn ich das Interface eth1 (192.168.1.99) herunterfahre, kann ich auf 10.8.0.1 und 192.168.1.98 vom Client aus pingen. Auf einen Netzwerkdrucker, der im Netz 192.168.1.0 ist und die IP 192.168.1.12 hat, kann ich jedoch nicht pingen oder sogar per telnet zugreifen.

Denke, dass ich wohl noch ein Problem mit dem Routing habe, oder?

Was muss ich noch machen?


PS: Soll ich eventuell noch mal meine aktuellen Einstellungen posten oder sogar einen neuen Thread öffnen?

Client.conf

Code: Alles auswählen

client
float
dev tun
tun-mtu 1492
fragment 1300
mssfix
proto udp
remote mydyndns 65157
ca /etc/openvpn/vpn-ca.pem
cert /etc/openvpn/mycert.pem
key /etc/openvpn/mykey.pem
auth SHA1
cipher aes-256-cbc
nobind
comp-lzo yes
persist-key
persist-tun
verb 3

Server.conf

Code: Alles auswählen

port 443
proto udp
dev tun
tun-mtu 1492
fragment 1300
mssfix
ca /etc/openvpn/vpn-ca.pem
cert /etc/openvpn/servercert.pem
key /etc/openvpn/serverkey.pem
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
auth SHA1
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
verb 3
status /etc/openvpn/openvpn-status.log

[stinkstiefel]

Warum antwortest du nicht auf meine zweite Frage? Gibt es einen zwingenden Grund für 10.8.0.0/24?
Wenn es wurscht ist welche IP der VPN-Client bekommt dann stell für VPN auf 192.168.1.0/24 um das macht es bedeutend einfacher.

[Duff]

Warum antwortest du nicht auf meine zweite Frage? Gibt es einen zwingenden Grund für 10.8.0.0/24?
Wenn es wurscht ist welche IP der VPN-Client bekommt dann stell für VPN auf 192.168.1.0/24 um das macht es bedeutend einfacher.

Verstehe ich nicht.

Dass Ganze Szenario sollte doch so funktionieren:

Routing

Der Routing-Modus ist die einfachste Form der sicheren Kommunikation und stellt einen verschlüsselten Tunnel zwischen zwei Gegenstellen her, über den ausschließlich IP-Pakete geleitet werden (Layer 3). Dazu wird jeder Gegenstelle eine virtuelle IP-Adresse eines fiktiven Subnetz zugewiesen (z. B. 10.8.0.1 und 10.8.0.2).

Der Zugriff auf das dahinter liegende Netzwerk ist grundsätzlich nicht direkt möglich (Point-to-Point Verbindung). Um die dortigen Adressen zu erreichen, muss die Gegenstelle die Datenpakete mittels IP-Forwarding und Einträgen in der Routingtabelle weitervermitteln.

[stinkstiefel]

Verstehe ich nicht.

Macht nix. In der jetzigen Konstellation haben die Clients in 192.168.1.0/24 als Getaway die Fritz!Box.
Der Fritz!Box kannst du über eine Route mitteilen wo Sie Rückantworten für 10.8.0.0/24 hinschicken soll, nämlich an 192.168.1.98
Dabei bin ich mangels Informationen nicht sicher mit welcher Absender-IP die Päckchen überhaupt bei z.B. 192.168.1.12 ankommen und noch irgend wo etwas geblockt wird, tcpdump ist dein Freund.

[Duff]

Der Fritz!Box kannst du über eine Route mitteilen wo Sie Rückantworten für 10.8.0.0/24 hinschicken soll, nämlich an 192.168.1.98

Wie muss ich diese denn auf der Fritzbox einrichten???
Hat jemand vielleicht einen Beispiel-Eintrag? Muss ich das in der Datei [/quote]machen, in der ich auch das Port-Forwarding eingerichtet habe???

Dabei bin ich mangels Informationen nicht sicher mit welcher Absender-IP die Päckchen überhaupt bei z.B. 192.168.1.12 ankommen und noch irgend wo etwas geblockt wird, tcpdump ist dein Freund.

Kann ich mal machen, aber dafür sollte ich vorher die "richtige Rückroute" auf der Fritzbox eingerichtet haben.

[stinkstiefel]

Bei der Fritz!Box unter System >> Ansicht die Expertenansicht aktivieren. Irgend wo unter Netzwerk müsste sich die Option Route verstecken. Um erst einmal zu schauen was wie wo auf dem Client ankommt ist die Route der Fritz!Box ziemlich nebensächlich.

[Duff]

Ok, auf das Frontend der Fritzbox komme ich über VPN, also remote nicht.

Wenn ich allerdings einen tcpdump auf dem Server starte und einen ping vom Client aus absetze, passiert folgendes:

Antwort auf 10.8.0.1 und 192.168.1.98 (IP-Adressen auf dem Server). Im tcpdump sehe ich jedoch nichts.
Ping auf 192.168.1.12, ein Drucker im Netz, wo auch der Server steht, bekomme ich keine Antwort. Dafür sehe ich was beim tcpdump.

Code: Alles auswählen

root@homer:~/docs# tcpdump -i eth0 icmp -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:11:55.737787 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 10.8.0.6 > 192.168.1.12: ICMP echo request, id 12054, seq 1, length 64
20:11:56.742319 IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 10.8.0.6 > 192.168.1.12: ICMP echo request, id 12054, seq 2, length 64
...

[stinkstiefel]

Das bringt dich leider noch nicht wirklich weiter, du brauchst die Information ob beim Client (Drucker) etwas ankommt. Der Drucker ist für deinen Test nicht besonders gut geeignet da wirst du ja mit tcpdump schlecht nachschauen können.

[Duff]

Hinter dem Server ist im Netzwerk leider kein Client, auf dem sich ein linux befindet.

Aber auf den Server komme ich ja mit einem ping...

[stinkstiefel]

Hinter dem Server ist im Netzwerk leider kein Client, auf dem sich ein linux befindet.

Was glaubst du wozu es windump gibt?

Aber auf den Server komme ich ja mit einem ping...

In wie weit hilft dir das jetzt bei der Fehlerdiagnose weiter?

[Duff]

Wenn ich es doch richtig verstanden habe, müsste ich bei korrekt gesetzter Rückroute auf der fritzbox funktionieren.

Vielleicht sollte ich einfach mal dieses probieren (am besten wäre natürlich ohne Webinterface, weil dann könnte ich es remote über ssl machen).

[Duff]

So, melde mich auch noch mal nach längerem...

Habe nun auf der Fritzbox eine statische "Rückroute" eingerichtet.

Code: Alles auswählen

Netz: 10.8.0.0
Netmask: 255.255.255.0
GW: 192.168.1.98

Wenn ich nun allerdings vom Client aus die OpenVPN-Verbindung starte, bekomme ich folgende Fehlermeldung, kurz nachdem die Verbindung eigentlich steht:

Code: Alles auswählen

Thu Aug 28 20:00:51 2008 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Thu Aug 28 20:00:51 2008 OPTIONS IMPORT: timers and/or timeouts modified
Thu Aug 28 20:00:51 2008 OPTIONS IMPORT: --ifconfig/up options modified
Thu Aug 28 20:00:51 2008 OPTIONS IMPORT: route options modified
Thu Aug 28 20:00:51 2008 TUN/TAP device tun0 opened
Thu Aug 28 20:00:51 2008 TUN/TAP TX queue length set to 100
Thu Aug 28 20:00:51 2008 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1492
Thu Aug 28 20:00:51 2008 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.5
Thu Aug 28 20:00:51 2008 Initialization Sequence Completed
Thu Aug 28 20:01:01 2008 Authenticate/Decrypt packet error: cipher final failed

Kann dies an der neu eingerichteten Rückroute liegen???