Question OpenVPN échouant sur le certificat auto-signé sur udp, fonctionne sur tcp


J'ai le server.conf suivant:

# OpenVPN 2.x config

proto tcp

port 1194
dev tun-vpn
dev-type tun

server 10.8.0.0 255.255.0.0
push "route 172.16.0.0 255.255.0.0"
push "dhcp-option DOMAIN mydom.com"
push "dhcp-option DNS 172.16.1.1"

# 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
tls-server

# Diffie hellman parameters
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

# Connection settings
comp-lzo
ping 10
ping-restart 120

# Server security
persist-key
persist-tun
user nobody
group nogroup

# Logging
status openvpn-status.log
verb 4
mute 10

Et la configuration client suivante:

# OpenVPN 2.x client config
client

dev tun

proto tcp

remote vpn.mydom.com 1194

resolv-retry infinite

nobind

persist-key
persist-tun

mute-replay-warnings

ca ca.crt
cert michaelc.crt
key michaelc.key

#ns-cert-type server

comp-lzo
ping 10
ping-restart 60

verb 3

Ces configurations fonctionnent bien, mais si je veux utiliser UDP au lieu de TCP, j'obtiens le journal suivant:

Thu May 24 22:30:16 2012 UDPv4 link local: [undef]
Thu May 24 22:30:16 2012 UDPv4 link remote: [AF_INET]x.x.x.x:1194
Thu May 24 22:30:16 2012 TLS: Initial packet from [AF_INET]x.x.x.x:1194, sid=e63bd705 392de807
Thu May 24 22:30:16 2012 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: /C=NL/ST=Zuid_Holland/L=_s-Gravendeel/O=Visser__s-Gravendeel_Holding_B.V./CN=Visser__s-Gravendeel_Holding_B.V._CA/emailAddress=hostmaster@visser.eu
Thu May 24 22:30:16 2012 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Thu May 24 22:30:16 2012 TLS Error: TLS object -> incoming plaintext read error
Thu May 24 22:30:16 2012 TLS Error: TLS handshake failed
Thu May 24 22:30:16 2012 TCP/UDP: Closing socket
Thu May 24 22:30:16 2012 SIGUSR1[soft,tls-error] received, process restarting
Thu May 24 22:30:16 2012 Restart pause, 2 second(s)

J'ai vérifié les certificats par rapport à ca.crt, et server.crt et michaelc.crt sont des certificats valides signés avec ca.crt.

De plus, comme ils fonctionnent sur TCP, je suppose que les certificats sont parfaitement valides. J'imagine que la connexion est mauvaise (bien qu'il s'agisse de DSL d'un côté et de fibre optique de l'autre), mais est-ce réparable? J'ai également essayé de générer de nouveaux certificats (CA, serveur et client), mais cela donne exactement la même erreur. J'espère que quelqu'un pourra me donner des indices.


6
2018-05-24 20:52


origine


Ce journal provient-il du client ou du serveur? Où se situe ce certificat dans: /C=NL/ST=Zuid_Holland/L=_s-Gravendeel/O=Visser__s-Gravendeel_Holding_B.V./CN=Visser__s-Gravendeel_Holding_B.V._CA/emailAddress=hostmaster@visser.eu? - mgorven
C'est un journal du client, le certificat est le certificat de l'autorité de certification (qui est auto-signé), qui fonctionne avec TCP. - mycroes
Cela implique que le client ne vérifie pas le certificat du serveur par rapport à l'autorité de certification. Qu'est-ce que le système d'exploitation client et comment exécutez-vous le client OpenVPN (par exemple, le script d'initiation Ubuntu, en exécutant openvpn directement)? - mgorven
Essayé sous Ubuntu Linux et Windows 7, sous Ubuntu avec exécution manuelle (openvpn --config michaelc.conf) et sous Windows avec openvpn et openvpn-mi-gui. En fait, cela signifie qu'il ne peut pas vérifier l'autorité de certification, ce qui, à mon avis, devrait être A. non nécessaire B. être identique lors de l'utilisation de TCP ... - mycroes


Réponses:


Heureusement, j'ai compris le problème, malheureusement c'était ma propre erreur. Il y a peu de temps, je testais VPN sur UDP sur un autre serveur. Les connexions UDP sur le port 1194 étaient donc redirigées vers l'autre serveur. L’autre serveur avait toujours OpenVPN en cours d’exécution, avec un certificat très similaire. Donc, en fait, l'erreur était correcte et était causée par la connexion à un autre serveur lors de la connexion à l'aide du protocole UDP. Bien que je me sente stupide de faire cette erreur, je suis heureux d’avoir compris ce qui ne va pas.


2
2018-05-31 18:10