Tutoriel OpenVPN: installation, configuration du serveur VPN et connexion

Qu’est-ce que c’est?

OpenVPN est un logiciel basé sur un logiciel gratuit qui nous permet de construire un réseau privé virtuel (VPN), pour se connecter à distance au serveur. Ce logiciel nous permet de configurer deux types d'architectures VPN:

• Accès à distance VPN: Nous avons un serveur VPN central et plusieurs clients VPN avec le logiciel installé sur votre ordinateur, smartphone, tablette ou autre appareil, et ils se connectent tous de manière centralisée au serveur VPN.
• VPN de site à site: cette architecture nous permet d'intercommuniquer entre différents sites pour partager des ressources via un réseau sécurisé, protégé par un cryptage de bout en bout. Ce type de VPN nous permet d'intercommuniquer des bureaux, des sièges sociaux, etc.

Certaines caractéristiques très importantes d'OpenVPN sont qu'il prend en charge une configuration étendue, à la fois pour améliorer les performances et la sécurité. Il est basé sur SSL / TLS, par conséquent, nous pouvons créer des certificats numériques pour l'authentification des clients VPN.De plus, nous pourrions également nous authentifier avec des certificats plus un nom d'utilisateur / mot de passe que nous ajoutons au système. OpenVPN est beaucoup plus facile à configurer qu'IPsec, et grâce à l'excellent support de la communauté, nous pourrons trouver OpenVPN sur tous les systèmes d'exploitation de bureau, serveurs et même sur smartphones et tablettes.

Pourquoi est-ce?

Si nous créons un serveur OpenVPN chez nous, cela peut nous aider à nous connecter à Internet dans un manière sécurisée de n'importe quel réseau, qu'il soit filaire ou WiFi, avec cryptage WEP / WPA ou sans cryptage. Tout le trafic sera chiffré via un tunnel de notre ordinateur où nous nous connectons à notre maison et de là, il ira à Internet, c'est comme être connecté à Internet à la maison. Nous devons prendre en compte plusieurs facteurs, comme avoir une bonne vitesse de téléchargement (30 Mbps ou plus), et avoir une adresse IP publique chez nous, car si nous avons CG-NAT nous ne pourrons pas nous connecter car nous ne le serons pas. capable de faire la redirection de port dans le routeur.

En installant un serveur OpenVPN chez nous, nous pouvons également accéder à chacune des ressources partagées que nous avons, telles que les serveurs Samba, FTP et même accéder à l'imprimante, aux caméras IP que nous avons connectées, etc. Tous les permis d'accès seraient comme si nous étions physiquement chez nous. OpenVPN est une solution pour VPN qui implémente des connexions de couche 2 ou 3, selon le mode de connexion choisi, cela fonctionnera d'une manière ou d'une autre, en outre, un détail important est que la grande majorité des systèmes d'exploitation prennent aujourd'hui en charge OpenVPN, bien que non il est généralement incorporé par les fabricants de matériel pour les pare-feu ou les routeurs.

OpenVPN utilise un ensemble de protocoles SSL / TLS qui fonctionnent au niveau de la couche de transport, et nous avons deux types d'opérations:

• TUN : Les TUN Le contrôleur émule un périphérique point à point, il est utilisé pour créer tunnels virtuels fonctionnant avec le protocole IP . De cette façon, tous les paquets qui y sont transportés peuvent être encapsulés sous forme de segments TCP ou de datagrammes UDP (plus tard vous verrez que nous choisissons UDP au lieu de TCP, et vous vous demanderez pourquoi, puisque TCP est connectif, fiable et orienté vers Connection ). Les machines derrière chaque extrémité du lien appartiendront à différents sous-réseaux.
• TAP : Simule une interface réseau Ethernet, plus communément appelée mode pont ou pont, ces tunnels virtuels encapsule directement les paquets Ethernet . Cette situation permet de conditionner des tissus différents de ceux IP. Les machines situées derrière chaque extrémité du lien peuvent fonctionner dans le cadre du même sous-réseau (si le protocole IP est utilisé). Le mode de fonctionnement du pont est particulièrement utile pour relier les utilisateurs distants, car ils peuvent se connecter au même serveur et faire pratiquement partie du réseau principal, cependant, si le réseau privé où est connecté l'origine coïncide avec la destination, nous aurons des problèmes de routage et la communication ne fonctionnera pas.

Dans le manuel, nous utiliserons TUN et verrons comment nous créons un sous-réseau virtuel 10.8.0.0/24 où les clients OpenVPN seront lorsqu'ils se connecteront. De cette manière, il sera beaucoup plus facile d'identifier les clients VPN que nous avons connectés au réseau local.

Dans ce manuel, je vais vous expliquer comment le faire en GNU / Linux (dans Debian 10) , bien que pour l'essentiel, il en soit de même pour Windows , uniquement les commandes de la console (cmd.exe), les certificats et les clés changent, ils sont les mêmes pour les deux , c'est-à-dire que vous pouvez TOUT créer en GNU / Linux puis passez-le à Windows pour l'utiliser (client ou serveur), il suffit de changer le serveur client extension .conf à .ovpn , bien que dans les dernières versions, OpenVPN pour Windows nous permette déjà de reconnaître et d'utiliser les fichiers de configuration .conf, nous n'aurons donc pas à changer l'extension.

Dans ce manuel, je vais vous montrer comment créer une configuration OpenVPN très sécurisée, en personnalisant les algorithmes de cryptage symétrique, asymétrique et de hachage. De cette manière, nous pouvons avoir le meilleur cryptage possible des communications.

Résumé de la cryptographie à utiliser

• Certificats numériques : Nous utiliserons EC (courbes elliptiques) pour la création du Infrastructure à clé publique . Nous créerons à la fois les certificats du CA (Autorité de Certification), ainsi que les certificats du serveur et des clients VPN qui souhaitent se connecter. L'algorithme EC utilisé est secp521r1, bien que nous en ayons beaucoup d'autres disponibles. L'algorithme de hachage que nous utiliserons sera SHA512 . Un détail important est que tous les clients / serveurs OpenVPN ne le prennent pas en charge, nous devons mettre à jour nos bibliothèques OpenVPN et cryptographiques, mais de nos jours il est rare de se retrouver dans un scénario qui n'est pas compatible.
• Canal de contrôle OpenVPN : nous utiliserons au moins TLS 1.2, et toujours en utilisant PFS (Perfect Forward Secrecy) basé sur Diffie-Hellmann avec des courbes elliptiques (ECDHE). Autrement dit, nous utiliserons une sélection de suites cryptographiques sécurisées, telles que TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384. Si vous voulez vérifier si votre serveur ou client prend en charge ce type de cryptage, vous devez mettre dans la console «openvpn –show-tls».
• Canal de données OpenVPN : Nous utiliserons le AES-256-GCM algorithme de cryptage symétrique, le plus sécurisé actuellement et qui a été intégré dans OpenVPN 2.4 et versions ultérieures. Si vous souhaitez vérifier si votre serveur ou client supporte ce type de cryptage, vous devez mettre dans la console « openvpn – afficher les chiffrements «. Si nous utilisons AES-256-GCM comme cryptage de canal de données, nous n'utiliserons aucun algorithme HASH puisqu'il s'agit d'AEAD, cependant, si nous utilisons AES-256-CBC, nous utiliserons SHA512.

En plus de ces mesures de sécurité, nous inclurons une signature HMAC supplémentaire pour la première négociation TLS, de cette manière, nous protégerons le système contre d'éventuelles attaques par déni de service, des attaques par inondation de port UDP et également des attaques TCP SYN. Lors de la connexion au serveur, si le client ne possède pas la signature HMAC correcte, il sera bloqué. Dans les versions précédentes d'OpenVPN 2.4, la directive était authentification tls , qui était uniquement responsable de l'authentification d'une clé pré-partagée générée par OpenVPN lui-même. Maintenant dans les versions supérieures à OpenVPN 2.4, il s'appelle crypte-tls , la principale différence est qu'en plus de l'authentification, il crypte également le canal afin que personne ne puisse capturer ladite clé pré-partagée. La configuration est très similaire, la génération de la clé est exactement la même dans les deux.

Enfin, nous utiliserons le protocole UDP au lieu de TCP, car il est plus résistant aux attaques par déni de service, il faut se rappeler que UDP est non connectif, peu fiable et orienté connexion. Cependant, nous pouvons utiliser TCP sans aucun problème pour fournir au VPN tous les avantages de ce protocole.

Étapes à suivre pour travailler avec OpenVPN

Ci-dessous, vous pourrez voir en détail comment installer ce logiciel, ainsi que tout ce dont vous avez besoin pour le démarrer avec la meilleure sécurité possible fournie par cette solution pour créer un réseau privé virtuel.

Téléchargez et installez

La première chose que nous devons faire est d'installer OpenVPN sur notre ordinateur, que ce soit avec Windows ou Linux. Si vous utilisez Windows, vous devez accéder au site officiel de téléchargement OpenVPN et installez tout dans l'assistant d'installation. Si vous utilisez un système d'exploitation comme Debian (nous utiliserons Debian 10 tout au long de ce manuel), vous devrez entrer la commande suivante:

sudo apt update

sudo apt installer openvpn

Téléchargement Easy-RSA 3 pour les certificats

Une fois installé, il faut télécharger le progiciel Easy-RSA 3, ce progiciel permet de créer des certificats numériques facilement et rapidement. On peut modifier la longueur de la clé, le type de clé, si l'on veut mettre un mot de passe sur les clés privées etc. site officiel du projet Easy-RSA 3 sur GitHub vous avez toutes les informations et la possibilité de télécharger un .zip avec tout.

Si vous êtes sur un système Linux, nous vous recommandons d'utiliser la commande wget pour télécharger le fichier .zip:

wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.8/EasyRSA-3.0.8.tgz

Ensuite, nous devons décompresser ce fichier téléchargé et entrer dans le dossier pour commencer à configurer le fichier vars.

tar -zxvf EasyRSA-3.0.8.tgz

Configurer Easy-RSA 3 «vars»

Le vars.exemple Le fichier est le centre de toute la configuration des certificats, c'est là que nous devons définir si nous voulons créer des certificats basés sur RSA ou basés sur EC. De même, cela nous permettra également de signer les certificats avec SHA256 ou SHA512 entre autres. Autrement dit, nous devons configurer correctement ce fichier de configuration pour créer ultérieurement les certificats numériques.

La première chose que nous devons faire est de copier le fichier vars.example dans le même dossier avec le nom «vars», si nous ne l'avons pas avec ce nom «vars» cela ne fonctionnera pas. Nous avons également la possibilité de renommer le fichier vars.example en «vars», mais nous vous recommandons de faire une sauvegarde au cas où vous supprimeriez quelque chose et que cela ne fonctionnerait pas pour vous.

Nous allons dans le dossier principal d'Easy-RSA3 et copions le fichier de cette manière:

cp vars.example vars

Une fois que nous avons le fichier «vars», nous devons le modifier avec n'importe quel éditeur de fichier via la console ou l'interface graphique, nous utiliserons nano en raison de sa facilité. Dans le fichier de configuration «vars» suivant, vous pouvez voir à quoi ressemblerait EC avec l'algorithme secp521r1, signé avec SHA512 et nous avons utilisé un DN (Distinguished Name) mettant le CN (Common Name) au lieu des «données d'organisation» typiques. nous l'avons toujours fait auparavant, de cette manière, nous facilitons la création de certificats, mais nous pourrions également le faire en indiquant les données d'organisation typiques.

Dans le fichier lui-même se trouvent les commentaires originaux en anglais, et en espagnol nous avons mis les nôtres pour faciliter la localisation de ce qui doit être modifié. Un détail très important, WordPress met automatiquement ces symboles << et >> alors qu'il devrait simplement mettre des guillemets doubles: »

# Réglages des paramètres Easy-RSA 3

# REMARQUE: si vous avez installé Easy-RSA à partir du gestionnaire de paquets de votre distribution, ne modifiez pas
# ce fichier en place - à la place, vous devez copier tout le répertoire easy-rsa
# vers un autre emplacement afin que les futures mises à jour n'effacent pas vos modifications.

# COMMENT UTILISER CE FICHIER
#
# vars.example contient des exemples intégrés aux paramètres Easy-RSA. Vous DEVEZ nommer
# ce fichier 'vars' si vous voulez qu'il soit utilisé comme fichier de configuration. Si tu fais
# non, il ne sera PAS lu automatiquement lorsque vous appelez les commandes easyrsa.
#
# Il n'est pas nécessaire d'utiliser ce fichier de configuration sauf si vous souhaitez changer
# défauts opérationnels. Ces valeurs par défaut devraient convenir à de nombreuses utilisations sans
# besoin de copier et d'éditer le fichier 'vars'.
#
# Tous les paramètres modifiables sont affichés commentés et commencent par la commande
# 'set_var' - cela signifie que toute commande set_var qui n'est pas commentée a été
# modifié par l'utilisateur. Si vous êtes satisfait d'un défaut, il n'est pas nécessaire de
# définir la valeur par défaut.

# REMARQUES POUR LES UTILISATEURS DE WINDOWS
#
# Les chemins pour Windows * DOIVENT * utiliser des barres obliques, ou éventuellement doublés
# des barres obliques inverses (des barres obliques simples sont recommandées.) Cela signifie votre chemin vers
# le binaire openssl pourrait ressembler à ceci:
# «C: / Program Files / OpenSSL-Win32 / bin / openssl.exe»

# Un peu de ménage: NE MODIFIEZ PAS CETTE SECTION
#
# Easy-RSA 3.x ne se connecte pas directement à l'environnement.
# Se plaindre si un utilisateur essaie de faire ceci:
if [-z "$ EASYRSA_CALLER"]; puis
echo "Vous semblez chercher un fichier" vars "Easy-RSA." > & 2
echo «Ce n'est plus nécessaire et est interdit. Voir la section intitulée »> & 2
echo "" Comment utiliser ce fichier "près des premiers commentaires pour plus de détails." > & 2
retour 1
fi

# FAITES VOS MODIFICATIONS SOUS CE POINT

# Cette variable est utilisée comme emplacement de base des fichiers de configuration nécessaires à
# easyrsa. Variables plus spécifiques pour des fichiers spécifiques (par exemple, EASYRSA_SSL_CONF)
# peut remplacer cette valeur par défaut.
#
# La valeur par défaut de cette variable est l'emplacement du script easyrsa
# lui-même, qui est également l'emplacement des fichiers de configuration dans le
# arbre easy-rsa.

#set_var EASYRSA "$ {0% / *}"

# Si votre commande OpenSSL n'est pas dans le PATH système, vous devrez définir le
# chemin d'accès ici. Normalement, cela signifie un chemin complet vers l'exécutable, sinon
# vous auriez pu le laisser indéfini ici et la valeur par défaut affichée serait utilisée.
#
# Utilisateurs Windows, n'oubliez pas d'utiliser les chemins avec des barres obliques (ou
# barres obliques inverses.) Les utilisateurs Windows doivent déclarer le chemin d'accès complet à openssl
# binaire ici s'il n'est pas dans leur PATH système.

#set_var EASYRSA_OPENSSL "openssl"
#
# Cet exemple est dans la syntaxe Windows - modifiez-le pour votre chemin si vous n'utilisez pas PATH:
#set_var EASYRSA_OPENSSL "C: / Program Files / OpenSSL-Win32 / bin / openssl.exe"

# Modifiez cette variable pour qu'elle pointe vers votre répertoire de clés sur le point d'être créé. Par
# par défaut, ce sera «$ PWD / pki» (c'est-à-dire le sous-répertoire «pki» du
# répertoire dans lequel vous vous trouvez actuellement).
#
# AVERTISSEMENT: init-pki fera un rm -rf sur ce répertoire donc assurez-vous de définir
# correctement! (Le mode interactif s'affiche avant d'agir.)

#set_var EASYRSA_PKI "$ PWD / pki"

# Définissez le mode DN X509.
# Ceci est utilisé pour ajuster quels éléments sont inclus dans le champ Objet en tant que DN
# (c'est le «nom distinctif».)
# Notez qu'en mode cn_only, les champs d'organisation ci-dessous ne sont pas utilisés.
#
# Les choix sont:
# cn_only - utilise juste une valeur CN
# org - utilisez le pays / province / ville / organisation / OU / «traditionnel» email / Format CN

#ELEGIMOS cn_only POUR LA CRÉATION DE CERTIFICATS

set_var EASYRSA_DN "cn_only"

# Champs organisationnels (utilisés avec le mode 'org' et ignorés en mode 'cn_only'.)
# Ce sont les valeurs par défaut des champs qui seront placés dans le
# certificat. Ne laissez aucun de ces champs vide, bien que de manière interactive
# vous pouvez omettre n'importe quel champ spécifique en tapant le «.» symbole (non valable pour
# e-mail.)

#set_var EASYRSA_REQ_COUNTRY "US"
#set_var EASYRSA_REQ_PROVINCE «Californie»
#set_var EASYRSA_REQ_CITY «San Francisco»
#set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
#set_var EASYRSA_REQ_EMAIL "me@example.net"
#set_var EASYRSA_REQ_OU «Mon unité organisationnelle»

# Choisissez une taille en bits pour vos paires de clés. La valeur recommandée est 2048. Utilisation
Les clés # 2048 bits sont considérées comme plus que suffisantes pendant de nombreuses années
# futur. Des tailles de clés plus importantes ralentiront la négociation TLS et créeront un paramètre clé / DH
# génération prend beaucoup plus de temps. Les valeurs jusqu'à 4096 devraient être acceptées par la plupart
# Logiciel. Utilisé uniquement lorsque l'alg crypto est rsa (voir ci-dessous.)

#set_var EASYRSA_KEY_SIZE 2048

# Le mode crypto par défaut est rsa; ec peut activer la prise en charge de la courbe elliptique.
# Notez que tous les logiciels ne prennent pas en charge ECC, soyez donc prudent lorsque vous l'activez.
# Les choix pour crypto alg sont: (chacun en minuscules)
# * RSA
# * ce

# NOUS CHOISISSONS LA COURBE ÉLIPTIQUE POUR LA CRÉATION DE CERTIFICATS, PAR DÉFAUT C'EST LE RSA.

set_var EASYRSA_ALGO ce

# NOUS DÉFINISSONS LE NOM DE LA COURBE ÉLIPTIQUE CHOISIE

set_var EASYRSA_CURVE secp521r1

# NOUS CONFIGURONS L'EXPIRATION DE LA CA

set_var EASYRSA_CA_EXPIRE 3650

# NOUS CONFIGURONS L'EXPIRATION DES CERTIFICATS CRÉÉS.

set_var EASYRSA_CERT_EXPIRE 1080

# Combien de jours avant la prochaine date de publication de la CRL? Notez que la CRL peut toujours être
# analysé une fois ce délai écoulé. Il n'est utilisé que pour un prochain
# date de publication.

# Combien de jours avant sa date d'expiration un certificat peut-il être
# renouvelé?
#set_var EASYRSA_CERT_RENEW 30

#set_var EASYRSA_CRL_DAYS 180

# Prise en charge des extensions «Netscape» obsolètes? (choix «oui» ou «non».) La valeur par défaut
# est «non» pour décourager l'utilisation d'extensions obsolètes. Si vous en avez besoin
# fonctionnalité à utiliser avec –ns-cert-type, définissez ceci sur «yes» ici. Ce soutien
# doit être remplacé par la fonction plus moderne –remote-cert-tls. Si tu fais
# n'utilisez pas –ns-cert-type dans vos configurations, il est prudent (et recommandé) de quitter
# ceci défini à «non». Lorsqu'il est défini sur «yes», les certificats signés par le serveur obtiennent le
# nsCertType = attribut de serveur, et obtenez également tout NS_COMMENT défini ci-dessous dans le
# champ nsCommentaire.

#set_var EASYRSA_NS_SUPPORT «non»

# Lorsque NS_SUPPORT est défini sur «yes», ce champ est ajouté en tant que champ nsComment.
# Définissez ce vide pour l'omettre. Avec NS_SUPPORT défini sur «non», ce champ est ignoré.

#set_var EASYRSA_NS_COMMENT "Certificat généré par Easy-RSA"

# Un fichier temporaire utilisé pour organiser les extensions de certificat lors de la signature. La valeur par défaut devrait
# convient à la plupart des utilisateurs; cependant, certains utilisateurs peuvent souhaiter une alternative sous un
# RAM-based FS, comme / dev / shm ou / tmp sur certains systèmes.

#set_var EASYRSA_TEMP_FILE "$ EASYRSA_PKI / extensions.temp"

# !!
# REMARQUE: OPTIONS AVANCÉES SOUS CE POINT
# JOUEZ AVEC EUX À VOS PROPRES RISQUES
# !!

# Alias ​​de commande shell cassés: si vous avez un shell largement cassé
# manquant l'une de ces commandes POSIX-requises utilisées par Easy-RSA, vous aurez besoin
# pour définir un alias vers le chemin approprié pour la commande. Le symptôme sera
# une forme d'erreur "commande introuvable" de votre shell. Cela signifie que votre
# shell est CASSÉ, mais vous pouvez le pirater ici si vous en avez vraiment besoin. estos
# les valeurs affichées ne sont pas des valeurs par défaut: c'est à vous de savoir ce que vous faites si
# vous les touchez.
#
#alias awk = »/alt/bin/awk»
#alias chat = »/ alt / bin / chat »

# Répertoire d'extensions X509:
# Si vous souhaitez personnaliser les extensions X509 utilisées, définissez le répertoire pour qu'il ressemble
# pour les extensions ici. Chaque type de certificat que vous signez doit avoir un nom de fichier correspondant,
# et un fichier facultatif nommé 'COMMON' est inclus en premier lorsqu'il est présent. Notez que
# lorsqu'il n'est pas défini ici, le comportement par défaut est de chercher d'abord dans $ EASYRSA_PKI, puis
# retour à $ EASYRSA pour le répertoire 'x509-types'. Vous pouvez remplacer cela
# détection avec un répertoire explicite ici.
#
#set_var EASYRSA_EXT_DIR "$ EASYRSA / x509-types"

# Fichier de configuration OpenSSL:
# Si vous avez besoin d'utiliser un fichier de configuration openssl spécifique, vous pouvez le référencer ici.
# Normalement, ce fichier est détecté automatiquement à partir d'un fichier nommé openssl-easyrsa.cnf depuis le
# EASYRSA_PKI ou EASYRSA dir (dans cet ordre.) Notez que ce fichier est Easy-RSA
# spécifique et vous ne pouvez pas simplement utiliser un fichier de configuration standard, il s'agit donc d'un
# fonctionnalité avancée.

#set_var EASYRSA_SSL_CONF "$ EASYRSA / openssl-easyrsa.cnf"

# CN par défaut:
# Il vaut mieux laisser cela seul. De manière interactive, vous définissez ceci manuellement, et BATCH
# appelants doivent définir ce paramètre eux-mêmes.

#set_var EASYRSA_REQ_CN «ChangeMe»

# Digest cryptographique à utiliser.
# Ne modifiez pas cette valeur par défaut si vous ne comprenez pas les implications de sécurité.
# Les choix valides incluent: md5, sha1, sha256, sha224, sha384, sha512

# NOUS AVONS SÉLECTIONNÉ LE HASH SHA512

set_var EASYRSA_DIGEST "sha512"

# Temps différé. Laissez cette option désactivée sauf si vous avez l'intention d'appeler Easy-RSA explicitement
# en mode batch sans aucune intervention de l'utilisateur, confirmation des opérations dangereuses,
# ou la plupart des sorties. Le paramétrer sur une chaîne non vide active le mode batch.

#set_var EASYRSA_BATCH « »

Une fois que nous avons tout modifié, nous sauvegardons le fichier car plus tard, nous allons l'utiliser avec ces valeurs.

Création PKI: CA, certificats serveur et client

Une fois le fichier «vars» configuré, nous procédons à la création de l'infrastructure à clé publique (PKI) avec la commande suivante (nous supposons que vous êtes toujours dans le répertoire principal d'Easy-RSA3):

./easyrsa init-pki

root @ debian-vm : /home/bron/EasyRSA-v3.0.6# ./easyrsa init-pki

Remarque: utilisation de la configuration Easy-RSA à partir de: ./vars

init-pki terminé; vous pouvez maintenant créer une autorité de certification ou des demandes.
Votre répertoire PKI nouvellement créé est: /home/bron/EasyRSA-v3.0.6/pki

Une fois la PKI initialisée, nous devons créer l'Autorité de Certification (CA):

./easyrsa build-ca

Une fois exécuté, nous devons suivre le simple assistant de génération de CA. Le mot de passe que vous nous demandez est de protéger la clé privée de l'AC, ce qui est fondamental.

root @ debian-vm : /home/bron/EasyRSA-v3.0.6# ./easyrsa build-ca

Remarque: utilisation de la configuration Easy-RSA à partir de: ./vars

Utilisation de SSL: openssl OpenSSL 1.1.1d 10 septembre 2019

Entrez la nouvelle phrase de passe de clé CA:
Entrez à nouveau la nouvelle phrase de passe de clé CA:
lire la clé EC
écriture de la clé EC
Impossible de charger /home/bron/EasyRSA-v3.0.6/pki/.rnd dans RNG
139864421569664: erreur: 2406F079: générateur de nombres aléatoires: RAND_load_file: Impossible d'ouvrir le fichier: ../ crypto / rand / randfile.c: 98: Filename = / home / bron / EasyRSA-v3.0.6 / pki / .rnd
Vous allez être invité à entrer des informations qui seront incorporées
dans votre demande de certificat.
Ce que vous êtes sur le point d'entrer est ce qu'on appelle un nom distinctif ou un DN.
Il y a pas mal de champs mais vous pouvez laisser un blanc
Pour certains champs, il y aura une valeur par défaut,
Si vous entrez «.», Le champ sera laissé vide.
-
Nom commun (par exemple: votre nom d'utilisateur, d'hôte ou de serveur) [Easy-RSA CA]: AUTORITY-CERTIFICATION

La création de l'autorité de certification est terminée et vous pouvez maintenant importer et signer des demandes de certificat.
Votre nouveau fichier de certificat CA pour la publication se trouve à l'adresse suivante:
/home/bron/EasyRSA-v3.0.6/pki/ca.crt

Si l'on ne souhaite pas saisir de mot de passe dans la clé privée de l'AC (ce n'est pas recommandé pour des raisons de sécurité), il faut mettre cette commande:

./easyrsa build-ca nopass

Une fois que nous avons créé l'AC, nous devons créer le certificat serveur et les certificats clients. Ensuite, nous devons le signer avec le CA.

Créez le certificat de serveur et signez-le avec l'autorité de certification

Lors de la création des certificats serveur et client, nous pouvons leur donner un mot de passe pour la clé privée, cependant, il n'est pas recommandé de le faire sur le serveur car à chaque fois que nous le démarrons, il nous demandera le mot de passe pour l'utiliser. Si nous ne voulons pas de mot de passe, nous mettrons «nopass» derrière chaque commande que vous verrez ci-dessous.

./easyrsa gen-req servidor-openvpn-redeszone nopass

La sortie du terminal est la suivante:

root @ debian-vm : /home/bron/EasyRSA-v3.0.6# ./easyrsa gen-req server-openvpn-redeszone nopass

Remarque: utilisation de la configuration Easy-RSA à partir de: ./vars

Utilisation de SSL: openssl OpenSSL 1.1.1d 10 septembre 2019
Générer une clé privée EC
écriture d'une nouvelle clé privée dans '/home/bron/EasyRSA-v3.0.6/pki/private/server-openvpn-redeszone.key.bHJsAFg0KR'
-
Vous allez être invité à entrer des informations qui seront incorporées
dans votre demande de certificat.
Ce que vous êtes sur le point d'entrer est ce qu'on appelle un nom distinctif ou un DN.
Il y a pas mal de champs mais vous pouvez laisser un blanc
Pour certains champs, il y aura une valeur par défaut,
Si vous entrez «.», Le champ sera laissé vide.
-
Nom commun (par exemple: votre nom d'utilisateur, d'hôte ou de serveur) [server-openvpn-redeszone]:

La demande de paire de clés et de certificat est terminée. Vos fichiers sont:
req : /home/bron/EasyRSA-v3.0.6/pki/reqs/server-openvpn-redeszone.req
clé: /home/bron/EasyRSA-v3.0.6/pki/private/servidor-openvpn-redeszone.key

Une fois le certificat créé, nous devons le signer avec l'AC en mode «serveur»:

./easyrsa sign-req server servidor-openvpn-redeszone

root @ debian-vm : /home/bron/EasyRSA-v3.0.6# ./easyrsa sign-req server server-openvpn-redeszone

Remarque: utilisation de la configuration Easy-RSA à partir de: ./vars

Utilisation de SSL: openssl OpenSSL 1.1.1d 10 septembre 2019

Vous êtes sur le point de signer le certificat suivant.
Veuillez vérifier l'exactitude des détails ci-dessous. Notez que cette demande
n'a pas été vérifié cryptographiquement. Veuillez vous assurer qu'il provient d'un
source ou que vous avez vérifié la somme de contrôle de la demande auprès de l'expéditeur.

Objet de la demande, à signer en tant que certificat de serveur pendant 1080 jours:

sujet =
commonName = serveur-openvpn-redeszone

Tapez le mot «oui» pour continuer ou toute autre entrée pour abandonner.
Confirmer les détails de la demande: oui
Utilisation de la configuration de /home/bron/EasyRSA-v3.0.6/pki/safessl-easyrsa.cnf
Entrez la phrase de passe pour /home/bron/EasyRSA-v3.0.6/pki/private/ca.key:
Vérifiez que la demande correspond à la signature
Signature d'accord
Le nom distinctif du sujet est le suivant
commonName: ASN.1 12: 'serveur-openvpn-redeszone'
Le certificat doit être certifié jusqu'au 23 décembre 11:40:22 2022 GMT (1080 jours)

Écrire la base de données avec 1 nouvelles entrées
Base de données mise à jour

Certificat créé à: /home/bron/EasyRSA-v3.0.6/pki/issued/servidor-openvpn-redeszone.crt

Et nous avons déjà créé le .crt que nous utiliserons plus tard dans le fichier de configuration OpenVPN.

Créez des certificats clients et signez-les avec l'autorité de certification

Les étapes que vous verrez ci-dessous, nous devrons effectuer une fois POUR CHAQUE CLIENT que nous allons créer. Autrement dit, si nous voulons créer 2 clients, nous devons suivre les étapes de création et de signature deux fois. Dans cette partie, il est conseillé de créer les certificats du client avec un mot de passe, afin que nous puissions être sûrs que si nous perdons le certificat, personne ne pourra l'utiliser. Nous n'allons pas introduire de mot de passe dans le manuel (nous mettrons nopass à la fin).

./easyrsa gen-req cliente1-openvpn-redeszone nopass

root @ debian-vm : /home/bron/EasyRSA-v3.0.6# ./easyrsa gen-req client1-openvpn-redeszone nopass

Remarque: utilisation de la configuration Easy-RSA à partir de: ./vars

Utilisation de SSL: openssl OpenSSL 1.1.1d 10 septembre 2019
Générer une clé privée EC
écriture d'une nouvelle clé privée dans '/home/bron/EasyRSA-v3.0.6/pki/private/cliente1-openvpn-redeszone.key.YflrPvFgdV'
-
Vous allez être invité à entrer des informations qui seront incorporées
dans votre demande de certificat.
Ce que vous êtes sur le point d'entrer est ce qu'on appelle un nom distinctif ou un DN.
Il y a pas mal de champs mais vous pouvez laisser un blanc
Pour certains champs, il y aura une valeur par défaut,
Si vous entrez «.», Le champ sera laissé vide.
-
Nom commun (par exemple: votre nom d'utilisateur, d'hôte ou de serveur) [client1-openvpn-redeszone]:

La demande de paire de clés et de certificat est terminée. Vos fichiers sont:
req : /home/bron/EasyRSA-v3.0.6/pki/reqs/cliente1-openvpn-redeszone.req
clé: /home/bron/EasyRSA-v3.0.6/pki/private/cliente1-openvpn-redeszone.key

Une fois créé, il faut le signer:

./easyrsa sign-req client cliente1-openvpn-redeszone

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa client sign-req client1-openvpn-redeszone

Remarque: utilisation de la configuration Easy-RSA à partir de: ./vars

Utilisation de SSL: openssl OpenSSL 1.1.1d 10 septembre 2019

Vous êtes sur le point de signer le certificat suivant.
Veuillez vérifier l'exactitude des détails ci-dessous. Notez que cette demande
n'a pas été vérifié cryptographiquement. Veuillez vous assurer qu'il provient d'un
source ou que vous avez vérifié la somme de contrôle de la demande auprès de l'expéditeur.

Objet de la demande, à signer en tant que certificat client pendant 1080 jours:

sujet =
commonName = client1-openvpn-redeszone

Tapez le mot «oui» pour continuer ou toute autre entrée pour abandonner.
Confirmer les détails de la demande: oui
Utilisation de la configuration de /home/bron/EasyRSA-v3.0.6/pki/safessl-easyrsa.cnf
Entrez la phrase de passe pour /home/bron/EasyRSA-v3.0.6/pki/private/ca.key:
Vérifiez que la demande correspond à la signature
Signature d'accord
Le nom distinctif du sujet est le suivant
commonName: ASN.1 12: 'client1-openvpn-redeszone'
Le certificat doit être certifié jusqu'au 23 décembre 11:41:36 2022 GMT (1080 jours)

Écrire la base de données avec 1 nouvelles entrées
Base de données mise à jour

Certificat créé à: /home/bron/EasyRSA-v3.0.6/pki/issued/cliente1-openvpn-redeszone.crt

Si nous voulions créer et signer un certificat numéro 2 pour un autre client, nous devrions mettre quelque chose comme ceci:

./easyrsa gen-req cliente2-openvpn-redeszone nopass ./easyrsa sign-req client cliente2-openvpn-redeszone

N'oubliez pas que si vous souhaitez mettre un mot de passe, il faut supprimer le «nopass».

Organiser les certificats serveur et client .crt et .key

Quelque chose de très important est d'organiser les certificats serveur et client par dossiers. Les certificats serveur et client sont dans le chemin «/ pki / issu /» et les clés privées sont dans «/ pki / private», le ca.crt est à la racine du dossier «pki». Nous devons créer trois dossiers avec le contenu suivant (pour l'instant):

• serveur: ca.crt, serveur-openvpn-redeszone.crt, serveur-openvpn-redeszone.key
• client1 : ca.crt, client1-openvpn-redeszone.crt, client1-openvpn-redeszone.key
• client2 : ca.crt, client2-openvpn-redeszone.crt, client2-openvpn-redeszone.key

Créez les paramètres Diffie-Hellmann et la clé tls-crypt (tls-auth sur les anciens systèmes)

Une fois les certificats créés et signés, nous devions auparavant créer les paramètres Diffie-Hellmann pour les placer dans le dossier «serveur», pour les générer nous utilisions «./easyrsa gen-dh» mais lors de l'utilisation d'ECDHE ce n'est pas nécessaire pour le créer ou l'indiquer dans le fichier de configuration du serveur. Ce que nous devons créer est la clé tls-crypt avec le nom ta.key ou ce que nous voulons. L'ordre que nous devons mettre est le suivant:

openvpn --genkey --secret ta.key

Cette clé ta.key doit être placée sur le serveur et sur TOUS les clients.

Une fois que nous sommes arrivés ici, nos dossiers avec les certificats devraient avoir les éléments suivants:

• serveur: ca.crt, serveur-openvpn-redeszone.crt, serveur-openvpn-redeszone.key, dh.pem (Diffie-Hellmann, FACULTATIF car nous ne l'utilisons pas avec ECDHE), ta.key (tls-crypt)
• client1 : ca.crt, client1-openvpn-redeszone.crt, client1-openvpn-redeszone.key, ta.key (tls-crypt)
• client2 : ca.crt, client2-openvpn-redeszone.crt, client2-openvpn-redeszone.key, ta.key (tls-crypt)

Si nous allons utiliser tls-auth au lieu de tls-crypt (car il n'est pas supporté, par exemple), nous devons en tenir compte:

Dans le la configuration du serveur (server.conf ou server.ovpn) il faut mettre:

tls-auth ta.key 0 (0 depuis Incoming)

Dans le configuration du client (client.conf ou client.ovpn) il faut mettre:

tls-auth ta.key 1 (1 de sortant)

Ensuite, nous mettons un tableau de ce qu'est chaque certificat (les noms varient).

Lorsque tout est organisé dans des dossiers, c'est maintenant que nous devons créer le fichier de configuration (.conf pour les systèmes Linux et .ovpn pour les systèmes Windows). Il y a exemples de fichiers de configuration sur le site officiel d'OpenVPN , ainsi que dans le chemin «/ usr / share / doc / openvpn / examples / examples-config-files /».

La première chose que nous devons vérifier est si notre serveur et nos clients supportent les chiffrements symétriques, tls-ciphersuites (TLS 1.3) et tls-cipher (TLS 1.2) et les courbes elliptiques configurées. Nous devons en tenir compte, sinon cela nous donnera une erreur. Pour effectuer ces vérifications, nous devons exécuter:

• openvpn – afficher les chiffrements
• openvpn –show-tls (il nous montrera s'il prend en charge TLS 1.3 et lesquels, comme TLS 1.2)
• openvpn –show-courbes

Configurez le serveur OpenVPN et démarrez-le

La configuration du serveur OpenVPN est essentielle pour donner des autorisations d'accès aux clients sur notre réseau local, configurer la négociation TLS. Parce que nous avons des centaines de configurations disponibles, nous allons mettre notre configuration avec quelques commentaires expliquant chaque paramètre, vous pouvez copier et coller la configuration sans problème. N'oubliez pas que pour Linux, il doit avoir une extension .conf et pour Windows .ovpn.

#PORT À UTILISER PAR TCP OU UDP, PAR DÉFAUT EST 1194.
#PROTOCOL POUR UTILISER TCP OU UDP
MODE #TUNNELING
Port 11949
proto udp
dev tun

#CERTIFICATS
# SI NOUS AVONS LE .CONF DANS LE MÊME DOSSIER, IL N'Y A PAS MANQUE À METER ROUTE, SEULEMENT LE NOM.
# SI ILS SONT SUR UN AUTRE ROUTE, NOUS DEVONS TESTER LE ROUTE DE TOUS

ca.crt
cert serveur-openvpn-redeszone.crt
clé server-openvpn-redeszone.key
#dh dh.pem (OPTIONNEL CAR NOUS UTILISONS ECDHE)
dh aucun
tls-crypt ta.key

# NOUS CONTRÔLONS LES CERTIFICATS DES CLIENTS (PLUS GRANDE SÉCURITÉ)
client remote-cert-tls

# NOUS MODIFIONS LE CHIFFREMENT SYMÉTRIQUE DU CANAL DE DONNÉES, LE CANAL DE CONTRÔLE TLS ET L'ALGORITHME POUR VÉRIFIER L'INTÉGRITÉ.
# SI NOUS UTILISONS AES-256-GCM, IL N'EST PAS NÉCESSAIRE DE METTRE LA DIRECTIVE AUTH CAR ELLE N'EST PAS UTILISÉE.

chiffrement AES-256-GCM
tls-ciphersuites TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384: TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
ecdh-courbe secp521r1
tls-version-min 1.2
reneg-sec 0
authentification SHA512

# TOPOLOGIE DU RÉSEAU (SOUS-RÉSEAU RECOMMANDÉ) ET SOUS-RÉSEAU VIRTUEL O SE TROUVENT LES CLIENTS.

topologie de sous-réseau
serveur 10.8.0.0 255.255.255.0

# NOUS CONFIGURONS LE SERVEUR POUR QUE LES CLIENTS ONT TOUJOURS LA MÊME IP, UNE FOIS QU'ILS SE CONNECTENT.
ifconfig-pool-persist ipp.txt

# NOUS FOURNISSONS L'ACCÈS DU CLIENT AU RÉSEAU DOMESTIQUE, NOUS RÉALISONS LA RÉDUCTION D'INTERNET ET FOURNISSONS DES OPENDNS DNS. WordPress place automatiquement ces symboles << et >> alors qu'il doit simplement mettre des guillemets doubles: »
appuyez sur «route 192.168.2.0 255.255.255.0»
appuyez sur "redirection de passerelle def1"
appuyez sur "DNS 208.67.222.222 option DHCP"
appuyez sur "DNS 208.67.220.220 option DHCP"

# NOUS PERMETTONS LA COMMUNICATION ENTRE LES CLIENTS, NOUS PERMETTONS DE KEEPALIVE POUR SAVOIR SI LE TUNNEL A CHUTE, NOUS ACTITUONS LA COMPRESSION ET UN MAXIMUM DE 100 CLIENTS SIMULTANÉMENT
client à client
keepalive 10 120
max-clients 100

# AUCUNE PERMISSION D'UTILISATEUR DANS OPENVPN, POUR LA SÉCURITÉ DU SERVEUR
utilisateur personne
groupe nogroup

# CLÉ ET TUNNEL PERSISTANT
persist-key
persist-tun

# LE SERVEUR SE CONNECTE DANS CE FICHIER, CONFIGURATION VERBE 3 POUR LES JOURNAUX.
statut openvpn-status.log
3 verbe
explicit-exit-notifier 1

Jusqu'à présent, nous sommes arrivés avec la configuration du serveur, pour le démarrer nous devrons simplement mettre «openvpn server.conf» dans les systèmes Linux et il démarrera automatiquement, à la fin du démarrage il faut mettre «Séquence d'initialisation terminée» .

Configurer le client (ou les clients)

Ensuite, vous pouvez voir la configuration client associée au serveur que nous avons vue précédemment. La seule différence entre les différents clients.conf est le chemin des certificats, par exemple. Il est très important que le chiffrement, le chiffrement tls et les autres paramètres soient exactement les mêmes, sinon il ne se connectera pas au serveur. N'oubliez pas que pour Linux, il doit avoir une extension .conf et pour Windows .ovpn.

# NOUS CONFIGURONS EN MODE CLIENT, MODE TUN, PROTOCOLE UDP.

client
dev tun
proto udp

# CETTE DIRECTIVE EST LA CONNEXION AVEC L'IP OU LE DOMAINE PUBLIC DU SERVEUR OPENVPN, NOUS DEVONS ÉGALEMENT METTRE LE MÊME PORT DE SERVEUR
télécommande 127.0.0.1 11949

# RÉSOLVEZ CONTINUEMENT L'IP OU LE DOMAINE POUR NOUS CONNECTER, CLÉ ET TUN PERSISTANT EN TANT QUE SERVEUR.
resolv-retry infini
nobind
persist-key
persist-tun

#RUTA DE LA CA, CERTIFICATS CLIENTS ET TA.KEY.
# SI NOUS L'AVONS DANS LE MÊME DOSSIER, IL N'EST PAS NÉCESSAIRE DE METTRE TOUTE LA ROUTE.
ca.crt
certificat client1-openvpn-redeszone.crt
clé client1-openvpn-redeszone.key
tls-crypt ta.key

#VÉRIFIEZ L'IDENTITÉ DU SERVEUR, UTILISEZ LE CRYPTAGE SYMÉTRIQUE GCM, TLS 1.2 ET LA CONFIGURATION D'AUTH. Si notre client ne prend pas en charge TLS 1.3.
serveur remote-cert-tls
chiffrement AES-256-GCM
authentification SHA512

compresser

#Si notre client prend en charge TLS 1.3, nous ajoutons cette directive:
# tls-ciphersuites TLS_AES_256_GCM_SHA384 : TLS_CHACHA20_POLY1305_SHA256

#Si notre client ne prend en charge que TLS 1.2, nous ajoutons cette directive:
# tls-cipher TLS-ECDHE-ECDSA-AVEC-AES-256-GCM-SHA384: TLS-ECDHE-ECDSA-AVEC-CHACHA20-POLY1305-SHA256

# ACTIVER LE JOURNAL VERBOSE NIVEAU 3

3 verbe

Si vous utilisez Windows, le dossier des certificats avec le fichier de configuration dans l'extension .ovpn doit être dans le chemin OpenVPN par défaut, qui est C: UsersBronOpenVPNconfig par défaut, bien que nous puissions le changer. Une fois que cela est fait, si nous faisons un clic droit sur OpenVPN dans la barre inférieure droite, nous verrons le nom du fichier client pour se connecter avec succès. À la fin du démarrage, vous devez mettre «Initialization Sequence Completed» et nous nous serons connectés avec succès au serveur OpenVPN configuré.

Créer une route statique dans notre routeur

Afin d'avoir une connectivité avec le réseau local de notre maison, il est nécessaire de créer une route statique dans notre routeur domestique. Avec la configuration de 10.8.0.0/24 que nous avons configurée dans le serveur OpenVPN, nous devons créer une route statique avec ces informations:

• IP du sous-réseau: 10.8.0.0
• Masque: 255.255.255.0
• Gateway: IP locale où l'on démarre le serveur OpenVPN, si par exemple on l'a installé sur un Raspberry PI avec l'IP 192.168.1.100, il faut mettre cette IP.

Principaux problèmes et échecs de connexion lors de la connexion

Lorsque nous installons un serveur OpenVPN pour la première fois, nous pouvons avoir différents problèmes de connexion des différents clients. Avant de lister les différents problèmes et échecs de connexion qui peuvent apparaître, il faut vous dire que si vous avez suivi le tutoriel pas à pas, vous ne devriez pas avoir d'erreurs lors de la connexion, puisque nous avons vérifié la configuration en détail. La configuration du serveur et des clients est en «verbe 3», c'est-à-dire un niveau d'enregistrement recommandé pour tous les utilisateurs, en cas de problème de connexion, si nous ne trouvons pas l'échec, nous devrons augmenter le niveau d'enregistrement , et mettez «verbe 5» pour avoir plus de détails sur tout ce qui se passe dans la connexion.

RÉSOLU: impossible de résoudre l'adresse de l'hôte: xxxx.no-ip.org:11949 (hôte inconnu.)

Cette erreur est due au fait que le serveur OpenVPN est introuvable, nous devons vérifier que le domaine que nous avons mis est correct, cette erreur est due au fait qu'il ne trouve aucune adresse IP publique associée à ce domaine. Le plus courant est que nous avons mal placé le domaine dans le client VPN, que le domaine que nous avons entré n'existe pas parce que nous ne l'avons pas encore créé, ou parce que le service DNS dynamique ne fonctionne pas correctement.

Impossible de déterminer le protocole IPv4 / IPv6

Cette erreur est liée à la précédente, nous avons entré un domaine qu'il ne parvient pas à trouver, soit en utilisant le protocole IPv4, soit le protocole IPv6.

SIGUSR1 [soft, init_instance] reçu, redémarrage du processus

Cet avertissement nous indique que le processus de connexion avec le serveur VPN va être redémarré, il indique simplement qu'il y a eu une erreur précédemment et qu'il va retenter la connexion.

GESTION:> ÉTAT: 1603127258, ATTENDEZ ,,,,,,

Bien que ce ne soit pas une erreur en soi, si le client OpenVPN reste continuellement dans cette section de la connexion, c'est parce que nous n'avons pas de ports ouverts sur notre routeur ou pare-feu vers le serveur VPN, selon que nous avons utilisé TCP ou UDP , et du port sélectionné, nous devons ouvrir un port ou un autre. En effet, le client est capable de localiser l'adresse IP sans problème, mais il attend une réponse du serveur OpenVPN, une réponse qui n'arrivera jamais.

Cette erreur se produit également généralement lorsque nous n'avons pas démarré le serveur VPN, si nous avons oublié de le démarrer au début, nous aurons ce problème. La solution est de le démarrer et d'attendre l'apparition des premiers clients.

REMARQUE: l'option –user n'est pas implémentée sous Windows

Dans les systèmes d'exploitation Windows, nous n'avons pas besoin de mettre la directive «user nobody», quelque chose que dans les systèmes d'exploitation basés sur Linux, il est conseillé de la mettre.

REMARQUE: l'option –group n'est pas implémentée sous Windows

Dans les systèmes d'exploitation Windows, nous n'avons pas besoin de mettre la directive «group nogroup», ce que dans les systèmes d'exploitation basés sur Linux, il est conseillé de la mettre.

AVERTISSEMENT: en ignorant l'option 'dh' en mode tls-client, veuillez ne l'inclure que dans la configuration de votre serveur

Dans le client VPN, nous n'avons rien à mettre en rapport avec Diffie-Hellmann, cette directive est uniquement dans le fichier de configuration du serveur, dans le client, c'est tout simplement inutile.

Erreur de déroulement de tls-crypt: échec de l'authentification des paquets et erreur TLS: échec du déballage de tls-crypt depuis [AF_INET]

L'authentification avec la directive tls-crypt a échoué, c'est généralement parce que le contenu du fichier ta.key sur le serveur et les clients est différent. Nous devons nous rappeler que la ta.key doit être exactement la même sur le serveur et sur tous les clients VPN que nous allons utiliser.

Erreur TLS: paquet de contrôle impossible à acheminer reçu de [AF_INET] et erreur TLS: les clés TLS locales / distantes ne sont pas synchronisées

Les clés TLS que nous avons utilisées ne sont pas correctes sur le serveur et / ou le client, il faut vérifier la configuration des certificats ainsi que la ta.key. Cette erreur se produit en particulier lorsque la ta.key est mal configurée.

Erreur TLS: paquet de contrôle impossible à acheminer reçu de

Il s'agit d'une erreur générale de la connexion TLS, vous avez peut-être mal copié le CA, le certificat du serveur (dans les paramètres du serveur), le certificat client (dans les paramètres du client). Cette erreur est due à un échec lors de la copie des différents certificats.

ATTENTION: 'link-mtu' est utilisé de manière incohérente, local = 'link-mtu 1549 ′, remote =' link-mtu 1550 ′

Cette erreur apparaît car il est nécessaire que le MTU soit le même à la fois en local (client) et aussi en distant (serveur VPN), si le MTU est mal configuré, la connexion sera établie, mais nous aurons une très faible performance, et il est possible que la connexion VPN soit coupée à tout moment.

Cette erreur se produit également lorsque nous avons activé la compression de données sur le serveur VPN et que nous ne l'avons pas configurée sur le client. Cela se produit également lorsque nous avons un algorithme de compression différent sur le serveur / les clients. Il est nécessaire que le serveur et les clients utilisent la même compression, ou ne pas utiliser la compression, qui est la plus recommandée pour la sécurité.

Pour résoudre cette erreur, il suffit de mettre la directive: «compress» sur le client, afin qu'il accepte la compression envoyée par le serveur via le «PUSH» qu'il effectue.

ATTENTION: 'comp-lzo' est présent dans la configuration distante mais manquant dans la configuration locale, remote = 'comp-lzo'

Cette erreur se produit lorsque sur le serveur VPN, nous avons activé la compression de données avec comp-lzo, et sur les clients, nous n'avons aucune compression du tout. Il est nécessaire que le serveur et les clients aient exactement le même algorithme de compression. Pour résoudre cette erreur, il suffit de mettre la directive: «compress» sur le client, afin qu'il accepte la compression envoyée par le serveur via le «PUSH» qu'il effectue.

L'erreur «écriture sur TUN / TAP: Erreur inconnue (code = 122)» peut également apparaître en raison de cette fonction de compression.

Erreur TLS: la négociation TLS a échoué

Une erreur est survenue lors de la négociation des informations sur le canal de contrôle, il est possible que nous ayons différentes suites de chiffrement tls ou tls-ciphersuites et qu'il n'y ait pas d'algorithme de canal de contrôle commun, cela provoque l'échec de la «prise de contact» et ne peut pas continuer.

Mises à jour et actualités dans les nouvelles versions d'OpenVPN

OpenVPN n'arrête pas de mettre à jour et de publier de nouvelles versions avec des corrections de bogues, des améliorations de performances et également des améliorations de sécurité, dans le but ultime que les connexions VPN soient aussi sécurisées que possible. Ensuite, nous allons expliquer certaines des améliorations qu'OpenVPN 2.5 aura et qui viendront très bientôt, car il est dans la phase «Release Candidate».

Tls-crypt-v2 est ajouté

tls-crypt est une fonctionnalité qui nous permet d'atténuer les attaques DoS et DDoS sur les serveurs OpenVPN, grâce à ces clés que nous créons directement dans OpenVPN, nous pourrons faire pré-authentifier chaque client, pour entrer plus tard dans la phase d'authentification avec leur certificat client. La première version de tls-crypt exige que le serveur et tous les clients aient exactement la même clé tls-crypt. Avec tls-crypt-v2, nous pouvons faire en sorte que chaque client dispose de sa propre clé tls-crypt, de cette manière, les très grandes organisations ou les fournisseurs OpenVPN peuvent protéger adéquatement leurs serveurs en créant plusieurs de ces clés.

Prise en charge du cryptage ChaCha20-Poly1305

Actuellement, le cryptage symétrique le plus sécurisé pouvant être utilisé sur le canal de données est AES-256-GCM et AES-128-GCM. Avec la dernière version d'OpenVPN 2.5, nous aurons également la possibilité de choisir le populaire cryptage ChaCha20-Poly1305 qui utilise un VPN comme WireGuard.

Négociation de cryptage améliorée sur le canal de données

Étroitement lié au point précédent, nous avons que dans la nouvelle version d'OpenVPN 2.5, l'option ncp-ciphers a été renommée en data-ciphers, bien que l'ancien nom continue d'être accepté. Le changement vise à éviter l'ambiguïté de «–cipher» et «–tls-cipher». Maintenant, les clients VPN indiqueront au serveur quel type de chiffrement il prend en charge, et le serveur choisira le premier chiffrement commun dans la liste des chiffrements de données pris en charge, au lieu d'utiliser le premier de la liste, ce qui rendra l'établissement VPN plus rapide. . Cela nous permet également que si le serveur a la configuration de «data-ciphers» ChaCha20-Poly1305: AES-256-GCM, et que le client a ChaCha20-Poly1305, il l'utilisera car le client le prend en charge.

La prise en charge de BF-CBC est supprimée dans les paramètres par défaut

Désormais, la configuration OpenVPN par défaut ne permettra pas d'utiliser BF-CBC, la dernière version n'acceptera que les chiffrements AES-256-GCM et AES-128-GCM pour le canal de données. Nous devons nous rappeler que dans OpenVPN, nous avons BG-CBC lorsque nous n'avons pas l'option –cipher ou –ncp-ciphers dans la configuration. Si vous souhaitez utiliser ce type de cryptage, vous devrez l'activer explicitement.

Nous espérons que ce manuel vous a été utile. Si vous avez des questions que vous pouvez commenter, nous vous recommandons visitez le HOWTO officiel d'OpenVPN où vous trouverez toutes les informations sur les différents paramètres à utiliser. le MAN PAGE d'OpenVPN 2.4 où vous avez tous les paramètres disponibles est également très utile.