openvpn WARNUNG: Es wurde keine Überprüfungsmethode für Serverzertifikate aktiviert

9

Ich habe versucht, openvpn auf Debian Squeez (Server) zu installieren und von meinem Fedora 17 als (Client) eine Verbindung herzustellen. Hier ist meine Konfiguration:

Serverkonfiguration

# Server TCP
proto tcp
port 1194
dev tun

# Keys and certificates
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

# Network
# Virtual address of the VPN network
server 192.170.70.0 255.255.255.0
# This line adds the client to the router network server
push "route 192.168.1.0 255.255.255.0"
# Create a route server to the tun interface
#route 192.170.70.0 255.255.255.0

# Security
keepalive 10 120
# type of data encryption
cipher AES-128-CBC
# enabling compression
comp-lzo
# maximum number of clients allowed
max-clients 10
# no user and group specific to the use of the VPN
user nobody
group nogroup

# to make persistent connection
persist-key
persist-tun

# Log of the OpenVPN status
status /var/log/openvpn-status.log

# logs openvpnlog /var/log/openvpn.log
log-append /var/log/openvpn.log

# verbosity
verb 5

Client-Konfiguration

client
dev tun
proto tcp-client
remote <my server wan IP> 1194
resolv-retry infinite
cipher AES-128-CBC

# Keys
ca ca.crt
cert client.crt
key client.key

# Security
nobind
persist-key
persist-tun
comp-lzo
verb 3

Nachricht vom Host-Client (Fedora 17) in der Protokolldatei /var/log/messages:

Dec  6 21:56:00 GlobalTIC NetworkManager[691]: <info> Starting VPN service 'openvpn'...
Dec  6 21:56:00 GlobalTIC NetworkManager[691]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 7470
Dec  6 21:56:00 GlobalTIC NetworkManager[691]: <info> VPN service 'openvpn' appeared; activating connections
Dec  6 21:56:00 GlobalTIC NetworkManager[691]: <info> VPN plugin state changed: starting (3)
Dec  6 21:56:01 GlobalTIC NetworkManager[691]: <info> VPN connection 'Connexion VPN 1' (Connect) reply received.
Dec  6 21:56:01 GlobalTIC nm-openvpn[7472]: OpenVPN 2.2.2 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Sep  5 2012
Dec  6 21:56:01 GlobalTIC nm-openvpn[7472]:[COLOR="Red"][U][B] WARNING: No server certificate verification method has been enabled.[/B][/U][/COLOR]  See http://openvpn.net/howto.html#mitm for more info.
Dec  6 21:56:01 GlobalTIC nm-openvpn[7472]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec  6 21:56:01 GlobalTIC nm-openvpn[7472]:[COLOR="Red"] WARNING: file '/home/login/client/client.key' is group or others accessible[/COLOR]
Dec  6 21:56:01 GlobalTIC nm-openvpn[7472]: UDPv4 link local: [undef]
Dec  6 21:56:01 GlobalTIC nm-openvpn[7472]: UDPv4 link remote: [COLOR="Red"]<my server wan IP>[/COLOR]:1194
Dec  6 21:56:01 GlobalTIC nm-openvpn[7472]: [COLOR="Red"]read UDPv4 [ECONNREFUSED]: Connection refused (code=111)[/COLOR]
Dec  6 21:56:03 GlobalTIC nm-openvpn[7472]: [COLOR="Red"]read UDPv4[/COLOR] [ECONNREFUSED]: Connection refused (code=111)
Dec  6 21:56:07 GlobalTIC nm-openvpn[7472]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Dec  6 21:56:15 GlobalTIC nm-openvpn[7472]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Dec  6 21:56:31 GlobalTIC nm-openvpn[7472]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Dec  6 21:56:41 GlobalTIC NetworkManager[691]: <warn> VPN connection 'Connexion VPN 1' (IP Conf[/CODE]

ifconfig auf dem Serverhost (debian):

ifconfig 
eth0      Link encap:Ethernet  HWaddr 08:00:27:16:21:ac  
          inet addr:192.168.1.6  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe16:21ac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9059 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5660 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:919427 (897.8 KiB)  TX bytes:1273891 (1.2 MiB)
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.170.70.1  P-t-P:192.170.70.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ifconfig auf dem Client-Host (Fedora 17)

as0t0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 5.5.0.1  netmask 255.255.252.0  destination 5.5.0.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 200  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 321 (321.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

as0t1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 5.5.4.1  netmask 255.255.252.0  destination 5.5.4.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 200  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 321 (321.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

as0t2: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 5.5.8.1  netmask 255.255.252.0  destination 5.5.8.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 200  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 321 (321.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

as0t3: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 5.5.12.1  netmask 255.255.252.0  destination 5.5.12.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 200  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 321 (321.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

**p255p1**: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.2  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::21d:baff:fe20:b7e6  prefixlen 64  scopeid 0x20<link>
        ether 00:1d:ba:20:b7:e6  txqueuelen 1000  (Ethernet)
        RX packets 4842070  bytes 3579798184 (3.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3996158  bytes 2436442882 (2.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16

p255p1 ist die Bezeichnung für die eth0-Schnittstelle

und

auf dem Server:

root@hoteserver:/etc/openvpn# tree
.
├── client
│** ├── ca.crt
│** ├── client.conf
│** ├── client.crt
│** ├── client.csr
│** ├── client.key
│** ├── client.ovpn
│*
│** 
├── easy-rsa
│** ├── build-ca
│** ├── build-dh
│** ├── build-inter
│** ├── build-key
│** ├── build-key-pass
│** ├── build-key-pkcs12
│** ├── build-key-server
│** ├── build-req
│** ├── build-req-pass
│** ├── clean-all
│** ├── inherit-inter
│** ├── keys
│** │** ├── 01.pem
│** │** ├── 02.pem
│** │** ├── ca.crt
│** │** ├── ca.key
│** │** ├── client.crt
│** │** ├── client.csr
│** │** ├── client.key
│** │** ├── dh1024.pem
│** │** ├── index.txt
│** │** ├── index.txt.attr
│** │** ├── index.txt.attr.old
│** │** ├── index.txt.old
│** │** ├── serial
│** │** ├── serial.old
│** │** ├── server.crt
│** │** ├── server.csr
│** │** └── server.key
│** ├── list-crl
│** ├── Makefile
│** ├── openssl-0.9.6.cnf.gz
│** ├── openssl.cnf
│** ├── pkitool
│** ├── README.gz
│** ├── revoke-full
│** ├── sign-req
│** ├── vars
│** └── whichopensslcnf
├── openvpn.log
├── openvpn-status.log
├── server.conf
└── update-resolv-conf

auf dem Client:

[login@hoteclient openvpn]$ tree 
.
|-- easy-rsa
|   |-- 1.0
|   |   |-- build-ca
|   |   |-- build-dh
|   |   |-- build-inter
|   |   |-- build-key
|   |   |-- build-key-pass
|   |   |-- build-key-pkcs12
|   |   |-- build-key-server
|   |   |-- build-req
|   |   |-- build-req-pass
|   |   |-- clean-all
|   |   |-- list-crl
|   |   |-- make-crl
|   |   |-- openssl.cnf
|   |   |-- README
|   |   |-- revoke-crt
|   |   |-- revoke-full
|   |   |-- sign-req
|   |   `-- vars
|   `-- 2.0
|       |-- build-ca
|       |-- build-dh
|       |-- build-inter
|       |-- build-key
|       |-- build-key-pass
|       |-- build-key-pkcs12
|       |-- build-key-server
|       |-- build-req
|       |-- build-req-pass
|       |-- clean-all
|       |-- inherit-inter
|       |-- keys [error opening dir]
|       |-- list-crl
|       |-- Makefile
|       |-- openssl-0.9.6.cnf
|       |-- openssl-0.9.8.cnf
|       |-- openssl-1.0.0.cnf
|       |-- pkitool
|       |-- README
|       |-- revoke-full
|       |-- sign-req
|       |-- vars
|       `-- whichopensslcnf
|-- keys -> ./easy-rsa/2.0/keys/
`-- server.conf

Ist die Quelle des Problems cipher AES-128-CBC, proto tcp-clientoder UDP oder die Schnittstelle p255p1auf Fedora17 oder dass Dateiauthentifikations ta.keynicht gefunden wird ?

debian fedora openvpn tmedtcom
quelle

Antworten:

2

Zuerst sollten Sie die Berechtigungen für Ihre /home/login/client/client.keyDatei so ändern , dass sie nicht für Gruppen oder andere zugänglich ist.

chmod 400 /home/login/client/client.key

Dann sollten Sie, wie hier beschrieben , eine Methode implementieren, um zu überprüfen, ob Ihre Clients eine Verbindung zum richtigen Server herstellen und kein Man-in-Middle-Angriff möglich ist.

teissler
quelle
2
Es wird schön sein, wenn Sie die Lösung hier
posten
1

Hier finden Sie eine vollständige Liste der Probleme, und Sie sollten die von OpenVPN gegebenen Warnungen ernst nehmen. Es gibt jedoch nur Warnungen und nicht den Grund für Ihr Problem, eine Verbindung herzustellen. Das openvpn-Plugin von NetworkManager versucht, eine Verbindung über UDP herzustellen. Ich weiß nicht, welche Beziehung Ihre client.conf zu Ihrer tatsächlichen Client-Konfiguration hat. Wurde es verwendet, um die VPN-Einstellungen in NetworkManager zu importieren?
Auf jeden Fall müssen Sie das Kontrollkästchen TCP-Verbindung im Dialogfeld für erweiterte Einstellungen Ihres VPN-Verbindungsprofils aktivieren.
Da Sie tls-auth weder auf der Client- noch auf der Serverseite zu verwenden scheinen, sollte keine ta.key-Datei fehlen (die Verwendung von tls-auth ist jedoch eine gute Idee).
Die Chiffre scheint auf beiden Seiten gleich zu sein und sollte kein Problem sein.
Ich wirklich empfehlen dringend zuÜberprüfen Sie das Serverzertifikat , wie von morlix angegeben.

Enno Gröper
quelle
1

Um die No server certificate verification method has been enabledWarnung zu entfernen, generieren Sie Ihre Client- und Serverzertifikate mit der richtigen extendedKeyUsageErweiterung und fügen Sie remote-cert-tls serversie dem Client hinzu openvpn.conf.

Fügen Sie Ihren Zertifizierungsstellen zwei Abschnitte hinzu openssl.cnf:

[server_cert]
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[client_cert]
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

Signieren Sie Serverzertifikate bei Ihrer Zertifizierungsstelle wie folgt:

openssl ca -config openssl.cnf -extensions server_cert -notext -md sha256 -in csr.pem -out cert.pem

Unterzeichnen Sie Client-Zertifikate wie folgt:

openssl ca -config openssl.cnf -extensions client_cert -notext -md sha256 -in csr.pem -out cert.pem

Fügen Sie dann in Ihrem Kunden openvpn.cnfdie folgende Zeile hinzu:

remote-cert-tls server

und starten Sie den openvpn-Dienst neu.

jcoffland
quelle