Configuration Iptables Openvpn Client

Fermé
angel_reborn Messages postés 6 Date d'inscription vendredi 15 avril 2022 Statut Membre Dernière intervention 18 avril 2022 - 15 avril 2022 à 09:22
avion-f16 Messages postés 19246 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 21 avril 2024 - 18 avril 2022 à 18:23
Bonjour,

J'essaye de connecter un serveur linux à un serveur OpenVpn, mais j'ai quelques difficultés :


Sat Apr 9 16:58:39 2022 OpenVPN 2.4.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021
Sat Apr 9 16:58:39 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Sat Apr 9 16:58:39 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Apr 9 16:58:39 2022 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Apr 9 16:58:39 2022 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Apr 9 16:58:39 2022 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Apr 9 16:58:39 2022 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Apr 9 16:58:39 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:1194
Sat Apr 9 16:58:39 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 9 16:58:39 2022 UDP link local: (not bound)
Sat Apr 9 16:58:39 2022 UDP link remote: [AF_INET]X.X.X.X:1194
Sat Apr 9 16:58:39 2022 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Sat Apr 9 16:58:39 2022 TLS: Initial packet from [AF_INET]X.X.X.X:1194, sid=babe05dd 7d9eb535
Sat Apr 9 16:58:39 2022 VERIFY OK: depth=1, CN=Easy-RSA CA
Sat Apr 9 16:58:39 2022 VERIFY KU OK
Sat Apr 9 16:58:39 2022 Validating certificate extended key usage
Sat Apr 9 16:58:39 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 9 16:58:39 2022 VERIFY EKU OK
Sat Apr 9 16:58:39 2022 VERIFY OK: depth=0, CN=server
Sat Apr 9 16:59:39 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 9 16:59:39 2022 TLS Error: TLS handshake failed
Sat Apr 9 16:59:39 2022 SIGUSR1[soft,tls-error] received, process restarting
Sat Apr 9 16:59:39 2022 Restart pause, 5 second(s)


Pourriez vous m'aider ?

Si dessous mes configs :

iptables -t filter -X 
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#openvpn
iptables -t filter -A INPUT -p tcp --dport 1194 -j ACCEPT

iptables -A INPUT -i ens3 -m state --state NEW -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o ens3 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i ens3 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT




Configuration: Windows / Chrome 100.0.4896.88
A voir également:

7 réponses

avion-f16 Messages postés 19246 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 21 avril 2024 4 497
Modifié le 15 avril 2022 à 22:28
Bonjour,

Sat Apr 9 16:59:39 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 9 16:59:39 2022 TLS Error: TLS handshake failed


Cela indique un problème de connexion réseau, le handshake TLS ne peut pas se faire.
Il ne s'agit donc même pas d'un problème de certificat ou d'algorithme, ça plante bien avant.

Si on regarde à tes règles pare-feu sur la table "filter" en INPUT :

iptables -t filter -P INPUT DROP 
iptables -t filter -A INPUT -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -i ens3 -m state --state NEW -p udp --dport 1194 -j ACCEPT


Tu autorises les connexions entrantes :
1) sur 1194/tcp
2) sur 1194/udp mais uniquement avec l'état NEW

Cependant, tu n'autorises pas les trafic entrant sur 1194/udp pour les autres états.

Je t'invite à réessayer avec :

iptables -t filter -X 
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#openvpn
iptables -A INPUT -i ens3 -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o ens3 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i ens3 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT


J'ai retiré "-t filter" car c'est la table filter qui est utilisée par défaut.
1
angel_reborn Messages postés 6 Date d'inscription vendredi 15 avril 2022 Statut Membre Dernière intervention 18 avril 2022
16 avril 2022 à 08:52
Hello,
Merci pour ton retour. Malheureusement j'ai encore le meme resultat :

Sat Apr 16 06:19:36 2022 OpenVPN 2.4.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021
Sat Apr 16 06:19:36 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Sat Apr 16 06:19:36 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Apr 16 06:19:36 2022 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Apr 16 06:19:36 2022 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Sat Apr 16 06:19:36 2022 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Apr 16 06:19:36 2022 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Apr 16 06:19:36 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:19:36 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 16 06:19:36 2022 UDP link local: (not bound)
Sat Apr 16 06:19:36 2022 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:19:36 2022 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Sat Apr 16 06:19:36 2022 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1194, sid=f52b39eb 9ffa7792
Sat Apr 16 06:19:36 2022 VERIFY OK: depth=1, CN=Easy-RSA CA
Sat Apr 16 06:19:36 2022 VERIFY KU OK
Sat Apr 16 06:19:36 2022 Validating certificate extended key usage
Sat Apr 16 06:19:36 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 16 06:19:36 2022 VERIFY EKU OK
Sat Apr 16 06:19:36 2022 VERIFY OK: depth=0, CN=server
Sat Apr 16 06:20:36 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 16 06:20:36 2022 TLS Error: TLS handshake failed
Sat Apr 16 06:20:36 2022 SIGUSR1[soft,tls-error] received, process restarting
Sat Apr 16 06:20:36 2022 Restart pause, 5 second(s)
Sat Apr 16 06:20:41 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Apr 16 06:20:41 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:20:41 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 16 06:20:41 2022 UDP link local: (not bound)
Sat Apr 16 06:20:41 2022 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:20:41 2022 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1194, sid=3824c6ba 8ea04fee
Sat Apr 16 06:20:41 2022 VERIFY OK: depth=1, CN=Easy-RSA CA
Sat Apr 16 06:20:41 2022 VERIFY KU OK
Sat Apr 16 06:20:41 2022 Validating certificate extended key usage
Sat Apr 16 06:20:41 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 16 06:20:41 2022 VERIFY EKU OK
Sat Apr 16 06:20:41 2022 VERIFY OK: depth=0, CN=server
Sat Apr 16 06:21:41 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 16 06:21:41 2022 TLS Error: TLS handshake failed
Sat Apr 16 06:21:41 2022 SIGUSR1[soft,tls-error] received, process restarting
Sat Apr 16 06:21:41 2022 Restart pause, 5 second(s)


J'arrive à connecter les appareils sous windows et android à ce vpn, mais pas ce serveur Linux. Ce serveur utilise systemd-resolved pour traiter la résolution DNS :

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search openstacklocal


J'ai essayé d'en tenir dans le certificat. Ci-dessous le contenu du fichier :

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
dev tun


# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote XXX.XXX.XXX.XXX 1194


# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup

# Try to preserve some state across restarts.
persist-key
persist-tun

# Verify server certificate by checking that the
# certicate has the correct key usage set.
remote-cert-tls server

# Select a cryptographic cipher.
cipher AES-256-GCM
auth SHA256

# Set log file verbosity.
verb 3

#key direction directive
key-direction 1

#systemd-resolved config
script-security 2
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
down-pre
dhcp-option DOMAIN-ROUTE .

<ca>
-----BEGIN CERTIFICATE-----
........
</ca>

<cert>
......
</cert>

<key>
.......
</key>

<tls-crypt>
......................
</tls-crypt>
0
angel_reborn Messages postés 6 Date d'inscription vendredi 15 avril 2022 Statut Membre Dernière intervention 18 avril 2022
16 avril 2022 à 14:23
Hello,
Merci pour ton retour. Malheureusement j'ai encore le meme resultat :

Sat Apr 16 06:19:36 2022 OpenVPN 2.4.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021
Sat Apr 16 06:19:36 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Sat Apr 16 06:19:36 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Apr 16 06:19:36 2022 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Apr 16 06:19:36 2022 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Sat Apr 16 06:19:36 2022 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Apr 16 06:19:36 2022 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Apr 16 06:19:36 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:19:36 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 16 06:19:36 2022 UDP link local: (not bound)
Sat Apr 16 06:19:36 2022 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:19:36 2022 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Sat Apr 16 06:19:36 2022 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1194, sid=f52b39eb 9ffa7792
Sat Apr 16 06:19:36 2022 VERIFY OK: depth=1, CN=Easy-RSA CA
Sat Apr 16 06:19:36 2022 VERIFY KU OK
Sat Apr 16 06:19:36 2022 Validating certificate extended key usage
Sat Apr 16 06:19:36 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 16 06:19:36 2022 VERIFY EKU OK
Sat Apr 16 06:19:36 2022 VERIFY OK: depth=0, CN=server
Sat Apr 16 06:20:36 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 16 06:20:36 2022 TLS Error: TLS handshake failed
Sat Apr 16 06:20:36 2022 SIGUSR1[soft,tls-error] received, process restarting
Sat Apr 16 06:20:36 2022 Restart pause, 5 second(s)
Sat Apr 16 06:20:41 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Apr 16 06:20:41 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:20:41 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 16 06:20:41 2022 UDP link local: (not bound)
Sat Apr 16 06:20:41 2022 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1194
Sat Apr 16 06:20:41 2022 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1194, sid=3824c6ba 8ea04fee
Sat Apr 16 06:20:41 2022 VERIFY OK: depth=1, CN=Easy-RSA CA
Sat Apr 16 06:20:41 2022 VERIFY KU OK
Sat Apr 16 06:20:41 2022 Validating certificate extended key usage
Sat Apr 16 06:20:41 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 16 06:20:41 2022 VERIFY EKU OK
Sat Apr 16 06:20:41 2022 VERIFY OK: depth=0, CN=server
Sat Apr 16 06:21:41 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr 16 06:21:41 2022 TLS Error: TLS handshake failed
Sat Apr 16 06:21:41 2022 SIGUSR1[soft,tls-error] received, process restarting
Sat Apr 16 06:21:41 2022 Restart pause, 5 second(s)
0
angel_reborn Messages postés 6 Date d'inscription vendredi 15 avril 2022 Statut Membre Dernière intervention 18 avril 2022
16 avril 2022 à 14:25
J'arrive à connecter les appareils sous windows et android à ce vpn, mais pas ce serveur Linux. Ce serveur utilise systemd-resolved pour traiter la résolution DNS :

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search openstacklocal
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
angel_reborn Messages postés 6 Date d'inscription vendredi 15 avril 2022 Statut Membre Dernière intervention 18 avril 2022
16 avril 2022 à 14:29
J'ai essayé d'en tenir dans le certificat. Ci-dessous le contenu du fichier :

client
dev tun
proto udp
remote XXX.XXX.XXX.XXX 1194

resolv-retry infinite
nobind
user nobody
group nogroup

persist-key
persist-tun

remote-cert-tls server

cipher AES-256-GCM
auth SHA256

verb 3

key-direction 1

#systemd-resolved config
script-security 2
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
down-pre
dhcp-option DOMAIN-ROUTE .
0
avion-f16 Messages postés 19246 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 21 avril 2024 4 497
Modifié le 17 avril 2022 à 14:35
Bonjour,

Le problème rencontré concerne un problème de communication au niveau TCP ou UDP et indique donc un problème de firewall, il n'est pas nécessaire de regarder du côté des certifications et encore moins des DNS.
https://openvpn.net/faq/tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity/

Confirmes-tu que les règles iptables données, sont celles que tu appliques sur le serveur ?
Par ailleurs, en INPUT, tu autorises les connexions NEW mais les autres (ESTABLISHED, RELATED) restent bloquées.

Peux-tu essayer en désactivant les filtres iptables et en conservant uniquement les règles NAT ?
0
angel_reborn Messages postés 6 Date d'inscription vendredi 15 avril 2022 Statut Membre Dernière intervention 18 avril 2022
18 avril 2022 à 14:14
Bonjour,
j'ai fait le test en desactivant les filtres iptables et j'obtiens la meme erreur. Ci-dessous, mes configurations iptables après avoir tenu compte de tes premières remarques :

iptables -t filter -F
iptables -t filter -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

# strategie (-P) par defaut : bloc tout l'entrant le forward et autorise le sortant
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT


# Loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

# Permettre a une connexion ouverte de recevoir du trafic en entree
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ICMP
iptables -t filter -A INPUT -p icmp -j DROP

# DNS:53
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT


#openvpn
iptables -A INPUT -i ens3 -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o ens3 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE
iptables -A OUTPUT -o tun0 -j ACCEPT
0
avion-f16 Messages postés 19246 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 21 avril 2024 4 497
18 avril 2022 à 18:23
Bonjour,

Je ne vois rien dans ces règles (côté serveur) qui pourrait empêcher la connexion au serveur OpenVPN.
D'ailleurs, tu as indiqué que la connexion s'établit bien depuis un autre client.

Il faut donc plutôt se pencher sur d'éventuelles restrictions pare-feu du côté de ce client.
Depuis le client, par exemple :
nc -w 5 -u portquiz.net 1194


Si au bout de 5 secondes il ne se passe rien (pas de "timed out", pas de "connection closed"), alors cela indique que le client peut établir une connexion sur le port 1194/udp vers un service externe.
Si une de ces erreurs se produit, ça indique un blocage au niveau du pare-feu côté client (soit celui de l'OS, soit son réseau).
0