[Gelöst] Fehler beim Start von OpenVPN-Server: Linux route add command failed

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
cmonty14

cmonty14

Mitglied
Mitglied seit
22 Jan 2007
Beiträge
378
Punkte für Reaktionen
0
Punkte
16
Hallo!

Ich habe für das Paket "OpenVPN" den Debug-Modus aktiviert und finde im Log folgende Einträge:
Code: 
root@net2-FB7390:/var/mod/root# cat /var/tmp/debug_openvpn.out 
Wed Nov 13 01:06:18 2013 OpenVPN 2.3.2 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Aug 31 2013
Wed Nov 13 01:06:18 2013 Diffie-Hellman initialized with 1024 bit key
Wed Nov 13 01:06:18 2013 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Wed Nov 13 01:06:18 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 13 01:06:18 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 13 01:06:18 2013 Socket Buffers: R=[202752->131072] S=[202752->131072]
Wed Nov 13 01:06:18 2013 TUN/TAP device tap0 opened
Wed Nov 13 01:06:18 2013 TUN/TAP TX queue length set to 100
Wed Nov 13 01:06:18 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Nov 13 01:06:18 2013 /sbin/ifconfig tap0 10.0.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.0.0.255
Wed Nov 13 01:06:18 2013 /sbin/route add -net 192.168.100.201 netmask 255.255.255.0 gw 10.0.0.11
route: netmask and route address conflict
Wed Nov 13 01:06:18 2013 ERROR: Linux route add command failed: external program exited with error status: 1
Wed Nov 13 01:06:18 2013 /sbin/route add -net 192.168.100.202 netmask 255.255.255.0 gw 10.0.0.12
route: netmask and route address conflict
Wed Nov 13 01:06:18 2013 ERROR: Linux route add command failed: external program exited with error status: 1
Wed Nov 13 01:06:18 2013 /sbin/route add -net 192.168.100.204 netmask 255.255.255.0 gw 10.0.0.14
route: netmask and route address conflict
Wed Nov 13 01:06:18 2013 ERROR: Linux route add command failed: external program exited with error status: 1
Wed Nov 13 01:06:18 2013 /sbin/route add -net 192.168.100.205 netmask 255.255.255.0 gw 10.0.0.15
route: netmask and route address conflict
Wed Nov 13 01:06:18 2013 ERROR: Linux route add command failed: external program exited with error status: 1
Wed Nov 13 01:06:18 2013 /sbin/route add -net 192.168.100.206 netmask 255.255.255.0 gw 10.0.0.16
route: netmask and route address conflict
Wed Nov 13 01:06:18 2013 ERROR: Linux route add command failed: external program exited with error status: 1
Wed Nov 13 01:06:18 2013 chroot to '/tmp/openvpn' and cd to '/' succeeded
Wed Nov 13 01:06:18 2013 GID set to openvpn
Wed Nov 13 01:06:18 2013 UID set to openvpn
Wed Nov 13 01:06:18 2013 UDPv4 link local (bound): [undef]
Wed Nov 13 01:06:18 2013 UDPv4 link remote: [undef]
Wed Nov 13 01:06:18 2013 MULTI: multi_init called, r=256 v=256
Wed Nov 13 01:06:18 2013 IFCONFIG POOL: base=10.0.0.10 size=11, ipv6=0
Wed Nov 13 01:06:18 2013 Initialization Sequence Completed

Die Fehler stehen nach meinem Verständnis in direktem Zusammenhang mit der Konfiguration "VPN IP-Adressen und Routing im VPN -> Erweiterte Clientkonfiguration".

Es stellt sich mir aber die Frage:
Wo ist der Fehler in der Konfiguration zu suchen?

Folgende Einstellungen findet man im GUI des Pakets "OpenVPN":
Lokale IP-Adresse: 10.0.0.1
Netzmaske: 255.255.255.0
DHCP-Range für Clients: 10.0.0.10 10.0.0.20
Optional: Routing von IP-Netzen:
Lokales Netz: 192.168.100.0 255.255.255.0

Client: mobile1-SGSi9100
Client-VPN-IP : 10.0.0.11
Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.201 255.255.255.0

THX
 
Zuletzt bearbeitet:
Moin

Soweit ich dass verstanden habe, werden Routen nicht auf einzelne IPs gesetzt, sondern auf ganze Netze.
Bei dir:
Code: 
/sbin/route add -net 192.168.100.206 netmask 255.255.255.0 gw 10.0.0.16

Probier mal:
Code: 
/sbin/route add -net 192.168.100.[B][COLOR="#FF0000"]0[/COLOR][/B] netmask 255.255.255.0 gw 10.0.0.16

Code: 
# /sbin/route add -net 192.168.100.[COLOR="#B22222"]0[/COLOR] netmask 255.255.255.0 gw 10.0.0.16
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
93.220.XXX.XXX   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
[B][COLOR="#B22222"]192.168.100.0   10.0.0.16       255.255.255.0   UG    0      0        0 dsl[/COLOR][/B]
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl
# /sbin/route del -net 192.168.100.0 netmask 255.255.255.0 gw 10.0.0.16
 
Zuletzt bearbeitet:
Genau, so ist es.

Als Ergänzung: Die Routen können beliebig gesetzt werden. Aber es müssen IP und Netzmaske zueinander passen.
Host-IPs haben z.B. eine Maske 255.255.255.255, Class C Netze 255.255.255.0.

Aber es gibt natürlich noch viel mehr Netze...

Nur als Beispiel 192.168.100.200 könnte diese Netzmasken haben:

192.168.100.200 255.255.255.255 -> nur diese IP
192.168.100.200 255.255.255.254 -> als Netz eher "sinnfrei" (das Netz hat nur Netz-IP 192.168.100.200 und Broadcast 192.168.100.201) für Routing o.k.
192.168.100.200 255.255.255.254 -> Netz mit 2 "nutzbaren" IPs Netz-IP 192.168.100.200 und Broadcast 192.168.100.203 mit "IPs .201 und .202"
192.168.100.200 255.255.255.248 -> Netz mit 6 "nutzbaren" IPs Netz-IP 192.168.100.200 und Broadcast 192.168.100.207 mit "IPs .201 bis .206"

Für die von dir wohl gewünschten IPs 201-206 könntest du also einen Eintrag "192.168.100.200 255.255.255.248" nehmen, der den Bereich abdeckt und zudem noch .200 und .207 enthält.
 
Sorry, aber mir ist nicht ganz klar, welche Einstellung geändert werden muss.
Ist es der Wert "Netz bei Client (Syntax: <ip> <subnetmask>):" bei den Einstellungen der einzelnen Clients?
Oder ist der Wert "Netzmaske" anzupassen?

THX
 
Ändern musst du 192.168.100.200 in 192.168.100.0 und über die Netzmaske (siehe Post von MaxMuster) gibtst du wohl an wieviele IPs aus diesem Netz nutzbar sind.
 
Gut.

Dann muss also diese Einstellung geändert werden zur Verwendung von 6 "nutzbaren" IPs:
Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.0 255.255.255.248

Damit entfällt aber die feste Zuweisung einer IP zu einem bestimmten Client, oder?
 
Nein, denn das eine (Route zu einem IP Adressenbereich) hat mit dem anderen (Zuweisung einer IP Nummer), nichts zu tun.
Diese IPs müssen den Geräten vorher und/oder nachher zugewiesen werden.
Zwingend bei dir ist, dass das Gerät mit der 10er IP als Gateway zu dem 192.168.100.er Netz vorhanden sein muss.
Eventuell kann das 10er Netz nicht erreicht werden, dann brauchst du noch eine Route zum 10er Netz.
Wenn das 10er Netz über den Router zu erreichen ist dann:
Code: 
route add -net 10.0.0.0 netmask 255.255.0.0 gw 192.168.178.1
(Wenn an der Fritz!Box angeschlossen)
 
Zuletzt bearbeitet:
Hier in deinem Beispiel wäre das dann (für .200 - .207 beim CLient):
Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.200 255.255.255.248

Alternativ für das ganze Netz 192.168.100.x:
Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.0 255.255.255.0
 
Das Problem ist nach Modifikation der Konfiguration behoben; im Debug-Log steht jetzt:
Code: 
root@net2-FB7390:/var/mod/root# cat /var/tmp/debug_openvpn.out 
Thu Nov 14 00:51:15 2013 OpenVPN 2.3.2 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Aug 31 2013
Thu Nov 14 00:51:15 2013 Diffie-Hellman initialized with 2048 bit key
Thu Nov 14 00:51:15 2013 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Thu Nov 14 00:51:15 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 14 00:51:15 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 14 00:51:15 2013 Socket Buffers: R=[202752->131072] S=[202752->131072]
Thu Nov 14 00:51:15 2013 TUN/TAP device tap0 opened
Thu Nov 14 00:51:15 2013 TUN/TAP TX queue length set to 100
Thu Nov 14 00:51:15 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Nov 14 00:51:15 2013 /sbin/ifconfig tap0 10.0.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.0.0.255
Thu Nov 14 00:51:15 2013 /sbin/route add -net 192.168.100.200 netmask 255.255.255.248 gw 10.0.0.11
Thu Nov 14 00:51:15 2013 /sbin/route add -net 192.168.100.200 netmask 255.255.255.248 gw 10.0.0.12
Thu Nov 14 00:51:15 2013 /sbin/route add -net 192.168.100.200 netmask 255.255.255.248 gw 10.0.0.14
Thu Nov 14 00:51:15 2013 /sbin/route add -net 192.168.100.200 netmask 255.255.255.248 gw 10.0.0.15
Thu Nov 14 00:51:15 2013 /sbin/route add -net 192.168.100.200 netmask 255.255.255.248 gw 10.0.0.16
Thu Nov 14 00:51:15 2013 chroot to '/tmp/openvpn' and cd to '/' succeeded
Thu Nov 14 00:51:15 2013 GID set to openvpn
Thu Nov 14 00:51:15 2013 UID set to openvpn
Thu Nov 14 00:51:15 2013 UDPv4 link local (bound): [undef]
Thu Nov 14 00:51:15 2013 UDPv4 link remote: [undef]
Thu Nov 14 00:51:15 2013 MULTI: multi_init called, r=256 v=256
Thu Nov 14 00:51:15 2013 IFCONFIG POOL: base=10.0.0.10 size=11, ipv6=0
Thu Nov 14 00:51:15 2013 Initialization Sequence Completed
Thu Nov 14 00:51:23 2013 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]91.89.xxx.xxx:54337
 
Sorry, so ist es falsch, da hab ich oben nicht richtig gelesen.

Wenn du wirklich immer nur genau eine 192.168.100.20x-er IP-Adresse zu einem stimmten Client routen willst (zumindest steht das da), dann musst du jeweils die korrekte IP mit der Host-Maske 255.255.255.255 eintragen, also:

Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.201 255.255.255.255 beim Client 10.0.0.11
...
Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.206 255.255.255.255 beim Client 10.0.0.16

Dann ist da immer noch der TLS-Fehler drin. Deaktiviere das doch erstmal oder uberprüfe die Keys auf beiden Seiten nochmal auf Gleichheit...
 
Zuletzt bearbeitet:
Danke für den Hinweis.
Ich werde die Änderung
Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.201 255.255.255.255 beim Client 10.0.0.11
...
Netz bei Client (Syntax: <ip> <subnetmask>): 192.168.100.206 255.255.255.255 beim Client 10.0.0.16
implementieren, damit ich eine feste Zuordnung Client -> IP-Adresse habe.

Abgesehen davon hast du natürlich Recht mit der Feststellung, dass der Fehler
Code: 
TLS Error: cannot locate HMAC in incoming packet from [AF_INET]91.89.xxx.xxx:54337
immer noch auftritt.

Ich habe alle Schlüssel neu generiert und auch die tls-auth mit diesem Befehl neu erstellt:
Code: 
openvpn --genkey --secret ta.key

Die Datei ta.key ist in Kopie auf dem Client, und der Inhalt von ta.key ist in das WebUI von OpenVPN unter "static.key" kopiert.

Die Fehlermeldung ist erst dann weg, wenn ich im WebUI die "TLS Authentifizierung" deaktiviere.

Interessant ist in diesem Zusammenhang, dass diese Fehlermeldung
Code: 
TLS Error: cannot locate HMAC in incoming packet from [AF_INET]91.89.xxx.xxx:54337
fortlaufend geschrieben wird, sobald der Dienst OpenVPN läuft.
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 573 (Mitglieder: 36, Gäste: 537)

Neueste Beiträge

Statistik des Forums

Themen
246,756
Beiträge
2,256,943
Mitglieder
374,783
Neuestes Mitglied
SoapWater
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück