openvpn auf debian-Server einrichten

[Duff]

Hallo,

bin dabei auf meinem Home-Server (debian) OpenVPN einzurichten. Doch, wie sollte es auch anders sein, funktioniert es noch nicht richtig.

Netzwerk-Skizze:

client(s) -> Internet -> Fritzbox -> Server (debian)

Die Fritzbox ist per dyndns erreichbar und ich kann ich mich auch per ssh auf den Server übers Internet einwählen. Für openvpn habe ich ebenfalls auf der Fritzbox ein Portforwarding (wie auch bei ssh) eingerichtet. Es ist von außen der Port 65157 erreichbar, der intern auf 443 und die IP-Addresse 192.168.1.98 vom Server weitergeleitet werden soll.

Habe die Zertifikate erstellt und nach dem Starten des openvpn-Dienstes bekomme ich immer folgende Fehlermeldungen:

http://nopaste.debianforum.de/8941

Hier ist meine server.conf:

Code: Alles auswählen

root@homer:~/scripts# grep -v "#" /etc/openvpn/server.conf | sed -e '/^$/d'
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

Muss ich eventuell noch was am Server einstellen, wie z.B. IP-Forwarding?
Habe folgende Firewall-Regel eingerichtet bzw. frei geschaltet:

Code: Alles auswählen

INET=eth0               # IP-Adresse 192.168.1.98 
LAN=eth1                # IP-Adresse 192.168.1.99

# Zugriff auf den SSH-Server (Port 22) aus dem Internet erlauben
$IPT -A INPUT -i $INET -p tcp --dport 22 -j ACCEPT

#openvpn aus dem Internet
$IPT -A INPUT -i $INET -p udp --dport 443 -j ACCEPT
$IPT -A OUTPUT -o $INET -p udp --dport 443 -j ACCEPT

Ein ifconfig sieht so aus:
Denke, dass ich für das Interface eth0 noch den mtu-Wert anpassen muss, oder?

Code: Alles auswählen

eth0      Protokoll:Ethernet  Hardware Adresse 00:1E:8C:9C:A0:0A  
          inet Adresse:192.168.1.98  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6 Adresse: fe80::21e:8cff:fe9c:a00a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:23924 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1835 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:2693499 (2.5 MiB)  TX bytes:192740 (188.2 KiB)
          Basisadresse:0x2000 Speicher:c8200000-c8220000 

eth1      Protokoll:Ethernet  Hardware Adresse 00:1E:8C:9C:A0:0B  
          inet Adresse:192.168.1.99  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6 Adresse: fe80::21e:8cff:fe9c:a00b/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13372 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16289 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:1306237 (1.2 MiB)  TX bytes:3236167 (3.0 MiB)
          Basisadresse:0x2020 Speicher:c8220000-c8240000 

lo        Protokoll:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:50 errors:0 dropped:0 overruns:0 frame:0
          TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:4436 (4.3 KiB)  TX bytes:4436 (4.3 KiB)

tun0      Protokoll:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet Adresse:10.8.0.1  P-z-P:10.8.0.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Bin über jeden Rat dankbar.

Gruß,
Daniel

[Danielx]

Muss ich eventuell noch was am Server einstellen, wie z.B. IP-Forwarding?
Habe folgende Firewall-Regel eingerichtet bzw. frei geschaltet:

Wenn ich mich richtig erinnere dann wird doch auch eine FORWARD-Regel benötigt, oder?

Gruß,
Daniel

[Duff]

Ok, du meinst also sowas?

Code: Alles auswählen

INET=eth0               # IP-Adresse 192.168.1.98 
LAN=eth1                # IP-Adresse 192.168.1.99
TUN=tun0

# Zugriff auf den SSH-Server (Port 22) aus dem Internet erlauben
$IPT -A INPUT -i $INET -p tcp --dport 22 -j ACCEPT

#openvpn aus dem Internet
$IPT -A INPUT -i $INET -p udp --dport 443 -j ACCEPT
$IPT -A OUTPUT -o $INET -p udp --dport 443 -j ACCEPT
$IPT -A FORWARD -i $TUN -o $INET -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT
$IPT -A FORWARD -i $INET -o $TUN -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT

Was ich noch nicht verstehe ist, wenn ich den openvpn-Dienst auf dem Server starte, bekomme ich folgende Meldung:

Code: Alles auswählen

Sun Jun 15 09:30:13 2008 OpenVPN 2.0.9 x86_64-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Sep 22 2007
Sun Jun 15 09:30:13 2008 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (curren
tly it is 1492)
Sun Jun 15 09:30:13 2008 TUN/TAP device tun0 opened
Sun Jun 15 09:30:13 2008 ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1492
Sun Jun 15 09:30:13 2008 GID set to nogroup
Sun Jun 15 09:30:13 2008 UID set to nobody
Sun Jun 15 09:30:13 2008 UDPv4 link local (bound): [undef]:443
Sun Jun 15 09:30:13 2008 UDPv4 link remote: [undef]
Sun Jun 15 09:30:13 2008 Initialization Sequence Completed
Sun Jun 15 09:30:14 2008 80.137.121.XXX:63301 Re-using SSL/TLS context
Sun Jun 15 09:30:14 2008 80.137.121.XXX:63301 LZO compression initialized
Sun Jun 15 09:30:14 2008 80.137.121.XXX:63301 WARNING: normally if you use --mssfix and/or --fragment, you should also set -
-tun-mtu 1500 (currently it is 1492)
Sun Jun 15 09:30:14 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:16 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:16 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:18 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:19 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:20 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:21 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:23 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:24 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:25 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sun Jun 15 09:30:26 2008 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)

Die IP-Adresse 80.137.121.XXX ist von meinem Client bzw. der Fritzbox vor meinem Client. Aber woher kennt er diese IP-Adresse?

Netzwerkaufbau:

Client (openvpn-client) <-> Fritzbox -> INTERNET -> Fritzbox (mit Portforwarding zum Server) <-> debian-Server (openvpn-server)

Wenn ich mich nun per ssh auf den Server einwähle und den openvpn-server Dienst starte, kennt er die "neue" bzw. die aktuelle IP-Adresse des Clients/Fritzbox. Woher?
Und welche route müsste ich noch hinzufügen, bezüglich der Fehlermeldung?

[Danielx]

Die IP-Adresse 80.137.121.XXX ist von meinem Client bzw. der Fritzbox vor meinem Client. Aber woher kennt er diese IP-Adresse?

Netzwerkaufbau:

Client (openvpn-client) <-> Fritzbox -> INTERNET -> Fritzbox (mit Portforwarding zum Server) <-> debian-Server (openvpn-server)

Wenn ich mich nun per ssh auf den Server einwähle und den openvpn-server Dienst starte, kennt er die "neue" bzw. die aktuelle IP-Adresse des Clients/Fritzbox. Woher?

Ähm, du startest also auf dem Server den OpenVPN-Dienst und dann kennt dieser schon die neue öffentliche IP des Clienten?
Läuft denn zu diesem Zeitpunkt schon OpenVPN auf dem Clienten?
Denn woher soll OpenVPN auf dem Server die aktuelle IP des Clienten wissen, wenn dieser sich nicht mit dem Server verbunden hat bzw. das zumindest versucht hat?
Das ist mir ein Rätsel...

Was steht denn in "ipp.txt"?

Gruß,
Daniel

[DynaBlaster]

Code: Alles auswählen

$IPT -A OUTPUT -o $INET -p udp --dport 443 -j ACCEPT

Bist du sicher, dass die Antwort-Pakete deines Servers auch den Server verlassen? Diese Regel müsste bei deinem Szeanario eigentlich so lauten:

Code: Alles auswählen

$IPT -A OUTPUT -o $INET -p udp --sport 443 -j ACCEPT

Für die FORWARD-Regeln gilt ähnliches: bei der 2. FORWARD-Regel werden Pakete von eth0 nach tun0 erlaubt, die als Abesendeadresse eine IP aus 10.8.0.0/24 haben. Pakete von eth0 haben aber defnintiv eine Adresse wie 192.168.1.x. Also:

Code: Alles auswählen

$IPT -A FORWARD -i $INET -o $TUN -s 192.168.1.0/24 -d 10.8.0.0/24 -j ACCEPT

Könnte die "No Route to Host"-Meldung evtl. damit zusammenhängen, dass du eth0 und eth1 beide für das Netz 192.168.1.0/24 konfiguriert hast. Eigentlich sollten 2 NIC's nicht im gleichen Netz betrieben werden. Poste mal bitte auch die Ausgabe von "route -n". Ausserdem wäre imho zum Testen der OpenVPN-Verbindung eine zeitweilige Deaktivierung der Firewall auf dem OpenVPN-Server sinnvoll - nur um sicher zu gehen, dass die OpenVPN-Server- und OpenVPN-Client-Konfigurationsdateien nicht die Verbindungsprobleme verursachen. Um die iptables-Einträge kann man sich dann ja danach kümmern.

[Duff]

@Danielx: Das ist mir ja auch ein Rätsel, woher er die IP-Adresse des Clients kennt. Habe sie aber in der Fritzbox vor dem Client nachgeschaut und die Adresse dort ist genau die gleich wie die im Logfile vom Server.

Die Datei ipp.txt habe ich wieder genullt.

[Duff]

@DynaBlaster: Danke für die iptables-Regeln. Hatte zwar auch verschiedene Varianten probiert, aber leider immer wieder falsch.
So funktioniert es wenigstens schonmal vom Client bis zum tun-Device des Servers.

ifconfig auf dem debian-Server (openvpn-server)

Code: Alles auswählen

root@homer:/etc/openvpn# ifconfig
eth0      Protokoll:Ethernet  Hardware Adresse 00:1E:8C:9C:A0:0A  
          inet Adresse:192.168.1.98  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6 Adresse: fe80::21e:8cff:fe9c:a00a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21726 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1919 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:1973101 (1.8 MiB)  TX bytes:234509 (229.0 KiB)
          Basisadresse:0x2000 Speicher:c8200000-c8220000 

eth1      Protokoll:Ethernet  Hardware Adresse 00:1E:8C:9C:A0:0B  
          inet Adresse:192.168.1.99  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6 Adresse: fe80::21e:8cff:fe9c:a00b/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11158 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9341 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:1012513 (988.7 KiB)  TX bytes:1586221 (1.5 MiB)
          Basisadresse:0x2020 Speicher:c8220000-c8240000 

lo        Protokoll:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:38 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:3668 (3.5 KiB)  TX bytes:3668 (3.5 KiB)

tun0      Protokoll:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet Adresse:10.8.0.1  P-z-P:10.8.0.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:126 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100 
          RX bytes:9808 (9.5 KiB)  TX bytes:252 (252.0 b)

ifconfig auf dem client (openvpn-client)

Code: Alles auswählen

daniel-laptop:/etc/rc2.d# ifconfig
eth0      Link encap:Ethernet  Hardware Adresse 00:11:2f:a4:ee:db  
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:4 

eth2      Link encap:Ethernet  Hardware Adresse 00:0e:35:5c:f4:bf  
          inet Adresse:192.168.1.30  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::20e:35ff:fe5c:f4bf/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:2049 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2702 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:800607 (781.8 KiB)  TX bytes:270084 (263.7 KiB)
          Interrupt:4 Basisadresse:0xa000 Speicher:ff9ee000-ff9eefff 

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:66 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:5248 (5.1 KiB)  TX bytes:5248 (5.1 KiB)

tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet Adresse:10.8.0.6  P-z-P:10.8.0.5  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1492  Metrik:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100 
          RX bytes:252 (252.0 B)  TX bytes:1104 (1.0 KiB)

Muss ich auf dem Client den MTU-Wert für eth2 noch auf 1492 herunter setzen?

Irgendeinen Fehler habe ich aber doch noch. Ich kann vom Client aus nur die IP-Adresse des tun-Devices anpingen:

Code: Alles auswählen

daniel-laptop:~# ping 10.8.0.1 -c3
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=108 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=109 ms
64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=107 ms

--- 10.8.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 107.927/108.721/109.555/0.717 m

Auf weitere IP-Adressen im Netz 192.168.1.0/24 hinter dem debian-server (openvpn-server) kann ich nicht zugreifen bzw. anpingen.

Code: Alles auswählen

daniel-laptop:/etc/rc2.d# ping 192.168.1.12
PING 192.168.1.12 (192.168.1.12) 56(84) bytes of data.

--- 192.168.1.12 ping statistics ---
195 packets transmitted, 0 received, 100% packet loss, time 194021ms

Vom Server aus bekomme ich die erwünschte Antwort, wenn ich die IP-Adresse 192.168.1.12 anpinge (ist ein Drucker).

Wo ist denn nun da noch der Fehler???

route -n auf dem debian-server (openvpn-server)

Code: Alles auswählen

root@homer:/etc/openvpn# route -n
Kernel IP Routentabelle
Ziel            Router          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.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

route -n auf dem client (openvpn-client)

Code: Alles auswählen

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.1.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth2
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth2

[DynaBlaster]

Auf weitere IP-Adressen im Netz 192.168.1.0/24 hinter dem debian-server (openvpn-server) kann ich nicht zugreifen bzw. anpingen

Das liegt vermutlich daran, dass die angepingten Clients den Weg nicht zurück kennen, sprich ihnen die Route ins Netz 10.0.8.0/24 fehlt. Nehmen wir also beispielsweise den Drucker-Server (192.168.1.12). Der bekommt also nun eine Ping-Anfrage von 10.0.8.5. Seine Antwort wird er aber nicht an den OpenVPN-Server schicken, sondern an sein Standard-Gateway, wahrscheinlich die FritzBox. Am besten konfigurierst du auf der FritzBox eine statische Route ins Netz 10.0.8.0/24 über 192.168.1.98. Dann "finden die Pakete auch den Weg zurück".

Alternativ könntest du auch alle Pakete des Tunnels mittels iptables maskieren. Der entsprechende Befehl auf dem OpenVPN-Server sähe dann so aus:

EDIT: ACHTUNG: Der folgende Teil ist natürlich Unfug, Richtigstellung weiter unten in diesem Thread

Code: Alles auswählen

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

[Duff]

Super, danke. So funktioniert auf jeden Fall schon mal ein pingen.

Dann müsste ich auf dem Client auch einen entsprechenden Eintrag einrichten, damit ich vom Server auf die IP 192.168.1.30 des Clients pingen kann.

Aber kannst du mir vielleicht das PREROUTING in diesem Zusammenhang nochmal in 2 bis 3 Sätzen erklären?
Danke.

[DynaBlaster]

EDIT: ACHTUNG !! Ebenfalls Blödsinn, Richtigstellung weiter unten ....

Zum PREROUTING:

Diese Regel bewirkt, dass der OpenVPN-Server den Traffic, der aus dem Netz 10.0.8.0/24 kommt, so manipuliert, dass er die ursprüngliche Absende-IP (also bspw. 10.0.8.5) beim "Weiter-Verschicken" durch 192.168.1.98 ersetzt. Für den Printserver sieht es dann so aus, als käme die Ping-Anfrage von 192.168.1.98 und antwortet entsprechend. Der OpenVPN-Server wandelt dann diese Antwort-Pakete wieder zurück.
Im Grunde umgehst du damit also die Route-Problematik.

Dann müsste ich auf dem Client auch einen entsprechenden Eintrag einrichten, damit ich vom Server auf die IP 192.168.1.30 des Clients pingen kann

Sehe ich das richtig, dass beide Netze hinter den Fritz-Boxen den IP-Bereich 192.168.1.0/24 haben? Dann wird es kompliziert.

[Duff]

Dann müsste ich auf dem Client auch einen entsprechenden Eintrag einrichten, damit ich vom Server auf die IP 192.168.1.30 des Clients pingen kann

Sehe ich das richtig, dass beide Netze hinter den Fritz-Boxen den IP-Bereich 192.168.1.0/24 haben? Dann wird es kompliziert.[/quote]

Ja, beide Netze haben hinter der Fritzbox den IP-Bereich 192.168.1.0/24.
Und in auf beiden Seiten hat die Fritzbox die IP 192.168.1.1.

[DynaBlaster]

Nagut, was genau willst du denn mit der OpenVPN-Verbindung erreichen? Wenn du die beiden Netze zu einem "grossen gemeinsamen" Netz zusammenfassen willst, würde sich Bridging anbieten. Dann musst du allerdings dafür sorgen, dass es keine "doppelten" Addressen gibt - das gilt auch für die Fritz-Boxen, von denen dann nur eine die 192.168.1.1 haben darf. Siehe dazu hier: http://openvpn.net/index.php/documentat ... dging.html

[Duff]

Ich will, dass man sich von überall aus übers Internet ins Netzwerk wo der debian-Server steht einwählen kann.
Dann soll man von den Windows-Clients aus auf den Server (auf dem u.a. Samba läuft) zurgreifen können. Speziell auf die Samba-Freigaben.

Eventuell soll auch ein Remote-Zugriff auf andere Rechner gestattet werden.

Habe gerade mal an einem anderen Rechner versucht die vpn-Verbindung (die ich bisher von einem debian-client zum debian-server aus getestet habe) von einem Windows-Rechner (client) aus probiert.

Naja, dass wollte auf jeden Fall noch nicht so, wie ich es von meinem debian-client aus gemacht habe.

[DynaBlaster]

Ich will, dass man sich von überall aus übers Internet ins Netzwerk wo der debian-Server steht einwählen kann.
Dann soll man von den Windows-Clients aus auf den Server (auf dem u.a. Samba läuft) zurgreifen können. Speziell auf die Samba-Freigaben.

Gut, dafür kannst du auf das Bridging verzichten. Wenn der Samba-Server auf dem OpenVPN-Server auf allen Interfaces lauscht, sollten die IPTABLES-Regeln so aussehen.

Code: Alles auswählen

iptables -A INPUT -i tun0 -s 10.0.8.0/24 -p TCP -m multiport --dport 139,445 -j ACCEPT
iptables -A INPUT -i tun0 -s 10.0.8.0/24 -p UDP --dport 137:138 -j ACCEPT
iptables -A OUTPUT -o tun0 -d 10.0.8.0/24 -p TCP -m multiport --sport 139,445 -j ACCEPT
iptables -A OUTPUT -o tun0 -d 10.0.8.0/24 -p UDP --sport 137:138 -j ACCEPT

Eventuell soll auch ein Remote-Zugriff auf andere Rechner gestattet werden

Das ist schon etwas haariger. Entweder du änderst bei einem der beiden Fritz-Boxen den IP-Bereich (z.B. auf 192.168.2.0/24) und richtest dann die bereits erwähnten statischen Routen auf den Fritzboxen ein. Oder - wenn das nicht gehen sollte, kannst du auch den Traffic für die Remote-Verbindungen auf dem OpenVPn-Server "umbiegen". Etwa so:

Code: Alles auswählen

iptables -A FORWARD -i tun0 -o eth0 -d 192.168.1.20 -p TCP --dport 3389 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 192.168.1.20 -p TCP --sport 3389 -j ACCEPT
iptables -t nat -A PREROUTING -i tun0 -p TCP --dport 3389 -j DNAT --to 192.168.1.20:3389
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.1.98

A propos: Ich merke jetzt erst, dass ich weiter oben voll den Mist verzapft habe. Dass die PREROUTING-Regel die Absende-Adresse manipuliert, ist völliger Unsinn. Genau das Gegenteil ist der Fall. Sie manipuliert die Ziel-Adresse. Das heisst bei deinen Ping-Versuchen auf den Printserver hat nicht der Printserver geantwortet, sondern der OpenVPN-Server selbst. Kein Wunder, dass das geklappt hat, sinnvoll ist es aber auf keinen Fall Sorry für die Fehlinformationen.

Das obige Beispiel ist jetzt allerdings richtig und bezieht sich auf die Weiterleitung einer RDP-Verbindung durch den OpenVPN-Server. Auf dem OpenVPN-Client, der sich mit einem Remote-Rechner hinter dem OpenVPN-Server verbinden soll, müsstest du allerdings im RDP-Client als Zieladresse 10.0.8.1:3389 eingeben. Die PREROUTING-Regel sorgt dann dafür, dass der OpenVPN-Server die Verbindung nicht selbst annimmt, sondern an den Rechner 192.168.1.20 weiterleitet. Die POSTROUTING-Regel ändert dann die Absende-Adresse von 10.0.8.x nach 192.168.1.98, damit der RDP-Server auf 192.168.1.20 antworten kann. Die FORWARD-Regeln müssen zusätzlich aktiviert werden, um diesen Traffic überhaupt zu routen.

Sorry nochmal für die Fehlinformationen. So ist das aber korrekt. Siehe auch hier: http://www.debianforum.de/forum/viewtop ... 7098&start

[Duff]

Danke.

Wäre es nicht noch einfacher, wenn ich für das Interface tun einfach alles erlauben würde?
Oder geht so was nicht?

[DynaBlaster]

Wäre es nicht noch einfacher, wenn ich für das Interface tun einfach alles erlauben würde?

Natürlich geht das. Die POST- und PREROUTING-Regeln müssen für die Remote-Desktop-Verbindungen aber weiterhin angewendet werden. Das liegt dann aber immer noch an der Routing-Problematik. Wären die Fritz-Boxen in unterschiedelichen Netzwerk-Bereichen, könntest du darauf verzichten und dich auf die FORWARD-Regeln beschränken.

[Duff]

Ok, danke.

Hoffe, dass ich es verstanden habe.
Wenn ich also unterschiedliche Netze an den Fritzboxen einrichte. Z.B. nehme ich am Client 192.168.2.0, dann sollten auf dem Server (192.168.1.0) die Forward-Regel reichen, also

Code: Alles auswählen

$IPT -A FORWARD -i $INET -o $TUN -s 192.168.1.0/24 -d 10.8.0.0/24 -j ACCEPT

, so wie du es geschrieben hattest.

Muss ich dann trotzdem noch was an den Routingtabellen ändern?

[DynaBlaster]

Code: Alles auswählen

################     ###############              ###############     ##################
# Client A     #-----# Fritz Box A #---INTERNET---# Fritz Box B #-----# Debian OpenVPN #
# 192.168.2.10 #     # 192.168.2.1 #              # 192.168.1.1 #     # 192.168.1.98   #
################     ###############              ###############     ##################
          |                                                                 |
10.0.8.5  |_________________________________________________________________| 10.0.8.1
                                   VPN-Tunnel

Ich denke, so wird das ganze anschaulicher. Wir haben es grundsätzlich also mit 3 Netzen zu tun. Netz A (192.168.2.0/24), Netz B (192.168.1.0/24) und Netz C (10.0.8.0/24).

Um bei aktivierter OpenVPN-Verbindung von "Client A" auf den "Debian-OpenVPN-Server" zuzugreifen brauchst du keine FORWARD-Regel. Auch die zusätzlichen Routen kannst du in diesem Szenario getrost ignorieren. "Client A" weiss, dass er den Server 10.0.8.1 über tun0 erreichen kann. Um bespielsweise einen SSH-Daemon auf dem Debian-OpenVPN-Server zu erreichen, müsstest du in dessen Firewall folgende Löcher "bohren" (Den Code für Samba habe ich ja bereits gepostet).

Code: Alles auswählen

iptables -A INPUT -i tun0 -p TCP --dport 22 -j ACCEPT
iptables -A OUTPUT -o tun0 -p TCP --sport 22 -j ACCEPT

Die FORWARD-Kette wird erst notwendig, wenn du von Client A "über" den "Debian-OpenVPN-Server" auf andere Rechner im Netz B zugreifen musst. Wollte man grundsätzlich alles von A nach B passieren lassen, müsste man das hier zusätzlich ergänzen:

Code: Alles auswählen

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

Das gewährleistet zwar das Weiterleiten durch den "Debian-OpenVPN-Srver", nun stehen wir aber immer noch vor einem Routing-Problem. Client A kennt nur Netz A und C, der "Debian-OpenVPN-Server" kennt nur "Netz B und C". "Fritz-Box A" und alle Clients in A kennen nur Netz A, "Fritz-Box B" und Clients in B äquivalent dazu nur Netz B. Wenn also beispielsweise ein Ping von 10.0.8.5 auf die "Fritz-Box B" gestartet wird, geht das schief, weil die "Fritz-Box B" schlicht nicht weiss, wie sie 10.0.8.5 antworten soll. Und hier kommen "statische Routen" ins Spiel. Du musst der "Fritz-Box B" mitteilen, dass sie Netz C über 192.168.1.98 erreichen kann(das kann man irgendwo im Webinterface der Fritz-Box konfigurieren). Äquivalent dazu verhält es sich mit der "Fritz-Box A" (die muss dann natürlich nicht 192.168.1.98 verwenden, sondern 192.168.2.10).

Ich hoffe, die Problematik und die Lösungsansätze sind nun etwas klarer

[Huck Fin]

Läuft das nun bei dir ?

Wenn nicht, sag bescheid.
Bei mir läuft das nämlich super...

[Duff]

Muss noch auf der Client-Seite das Netzwerk in 192.168.2.0 ändern.

Wie sehen denn deine Konfigs und iptables-Regeln aus?

[Huck Fin]

Ich habe das warscheinlich anders gelöst, als du.
Verbindest du zwei Linux-Server ?
Ich mach das inzwischen in alle Richtungen (von Win XP nach Linux-Server und Linux-Server zu Linux-Server)

Ich benutze auf beiden Seiten den Port 5000
im Router habe ich eingestellt, dass eingehende Anfragen auf Port 5000 auf die IP vom Server geleitet werden.

Hier mal die Config vom XP-PC (habe mal das Ziel durch ne IP ersetzt für Testzwecke)
-----------------------------------

Code: Alles auswählen

remote 192.168.22.5
dev tap
proto udp
port 5000
tls-client
client
ns-cert-type server
cipher AES-256-CBC
ca C:\\Programme\\OpenVPN\\Zerti\\ca.crt 
key C:\\Programme\\OpenVPN\\Zerti\\pc1.key 
cert C:\\Programme\\OpenVPN\\Zerti\\pc1.crt
tls-auth C:\\Programme\\OpenVPN\\Zerti\\ta.key 1
pull
verb 3 
keepalive 10 120
comp-lzo

Und die vom Linux-Server:

Code: Alles auswählen

float
port 5000
proto udp
mode server
dev tap
ifconfig 10.0.0.10 255.255.255.0
ifconfig-pool 10.0.0.12 10.0.0.19
client-to-client
tls-server
dh /etc/openvpn/dh1024.pem 
ca /etc/openvpn/ca.crt 
key /etc/openvpn/server1.key 
cert /etc/openvpn/server1.crt
tls-auth /etc/openvpn/ta.key 0
push "route-gateway 10.0.0.10"
push "route-gateway 192.168.22.5"
cipher AES-256-CBC
verb 3 
keepalive 10 120
comp-lzo

Die Zertifikate erstell ich immer unter Win-XP, weil ich das inzwischen gut kann.
Das mit dem ta.key 0 ist gegen DOS-Attacken
0 am Server und 1 bei den Clients.

Wenn dann eine Verbindung steht, log ich mich mit SSH auf 10.0.0.10 ein.

Hab gerade mal den ganzen Tread durchgelesen.
Ich kann der ganzen Sache nicht ganz folgen.
Wenn du nur von einem PC auf den Server zugreifen willst, ist das ganz leicht.
PCx -> FritzBox -> Internet -> no-ip.org -> FritzBox2 -> DebianServer
Port 5000 udp ----------> port5000 udp -> port5000 udp
Und wieso heissen deine Zertifikate alle .PEM ?

Server:

Code: Alles auswählen

tls-server 
dh C:\\Programme\\OpenVPN\\Zertifikate\\dh2048.pem 
ca C:\\Programme\\OpenVPN\\Zertifikate\\meine-ca.crt 
key C:\\Programme\\OpenVPN\\Zertifikate\\Server.key 
cert C:\\Programme\\OpenVPN\\Zertifikate\\Server.crt 
 

Client:

Code: Alles auswählen

tls-client 
ca C:\\Programme\\OpenVPN\\Zertifikate\\meine-ca.crt 
key C:\\Programme\\OpenVPN\\Zertifikate\\Client_01.key 
cert C:\\Programme\\OpenVPN\\Zertifikate\\Client_01.crt 
 

[Duff]

Habe mir die folgenden Tutorials/Anleitungen zu OpenVPN angeschaut (hätte auch nichts gegen ein gutes Buch):

http://www.pronix.de/pronix-935.html
http://www.openvpn-forum.de/wiki/index.php/OVPN-Linux

[DynaBlaster]

Ich kann der ganzen Sache nicht ganz folgen.
Wenn du nur von einem PC auf den Server zugreifen willst, ist das ganz leicht.

Das ist richtig. Der ganze Kram bezüglich statischer Routen und den iptables-FORWARD-Regeln ist auch nur nötig, wenn Duff auf Clients hinter dem OpenVPN-Server zugreifen will. Dabei bezog ich mich auf diese Äusserung

Eventuell soll auch ein Remote-Zugriff auf andere Rechner gestattet werden.

[Huck Fin]

Habe mir die folgenden Tutorials/Anleitungen zu OpenVPN angeschaut (hätte auch nichts gegen ein gutes Buch):

http://www.pronix.de/pronix-935.html
http://www.openvpn-forum.de/wiki/index.php/OVPN-Linux

Schau doch mal im OpenVPN-Forum vorbei.
Da gibt es auch ein Buch, aber das braucht man (ich) nicht unbedingt.
http://www.vpnforum.de/openvpn-forum/

und unter
http://www.vpnforum.de/openvpn-forum/vi ... php?t=2101

steht, dass man unter Linux nix routen muss !

Nachtrag:
Wenn du auf PCs hinter dem Netzwerk zugreifen möchtest, gibt es 1000 Möglichkeiten.

1. du kannst OpenVPN auf mehreren Server im Ziel installieren, alle auf anderen Ports (5000, 5003, 5006, etc)
In der FritzBox kannst du ja die Ports an verschiedene PCs verteilen.
Hab ich auch schon gemacht. Dann brauchst du nur eine DynDNS
Dann richtest du dir auf deinem Client PC mehrere configs ein, alle gleich bis auf den Port.
Dann kannst du dich zu jedem einzelnen verbinden.
Oder

2. du kannst OpenVPN auf mehreren PCs im Ziel (Client-Modus) installieren, alle verbinden sich zum Haupt-Server.
Am Server haben die clients dann die IPs 10.0.0.10, 10.0.0.11, etc
und der Eintrag

Code: Alles auswählen

client-to-client

tut den Rest
Die kann man anpingen und was man sonst so machen will.
Hab ich so auch am laufen und geht gut.

Oder schau dir mal die Anleitung an, ob die auf dein Problem passt.
http://www.vpnforum.de/openvpn-forum/vi ... php?t=2101

Aber ich glaube es ist erstmal wichtig überhaupt eine verschlüsselte Verbindung aufzubauen.
Da kannst du meine Configs von oben gerne für nehmen.
Die funktionieren.
Aber schau nochmal genau, warum deine ganzen Zertifikate .pem heissen.
Bei mir heissen die nämlich .key, oder .crt

[Huck Fin]

Keine Ahnung.
Wofür soll das gut sein ?


Aber ich hab gerade was gefunden...

Mit dem Eintrag

push “route 192.168.178.0 255.255.255.0″
(ip durch dein Server-Netz ersetzen)

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

sollen die PCs hinter dem Server sichtbar werden...

Ich kann das hier nicht testen, weil im anderen Netz sind die gleichen IPs wie hier...
Das solltest du auch beachten.

Nanu, wo ist dein Posting ?