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

[gelöst] openvpn funktioniert nur manchmal

Phillinger

Phillinger

Hallo,

ich bin hier kurz vor der Verzweifelung...

Ich habe einen multiclient-VPN aufgesetzt, der lief auch viele Monate (wenn nicht Jahre) fehlerfrei. Nun musste ich auf neue HW umsiedeln, was auch alles gut geklappt hat. HTTP/S-Server, SSH, Samba, LDAP... alles prima umgezogen und out-of-the-box flugfähig. Und eigentlich auch openvpn. Aber nun klappen die Verbindungen von außen um's Verrecken nicht mehr. D.h. manchmal (gaaaanz selten) schon... Aber ich kann es nicht reproduzieren und stabil sind diese Verbindungen auch nicht.

Interessant ist: Von einem Client innerhalb des LANS des Servers ist alles kein Problem, auch wenn sich der Client über die externe IP verbindet. Also quasi "raus" und wieder "rein" verbindet.

Das dumme ist, dass unser Provider (KabelBW) ungefragt eine neue FW auf das Modem gespielt hat. Eventuell ist das eine Fehlerquelle, leider weiß ich nicht, WANN das geschehen ist. Und dann ist da natürlich der komplett neu aufgesetzte Server...

Um den Fehler möglichst einzukreisen, habe ich mal versucht, eine Minimalst-Verbindung aufzubauen, ohne Zertifikate und den ganzen Verschlüsselungs-Schmonz. Einfach per Befehlszeile:

Server:
Code: 
openvpn --remote ROADWARRIOR_IP --port 54321 --dev tun1 --ifconfig 192.168.10.1 192.168.10.2 --verb 3

Client:
Code: 
openvpn --remote SERVER_IP --port 54321 --dev tun1 --ifconfig 192.168.10.2 192.168.10.1 --verb 3

Auch das klappt nicht. Nicht mal ein Ping. Hier die Logs:

Server-Log:
Code: 
Tue Nov  8 16:17:29 2011 OpenVPN 2.1.3 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Oct 22 2010
Tue Nov  8 16:17:29 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Nov  8 16:17:29 2011 ******* WARNING *******: all encryption and authentication features disabled -- all data will be tunnelled as cleartext
Tue Nov  8 16:17:29 2011 Socket Buffers: R=[124928->131072] S=[124928->131072]
Tue Nov  8 16:17:29 2011 TUN/TAP device tun1 opened
Tue Nov  8 16:17:29 2011 TUN/TAP TX queue length set to 100
Tue Nov  8 16:17:29 2011 /sbin/ifconfig tun1 192.168.10.1 pointopoint 192.168.10.2 mtu 1500
Tue Nov  8 16:17:29 2011 Data Channel MTU parms [ L:1500 D:1450 EF:0 EB:4 ET:0 EL:0 ]
Tue Nov  8 16:17:29 2011 Local Options hash (VER=V4): 'b3846a5e'
Tue Nov  8 16:17:29 2011 Expected Remote Options hash (VER=V4): '44426e7e'
Tue Nov  8 16:17:29 2011 UDPv4 link local (bound): [undef]
Tue Nov  8 16:17:29 2011 UDPv4 link remote: [AF_INET]ROADWARRIOR_IP:54321

Client-Log:
Code: 
Tue Nov 08 16:19:20 2011 OpenVPN 2.1_rc20 i686-pc-mingw32 [SSL] [LZO2] [PKCS11]
built on Oct  1 2009
Tue Nov 08 16:19:20 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or hig
her to call user-defined scripts or executables
Tue Nov 08 16:19:20 2011 ******* WARNING *******: all encryption and authenticat
ion features disabled -- all data will be tunnelled as cleartext
Tue Nov 08 16:19:21 2011 TAP-WIN32 device [OpenVPN TAP] opened: \\.\Global\{5D39
68DC-A6FD-47DA-8094-5B4E674EF06A}.tap
Tue Nov 08 16:19:21 2011 TAP-Win32 Driver Version 9.6
Tue Nov 08 16:19:21 2011 TAP-Win32 MTU=1500
Tue Nov 08 16:19:21 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 1
92.168.10.2/255.255.255.252 on interface {5D3968DC-A6FD-47DA-8094-5B4E674EF06A}
[DHCP-serv: 192.168.10.1, lease-time: 31536000]
Tue Nov 08 16:19:21 2011 Successful ARP Flush on interface [3] {5D3968DC-A6FD-47
DA-8094-5B4E674EF06A}
Tue Nov 08 16:19:21 2011 Data Channel MTU parms [ L:1500 D:1450 EF:0 EB:4 ET:0 E
L:0 ]
Tue Nov 08 16:19:21 2011 Local Options hash (VER=V4): '44426e7e'
Tue Nov 08 16:19:21 2011 Expected Remote Options hash (VER=V4): 'b3846a5e'
Tue Nov 08 16:19:21 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Nov 08 16:19:21 2011 UDPv4 link local (bound): [undef]:54321
Tue Nov 08 16:19:21 2011 UDPv4 link remote: SERVER_IP:54321

Irgendwann kommt dann folgende Fehlermeldung (Server):
Code: 
Tue Nov  8 16:24:46 2011 us=945275 NOTE: failed to obtain options consistency info from peer -- this could occur if the remote peer is running a version of OpenVPN before 1.5-beta8 or if there is a network connectivity problem, and will not necessarily prevent OpenVPN from running (0 bytes received from peer, 0 bytes authenticated data channel traffic) -- you can disable the options consistency check with --disable-occ.

Was habe ich bisher versucht?
  • Firewall auf Router vor Server deaktiviert - keine Änderung
  • OpenVPN mit --disable-occ gestartet - keine Änderung
  • OpenVPN mit --float gestartet - keine Änderung
  • ALLE mir zugänglichen Komponenten (Server -- Router(Location A) -- Router(Location B) -- Client) per NTP Zeit-synchronisiert
  • nmap zeigt den UDP-Port als "open|filtered"

Alle anderen Services (SSH, HTTPS) funktionieren von außen einwandfrei. Ich bin wirklich ratlos, wo ich weiter suchen soll. Hat hier irgendjemand eine Idee?
 
S

spoensche

Wenn du dem Client manuell eine IP per OpenVPN zuweisst, dann sollte sie nicht aus dem IP-Bereich des DHCP-Servers sein und auch nicht aus dem selben Netz, wie die IP deiner Netzwerkkarte.

Wenn du dich mit dem Client zum Server verbindest, dann poste mal bitte die Ausgabe (auf dem Server ausführen) von
Code: 
ip a s
ip route show
 
OP
Phillinger

Phillinger

Das ist doch....

Also erstmal danke für die Antwort! :) Es war wohl ein Routing-Problem durch ein zweites eth-Interface (der alte Server hatte nur eines).

Hier die Ausgaben von ip a s
Code: 
root@albert:~# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1e:67:07:26:05 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.200/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::21e:67ff:fe07:2605/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:1e:67:07:26:04 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.210/24 brd 192.168.0.255 scope global eth1
    inet6 fe80::21e:67ff:fe07:2604/64 scope link
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.0.0.1 peer 10.0.0.2/32 scope global tun0
root@albert:~#
... und ip route show
Code: 
root@albert:~# ip route show
10.0.0.2 dev tun0  proto kernel  scope link  src 10.0.0.1
10.0.0.0/24 via 10.0.0.2 dev tun0
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.200
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.210
default via 192.168.0.1 dev eth1
default via 192.168.0.1 dev eth0
root@albert:~#


Hier noch die eigentliche Server-Config:
Code: 
root@albert:~# cat /etc/openvpn/OpenVPN.conf
# In das OpenVPN-Verzeichnis wechseln
cd /etc/openvpn

# Managaement Konsole auf localhost:11940
management localhost 11940

# Logfile (immer anhängen)
log-append /var/log/openvpn.log

# Device
dev tun0

# Port und Protokoll
port 1194
proto udp

# Paketgroessen
tun-mtu 1500
fragment 1300
mssfix

#Server
mode server
server 10.0.0.0 255.255.255.0
keepalive 10 60

# Zum merken der IP-Adressen
ifconfig-pool-persist ipp.txt

# Netzwerkconfig.
push "route 10.0.0.0 255.255.255.0"

# Auth.-Server
tls-server
# crl-verify crls/crl.pem
auth SHA1

# Diffie-Hellman-Parameter
dh dh1024.pem

# Verschluesselungsmethode
# cipher AES-256-CBC

# Zertifikate im PKCS#12-Format
pkcs12 certs/server.p12

# Verbose-Mode
verb 3
root@albert:~#


So wie ich das verstehe, ist das Problem, dass beide Interfaces eine default-Route nach draußen bereitstellen. Und OpenVPN nimmt mal diese und mal diese (meistens die falsche). Liege ich da richtig? Kann die "Abzweigung" nicht eigentlich egal sein, solange Server und Client überhaupt eine Verbindung erhalten?

/edit: Was ich seit heute früh beobachte ist noch folgendes in /var/log/openvpn.log:
Code: 
root@albert:~# tail -n 10 /var/log/openvpn.log
Wed Nov  9 09:20:37 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:20:54 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:20:56 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:20:59 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:21:02 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:21:36 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:24:31 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:24:32 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:24:34 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
Wed Nov  9 09:24:38 2011 testuser/xxx.xxx.xxx.xxx:38764 Need IPv6 code in mroute_extract_addr_from_packet
root@albert:~#
Kann es auch sein, dass mein Provider KabelBW erste Schritte Richtung IPv6 macht und mir in die Suppe spuckt(e)? Ich glaube nicht, dass mein Client noch IPv6-Pakete in den Tunnel streut.
 
OP
Phillinger

Phillinger

Phillinger schrieb:
Kann es auch sein, dass mein Provider KabelBW erste Schritte Richtung IPv6 macht und mir in die Suppe spuckt(e)? Ich glaube nicht, dass mein Client noch IPv6-Pakete in den Tunnel streut.
Zum Vergrößern anklicken....
Ok, das hat sich sehr schnell als Blödsinn herausgestellt: Einfach beim TAP-Win32 Interface den IPv6-Protokollstapel deaktiveren und (vorerst) glücklich sein. :D

Bleibt die Vermutung mit dem Routing-Problem.
 
S

spoensche

Die Routen sind korrekt und in der Routingtabelle vorhanden (Siehe Ausgabe von ip route show).

Das Problem ist folgender Eintrag in deiner Konfig:
Philinger schrieb:
Code: 
server 10.0.0.0 255.255.255.0
Zum Vergrößern anklicken....

Du kannst deinem Server nicht die 10.0.0.0 zuweisen, weil es die Netzadresse ist und die kann keinen Host zugewiesen werden. Du musst deinem Server also mind. die 10.0.0.1 zuteilen.

Die IPv6- Meldung hat nichts mit deinem Provider zu tun. Wenn du IPv6 auf deinem Rechner nicht deaktviert hast, dann hast du auch IPv6 Adressen.
Die Meldung ist ein Hinweis, dass die Funtkion mroute_extract_addr_from_packet IPv6 code erwartet, um die IPv6-Multicastrouten anlegen zu können.
 
OP
Phillinger

Phillinger

Danke für die Antwort. :)

Zunächst mal muss ich sagen, dass OpenVPN wieder tadellos funktioniert, seit ich einfach die zweite eth-Schnittstelle deaktiviert habe. An der OpenVPN-Serverconfig habe ich nichts geändert.

spoensche schrieb:
Das Problem ist folgender Eintrag in deiner Konfig:
Philinger schrieb:
Code: 
server 10.0.0.0 255.255.255.0
Zum Vergrößern anklicken....

Du kannst deinem Server nicht die 10.0.0.0 zuweisen, weil es die Netzadresse ist und die kann keinen Host zugewiesen werden. Du musst deinem Server also mind. die 10.0.0.1 zuteilen.
Zum Vergrößern anklicken....
Nene, das ist schon korrekt. Siehe auch die openvpn-manpage:
Code: 
 --server network netmask
              A helper directive designed to simplify the configuration of OpenVPN's server mode.
              This directive will set up  an  OpenVPN  server  which will allocate addresses to clients
              out of the given network/netmask.

              The server itself will take the ".1" address of the given network for use as the server-side 
              endpoint of the local TUN/TAP interface.
Der Server bekommt also in meinem Fall automatisch die 10.0.0.1 zugewiesen.

IPv6 ist soweit ja schon als Ursache ausgeklammert und auch das hässliche Logfile-Fluten dieser Einträge ist abgestellt (siehe mein Posting oben).

Aber ich wette, dass OpenVPN wieder auf die Schnauze fliegt, sobald ich die zweite Schnittstelle wieder aktiviere. Und zwar - so denke ich - weil es dann zwei gleichwertige default-Routen gibt (siehe Ausgabe von ip route show oben). Was meint ihr?
 
OP
Phillinger

Phillinger

Joa, das Problem ist "gelöst", aber nicht geklärt. Ich setze den Thread auf [gelöst] und schreibe hier noch rein, falls ich selbst auf die Erklärung komme. Jeder andere ist natürlich auch eingeladen... ;)

Aber ich wette, dass OpenVPN wieder auf die Schnauze fliegt, sobald ich die zweite Schnittstelle wieder aktiviere. Und zwar - so denke ich - weil es dann zwei gleichwertige default-Routen gibt (siehe Ausgabe von ip route show oben). Was meint ihr?
Zum Vergrößern anklicken....

Vielen Dank für die Tipps, Hilfen und die Aufmerksamkeit. :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben