- Mitglied seit
- 7 Jun 2005
- Beiträge
- 323
- Punkte für Reaktionen
- 0
- Punkte
- 16
"openvpn mit tap und Kernel 2.6: Tunnel aufgebaut aber keine IP-Verbindung"
Hallo Leute!
Ich hatte unter Kernel 2.4 bisher einen stabilen Tunnel. Seit Umstellung auf Kernel 2.6 haben sich wohl die Devicenames geändert.
Ich habe also zunächst mein device angelegt mit "mknod /var/tmp/tun c 10 200".
Zum testen habe ich von Jack1st das statisch gelinkte "OpenVPN 2.1_rc2" mit folgender Konfig getartet:
Der Client baut nun erfolgreich die Verbindung auf:
Der Client bekommt (wie damals auch) die 192.168.110.201 zugewiesen und sollte (laut Netzmaske) das gesamte 192.168.110.0/24 an diesem Interface erwarten.
Der Eintrag findet sich auch in der Routingtabelle des Clients wieder:
Wenn ich nun versuche meine FBF anzupingen (oder eine andere Maschine in diesem LAN-Segment) erhalte ich keine Anwort.
Ich kann auf der Fritzbox sehen, daß die Pings vom Client verschlüsselt ankommen:
Warum setzt openvpn die Pakete nicht auf das Lan? Ich habe den Eindruck, /var/tmp/tun ist nicht mit dem lan gebridged?
Hallo Leute!
Ich hatte unter Kernel 2.4 bisher einen stabilen Tunnel. Seit Umstellung auf Kernel 2.6 haben sich wohl die Devicenames geändert.
Ich habe also zunächst mein device angelegt mit "mknod /var/tmp/tun c 10 200".
Zum testen habe ich von Jack1st das statisch gelinkte "OpenVPN 2.1_rc2" mit folgender Konfig getartet:
Code:
port 1194
proto udp
dev tap
dev-node /var/tmp/tun
# daemon
mode server
tls-server
pkcs12 7170-VPN.p12
dh dh1024.pem
auth SHA1
cipher AES-256-CBC
server-bridge 192.168.110.254 255.255.255.0 192.168.110.200 192.168.110.230
ifconfig-pool-persist hosts.ovpn
push "dhcp-option DNS 192.168.110.254"
client-to-client
keepalive 10 60
Der Client baut nun erfolgreich die Verbindung auf:
Code:
Tue Jul 17 04:30:15 2007 OpenVPN 2.0.5 Win32-MinGW [SSL] [LZO] built on Nov 2 2005
Tue Jul 17 04:30:17 2007 UDPv4 link local: [undef]
Tue Jul 17 04:30:17 2007 UDPv4 link remote: 84.167.188.198:1194
Tue Jul 17 04:30:19 2007 [7170-VPN] Peer Connection Initiated with 84.167.188.198:1194
Tue Jul 17 04:30:20 2007 TAP-WIN32 device [TAP-Tunnel] opened: \\.\Global\{245CFA46-FF79-4E29-A10F-B2E275CFC122}.tap
Tue Jul 17 04:30:20 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of [COLOR="Red"]192.168.110.201[/COLOR]/255.255.255.0 on interface {245CFA46-FF79-4E29-A10F-B2E275CFC122}
[DHCP-serv: 192.168.110.0, lease-time: 31536000]
Tue Jul 17 04:30:20 2007 Successful ARP Flush on interface [7] {245CFA46-FF79-4E
29-A10F-B2E275CFC122}
Tue Jul 17 04:30:25 2007 Initialization Sequence Completed
Der Client bekommt (wie damals auch) die 192.168.110.201 zugewiesen und sollte (laut Netzmaske) das gesamte 192.168.110.0/24 an diesem Interface erwarten.
Der Eintrag findet sich auch in der Routingtabelle des Clients wieder:
Code:
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 10.0.0.254 10.0.0.110 1
10.0.0.0 255.255.255.0 10.0.0.110 10.0.0.110 1
10.0.0.110 255.255.255.255 127.0.0.1 127.0.0.1 1
10.255.255.255 255.255.255.255 10.0.0.110 10.0.0.110 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.2 192.168.1.2 1
192.168.1.2 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.1.255 255.255.255.255 192.168.1.2 192.168.1.2 1
192.168.19.0 255.255.255.0 192.168.19.1 192.168.19.1 1
192.168.19.1 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.19.255 255.255.255.255 192.168.19.1 192.168.19.1 1
192.168.83.0 255.255.255.0 192.168.83.1 192.168.83.1 1
192.168.83.1 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.83.255 255.255.255.255 192.168.83.1 192.168.83.1 1
[COLOR="#ff0000"]192.168.110.0 255.255.255.0 192.168.110.201 192.168.110.201 1
192.168.110.201 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.110.255 255.255.255.255 192.168.110.201 192.168.110.201 1[/COLOR]
192.168.255.0 255.255.255.0 192.168.255.1 192.168.255.1 1
192.168.255.0 255.255.255.0 192.168.255.254 192.168.255.254 1
192.168.255.1 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.255.254 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.255.255 255.255.255.255 192.168.255.1 192.168.255.1 1
192.168.255.255 255.255.255.255 192.168.255.254 192.168.255.254 1
224.0.0.0 224.0.0.0 10.0.0.110 10.0.0.110 1
224.0.0.0 224.0.0.0 192.168.1.2 192.168.1.2 1
224.0.0.0 224.0.0.0 192.168.19.1 192.168.19.1 1
224.0.0.0 224.0.0.0 192.168.83.1 192.168.83.1 1
224.0.0.0 224.0.0.0 192.168.110.201 192.168.110.201 1
224.0.0.0 224.0.0.0 192.168.255.1 192.168.255.1 1
224.0.0.0 224.0.0.0 192.168.255.254 192.168.255.254 1
255.255.255.255 255.255.255.255 192.168.1.2 192.168.1.2 1
Standardgateway: 10.0.0.254
Wenn ich nun versuche meine FBF anzupingen (oder eine andere Maschine in diesem LAN-Segment) erhalte ich keine Anwort.
Ich kann auf der Fritzbox sehen, daß die Pings vom Client verschlüsselt ankommen:
Code:
/var/tmp $ tcpdump -qtni dsl port 1194
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on dsl, link-type LINUX_SLL (Linux cooked), capture size 68 bytes
IP 84.58.193.41.32986 > 169.254.2.1.1194: UDP, length 69
IP 84.58.193.41.32986 > 169.254.2.1.1194: UDP, length 85
IP 84.58.193.41.32986 > 169.254.2.1.1194: UDP, length 85
IP 84.58.193.41.32986 > 169.254.2.1.1194: UDP, length 85
Warum setzt openvpn die Pakete nicht auf das Lan? Ich habe den Eindruck, /var/tmp/tun ist nicht mit dem lan gebridged?
Zuletzt bearbeitet: