7170 (29.04.40) 100% CPU Last mit openvpn

[finreg]

Hallo,

angesichts von Halbwissen zu openvpn [oder eher weniger ] bräuchte ich einen Tipp von euch.

Ich nutze eine openvpn bridge zwischen zwei Fritzboxen. Jetzt möchte ich die Serverbox von 7050 (14.04.26) auf 7170 (29.04.40) umstellen.

Bei praktisch identischer debug.cfg läuft die 7050 problemlos, die 7170 kriegt unmittelbar nach Start von openvpn 100% CPU Last (angezeigt über imond/trayflow). Sobald ich openvpn kille, ist die Last wieder normal. Wenn ich auf der 7170 openvpn nicht als daemon laufen lasse, dann sehe ich, dass da eine Endlos-Schleife läuft. Die Clientbox versucht sich anzumelden (IP der clientbox im log) aber das klappt nicht.

Schleifeninhalt plus Kommentare von mir:

>>begin
MULTI: multi_create_instance called # keine Ahnung was das heißt
Re-using SSL/TLS context
LZO compression initalized
Control Chanddel MTU parms ...
Data Channel MTU parms ...
Local option hash ...
Expecte Remote Option hash ...
# Local option hash und expected remote option hash sind unterschiedlich.
TCP: accept(3) failed: Ressource temporarily unavailable.
<<end

Und dann das Ganze von vorne.

Das erfolgt, bevor ich mit brctl den tap0 der bridge hinzufüge. Aber auch das Zufügen zur Bridge bringt nichts, immer noch 100% Last.

Die passenden binaries (openvpn, brctl je nach Kernel habe ich aus dem Forum gezogen. Die laufen problemlos. Das tun device bei der 7170 habe ich angelegt. Die unterschiedlichen Pfade zum tun device sind der einzige mit bewusste Unterschied in den config files. In der ar7.cfg ist die port-weiterleitung auch identisch (tcp 0.0.0.0:1194 192.168.1.1:1194 0). # wozu ist eigentlich die 0 nach der zweiten IP?

Serverconifg:

daemon
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
proto tcp-server
port 1194
dev tap0
dev-node /var/tmp/vpn/tun # bei 7170
#dev-node /dev/misc/net/tun # bei 7050
mode server
tls-server
ifconfig 192.168.1.1 255.255.255.0 # IP-serverbox
client-to-client
keepalive 10 60
comp-lzo
persist-key
persist-tun
verb 3

Ich bin leider am Ende meines Lateins.

Wißt Ihr mehr?

Danke

finreg

 

[MaxMuster]

TCP: accept(3) failed: Ressource temporarily unavailable.

Das ist vermutlich dein Problem. Ich kenne noch keine Lösung dazu, soweit ich das weiß, tritt das auch nur bei der 7170 mit TCP auf. Die einzige Lösung die ich kenne ist: Versuche es wenn möglich mit UDP statt TCP.

Jörg

 

[finreg]

@max
UDP hat bei der 7050 nicht funktioniert. Ich werde es mal ausprobieren, sobald die hash Werte passen. macht vorher wohl kaum Sinn.
Verwenden die verschiedenen openvpn Versionen vielleicht verschiedene Kodierungsmethoden?

 

[MaxMuster]

Die Hash-Werte sind schon o.k. so, dass sind die jeweils lokal berechneten, die die "Gegenseite" dann auch berechnen muss.
Aber das TCP-Problem besteht vermutlich noch immer (siehe auch hier) so dass du wohl nur mit UDP weiter kommen wirst.
Für die Weiterleitung würde ich dir

"tcp 0.0.0.0:1194 0.0.0.0:1194"

enpfehlen mit "," oder ";" dahinter, je nachdem wo die Regel steht (oder analog mit udp), als Änderung also auf die 0.0.0.0 und ohne die 0 am Ende.

Jörg

 

[finreg]

@max
<<tcp 0.0.0.0:1194 0.0.0.0:1194 0 #serverbox",>>
hatte ich auch schon probiert. gibt denselben Effekt.
Nächstes Wochenende kann ich das Ganze mal mit UDP probieren. Vielleicht klappt das dann ja.

Noch eine Frage, um das log besser zu verstehen. Da steht der bereits angegebene Text drin und dann das Ganze nochmal mit der vorangestellten IP der Clientbox. Sind das jeweils identische Meldungen einmals seitens Server und einmals seitend client? Wenn ja, dann wären die hash-Werte übereinstimmen.



MULTI: multi_create_instance called # keine Ahnung was das heißt
Re-using SSL/TLS context
LZO compression initalized
Control Channel MTU parms ...
Data Channel MTU parms ...
Local option hash ...
Expecte Remote Option hash ...
TCP connection established with <Ip Client-Box>:2870 #wieso port 2870, wo kommt der denn her?
Socket Buffets: R=[131072->131072] S=[131072->131072]
TCPv4_Server link local: [undef]
TCPv4_Server link remote: <IP-Client>:2870
<Ip Client-Box>:2870 MULTI: multi_create_instance called # keine Ahnung was das heißt
<Ip Client-Box>:2870 Re-using SSL/TLS context
<Ip Client-Box>:2870 LZO compression initalized
<Ip Client-Box>:2870 Control Chanddel MTU parms ...
<Ip Client-Box>:2870 Data Channel MTU parms ...
<Ip Client-Box>:2870 Local option hash ...
<Ip Client-Box>:2870 Expecte Remote Option hash ...
<Ip Client-Box>:2870 TCP: accept(3) failed. Resource temporarily unavailable (errno=11)

und dann von vorne:

MULTI: multi_create_instance called
Re-using SSL/TLS context
LZO compression initalized
Control Chanddel MTU parms ...
Data Channel MTU parms ...

 

[MaxMuster]

Da steht der bereits angegebene Text drin und dann das Ganze nochmal mit der vorangestellten IP der Clientbox. Sind das jeweils identische Meldungen einmals seitens Server und einmals seitend client?

Bei mir sieht das Log etwas anders aus (vermutlich hast du eine andere Version). Auf der Serverseite kannst du eigentlich nur das Log des Servers sehen, daher vermute ich, dass das die erste "Initialisierung" ist (quasi der Programmstart) danach die Ausgabe des "verbindenden Clients".

TCP connection established with <Ip Client-Box>:2870 #wieso port 2870, wo kommt der denn her?

Das ist der "Absende-Port" des Clients, auf den dann der Server antwortet.

Jörg

 

[finreg]

Ich kann leider erst wieder am Wochenende probieren.

Bis dann