Ubuntu 20.04 Focal Fossa est le dernier support à long terme de l'une des distributions Linux les plus utilisées. Dans ce tutoriel nous allons voir comment utiliser ce système d'exploitation pour créer un serveur OpenVPN et comment créer un .ovpn fichier que nous utiliserons pour nous y connecter depuis notre machine cliente.
Dans ce didacticiel, vous apprendrez :
- Comment générer une autorité de certification
- Comment générer un certificat et une clé serveur et client
- Comment signer un certificat avec l'autorité de certification
- Comment créer des paramètres Diffie-Hellman
- Comment générer une clé tls-auth
- Comment configurer le serveur OpenVPN
- Comment générer un fichier .ovpn pour se connecter au VPN
Comment configurer un serveur OpenVPN sur Ubuntu 20.04
Configuration logicielle requise et conventions utilisées
| Catégorie | Exigences, conventions ou version du logiciel utilisée |
|---|---|
| Système | Ubuntu 20.04 Focal Fossa |
| Logiciel | openvpn, ufw, easy-rsa |
| Autre | Autorisations root pour effectuer des tâches administratives |
| Conventions | # - nécessite que les commandes linux données soient exécutées avec les privilèges root soit directement en tant qu'utilisateur root, soit en utilisant sudo commande$ – nécessite que les commandes linux données soient exécutées en tant qu'utilisateur normal non privilégié |
Configuration du scénario
Avant de procéder à la configuration réelle du VPN, parlons des conventions et de la configuration que nous adopterons dans ce didacticiel.
Nous utiliserons deux machines, toutes deux alimentées par Ubuntu 20.04 Focal Fossa . Le premier, camachine sera utilisé pour héberger notre autorité de certification; le second, openvpnmachine sera celui que nous configurerons en tant que VPN réel serveur. Il est possible d'utiliser la même machine pour les deux fins, mais ce serait moins sûr, puisqu'une personne violant le serveur pourrait "usurper l'identité" de l'autorité de certification et l'utiliser pour signer des certificats indésirables (le problème n'est particulièrement pertinent que si vous prévoyez d'avoir plus d'un serveur ou si vous prévoyez d'utiliser la même autorité de certification à d'autres fins). Pour déplacer des fichiers d'une machine à l'autre nous utiliserons le scp (copie sécurisée). Les 10 étapes principales que nous allons effectuer sont les suivantes :
- Génération de l'autorité de certification ;
- Génération de la clé du serveur et demande de certificat ;
- Signature de la demande de certificat du serveur avec l'AC ;
- Génération des paramètres Diffie-Hellman sur le serveur ;
- Génération de la clé tls-auth sur le serveur ;
- Configuration OpenVPN ;
- Configuration du réseau et du pare-feu (ufw) sur le serveur ;
- Génération d'une clé client et demande de certificat ;
- Signature du certificat client avec l'AC ;
- Création du fichier client .ovpn utilisé pour se connecter au VPN.
Étape 1 - Génération de l'autorité de certification (CA)
La première étape de notre parcours consiste en la création de l'autorité de certification sur la machine dédiée. Nous travaillerons en tant qu'utilisateur non privilégié pour générer les fichiers nécessaires. Avant de commencer, nous devons installer le easy-rsa paquet :
$ sudo apt-get update && sudo apt-get -y install easy-rsa
Avec le paquet installé, nous pouvons utiliser le make-cadir commande pour générer un répertoire contenant les outils nécessaires et les fichiers de configuration, dans ce cas nous l'appellerons certificate_authority . Une fois créé, nous nous déplacerons à l'intérieur :
$ make-cadir certificate_authority && cd certificate_authority
Dans le répertoire, nous trouverons un fichier appelé vars . Dans le fichier, nous pouvons définir certaines variables qui seront utilisées pour la génération du certificat. Un ensemble commenté de ces variables se trouve à la ligne 91 à 96 . Supprimez simplement le commentaire et attribuez les valeurs appropriées :
set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "California" set_var EASYRSA_REQ_CITY "San Francisco" set_var EASYRSA_REQ_ORG "Copyleft Certificate Co" set_var EASYRSA_REQ_EMAIL "[email protected]" set_var EASYRSA_REQ_OU "My Organizational Unit"
Une fois les modifications enregistrées, nous pouvons procéder et générer la PKI (Public Key Infrastructure), avec la commande suivante qui créera un répertoire nommé pki :
$ ./easyrsa init-pki
Avec l'infrastructure en place, nous pouvons générer notre clé et notre certificat CA. Après avoir lancé la commande ci-dessous, il nous sera demandé de saisir une phrase de passe pour la clé ca . Nous devrons fournir le même mot de passe chaque fois que nous interagirons avec l'autorité. Un nom commun pour le certificat doit également être fourni. Cela peut être une valeur arbitraire; si nous appuyons simplement sur entrée à l'invite, celle par défaut sera utilisée, dans ce cas Easy-RSA CA :
$ ./easyrsa build-ca
Voici le résultat de la commande :
Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019 Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: Generating RSA private key, 2048 bit long modulus (2 primes) ..........+++++ ....................................................................+++++ e is 65537 (0x010001) Can't load /home/egdoc/certificate_authority/pki/.rnd into RNG 140296362980608:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:98:Filename=/home/egdoc/certificate_authority/pki/.rnd You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/egdoc/certificate_authority/pki/ca.crt
Le build-ca la commande a généré deux fichiers ; leur chemin, relatif à notre répertoire de travail sont :
- pki/ca.crt
- pki/private/ca.key
Le premier est le certificat public, le second est la clé qui sera utilisée pour signer les certificats du serveur et des clients, il doit donc être gardé aussi sûr que possible.
Une petite note, avant d'aller de l'avant :dans la sortie de la commande, vous avez peut-être remarqué un message d'erreur. Bien que l'erreur ne soit pas flagrante, une solution de contournement pour l'éviter consiste à commenter la troisième ligne du openssl-easyrsa.cnf fichier qui se trouve dans le répertoire de travail généré. Le problème est discuté sur le référentiel github openssl. Après la modification, le fichier devrait ressembler à ceci :
# For use with Easy-RSA 3.1 and OpenSSL or LibreSSL RANDFILE = $ENV::EASYRSA_PKI/.rnd
Ceci dit, passons à la machine que nous utiliserons comme serveur OpenVPN et générons la clé et le certificat du serveur.
Étape 2 - Génération de la clé du serveur et de la demande de certificat
Dans cette étape, nous allons générer la clé du serveur et la demande de certificat qui seront ensuite signées par l'autorité de certification. Sur la machine que nous utiliserons comme serveur OpenVPN, nous devons installer le openvpn , easy-rsa et ufw forfaits :
$ sudo apt-get update && sudo apt-get -y install openvpn easy-rsa ufw
Pour générer la clé du serveur et la demande de certificat, nous effectuons la même procédure que celle que nous avons utilisée sur la machine hébergeant l'autorité de certification :
- Nous générons un répertoire de travail avec le
make-cadircommande, et déplacez-vous à l'intérieur. - Configurer les variables contenues dans le
varsfichier qui sera utilisé pour le certificat. - Générer l'infrastructure à clé publique avec le
./easyrsa init-pkicommande.
Après ces étapes préliminaires, nous pouvons émettre la commande pour générer le certificat du serveur et le fichier clé :
$ ./easyrsa gen-req server nopass
Cette fois, puisque nous avons utilisé le nopass option, nous ne serons pas invités à insérer un mot de passe lors de la génération de la clé du serveur . On nous demandera toujours de saisir un nom commun pour le certificat de serveur . Dans ce cas la valeur par défaut utilisée est server . C'est ce que nous allons utiliser dans ce tutoriel :
Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019 Generating a RSA private key ....................+++++ .................+++++ writing new private key to '/home/egdoc/openvpnserver/pki/private/server.key.9rU3WfZMbW' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [server]: Keypair and certificate request completed. Your files are: req: /home/egdoc/openvpnserver/pki/reqs/server.req key: /home/egdoc/openvpnserver/pki/private/server.key
Une demande de signature de certificat et une clé privée sera généré :
/home/egdoc/openvpnserver/pki/reqs/server.req/home/egdoc/openvpnserver/pki/private/server.key.
Le fichier clé doit être déplacé dans le /etc/openvpn répertoire :
$ sudo mv pki/private/server.key /etc/openvpn
La demande de certificat, à la place, doit être envoyée à la machine de l'autorité de certification, pour être signée. Nous pouvons utiliser scp commande pour transférer le fichier :
$ scp pki/reqs/server.req egdoc@camachine:/home/egdoc/
Revenons à camachine et autoriser le certificat.
Étape 3 – Signature du certificat du serveur avec l'autorité de certification
Sur la machine de l'autorité de certification, nous devrions trouver le fichier que nous avons copié à l'étape précédente dans le $HOME répertoire de notre utilisateur :
$ ls ~ certificate_authority server.req
La première chose que nous faisons est d'importer la demande de certificat. Pour accomplir la tâche, nous utilisons le import-req action de easyrsa scénario. Sa syntaxe est la suivante :
import-req <request_file_path> <short_basename>
Dans notre cas, cela se traduit par :
$ ./easyrsa import-req ~/server.req server
La commande générera la sortie suivante :
Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019 The request has been successfully imported with a short name of: server You may now use this name to perform signing operations on this request.
Pour signer la requête, nous utilisons le sing-req action, qui prend le type de la requête comme premier argument (serveur, dans ce cas), et le short_basename nous avons utilisé dans la commande précédente (serveur). Nous courons :
$ ./easyrsa sign-req server server
Il nous sera demandé de confirmer que nous voulons signer le certificat et de fournir le mot de passe que nous avons utilisé pour la clé de l'autorité de certification. Si tout se passe comme prévu, le certificat sera créé :
Note: using Easy-RSA configuration from: ./vars
Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.
Request subject, to be signed as a server certificate for 1080 days:
subject=
commonName = server
Type the word 'yes' to continue, or any other input to abort.
Confirm request details: yes
Using configuration from /home/egdoc/certificate_authority/pki/safessl-easyrsa.cnf
Enter pass phrase for /home/egdoc/certificate_authority/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'server'
Certificate is to be certified until Mar 20 02:12:08 2023 GMT (1080 days)
Write out database with 1 new entries
Data Base Updated
Certificate created at: /home/egdoc/certificate_authority/pki/issued/server.crt
Nous pouvons maintenant supprimer le fichier de requête que nous avons précédemment transféré depuis openvpnmachine . Et copiez le certificat généré sur notre OpenVPN serveur, ainsi que le certificat public de l'AC :
$ rm ~/server.req
$ scp pki/{ca.crt,issued/server.crt} egdoc@openvpnmachine:/home/egdoc
De retour sur openvpnmachine nous devrions trouver les fichiers dans notre répertoire personnel. Nous pouvons maintenant les déplacer vers /etc/openvpn :
$ sudo mv ~/{ca.crt,server.crt} /etc/openvpn
Étape 4 - Génération des paramètres Diffie-Hellman
La prochaine étape consiste en la génération d'un Diffie-Hellman paramètres. Le Diffie-Hellman L'échange de clés est la méthode utilisée pour transférer des clés de chiffrement sur un canal public non sécurisé. La commande pour générer la clé est la suivante (cela peut prendre un certain temps pour se terminer) :
$ ./easyrsa gen-dh
La clé sera générée à l'intérieur du pki répertoire sous la forme dh.pem . Déplaçons-le dans /etc/openvpn comme dh2048.pem :
$ sudo mv pki/dh.pem /etc/openvpn/dh2048.pem
Étape 5 - Génération de la clé tls-auth (ta.key)
Pour améliorer la sécurité, OpenVPN implémente tls-auth . Citant la documentation officielle :
La directive tls-auth ajoute une signature HMAC supplémentaire à tous les paquets de prise de contact SSL/TLS pour la vérification de l'intégrité. Tout paquet UDP ne portant pas la signature HMAC correcte peut être supprimé sans autre traitement. La signature HMAC tls-auth fournit un niveau de sécurité supplémentaire au-delà de celui fourni par SSL/TLS. Il peut protéger contre :
– les attaques DoS ou l'inondation de port sur le port UDP OpenVPN.
– l'analyse des ports pour déterminer quels ports UDP du serveur sont en état d'écoute.
– les vulnérabilités de débordement de tampon dans le Implémentation SSL/TLS.
– Initiations de poignée de main SSL/TLS à partir de machines non autorisées (alors que de telles poignées de main échoueraient finalement à s'authentifier, tls-auth peut les couper beaucoup plus tôt).
Pour générer la clé tls_auth, nous pouvons exécuter la commande suivante :
$ openvpn --genkey --secret ta.key
Une fois généré, nous déplaçons le ta.key fichier dans /etc/openvpn :
$ sudo mv ta.key /etc/openvpn
La configuration de nos clés de serveur est maintenant terminée. Nous pouvons procéder à la configuration réelle du serveur.
Étape 6 - Configuration d'OpenVPN
Le fichier de configuration OpenVPN n'existe pas par défaut dans /etc/openvpn . Pour le générer, nous utilisons un modèle fourni avec le openvpn emballer. Exécutons cette commande :
$ zcat \ /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz \ | sudo tee /etc/openvpn/server.conf > /dev/null
Nous pouvons maintenant éditer le /etc/openvpn/server.conf dossier. Les parties concernées sont présentées ci-dessous. La première chose que nous voulons faire est de vérifier que le nom des clés et des certificats référencés correspond à ceux que nous avons générés. Si vous avez suivi ce tutoriel, cela devrait certainement être le cas (lignes 78-80 et 85 ):
ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh2048.pem
Nous voulons faire fonctionner le démon OpenVPN avec de faibles privilèges, le nobody utilisateur et nogroup grouper. La partie pertinente du fichier de configuration se trouve aux lignes 274 et 275 . Nous avons juste besoin de supprimer le premier ; :
user nobody group nogroup
Une autre ligne dont nous voulons supprimer le commentaire est 192 . Cela obligera tous les clients à rediriger leur passerelle par défaut via le VPN :
push "redirect-gateway def1 bypass-dhcp"
Lignes 200 et 201 to peut également être utilisé pour permettre au serveur de pousser des serveurs DNS spécifiques vers des clients. Ceux du fichier de configuration sont ceux fournis par opendns.com :
push "dhcp-option DNS 208.67.222.222" push "dhcp-option DNS 208.67.220.220"
À ce stade, le /etc/openvpn Le répertoire doit contenir ces fichiers que nous avons générés :
/etc/openvpn ├── ca.crt ├── dh2048.pem ├── server.conf ├── server.crt ├── server.key └── ta.key
Assurons-nous qu'ils appartiennent tous à root :
$ sudo chown -R root:root /etc/openvpn
Nous pouvons passer à l'étape suivante :configurer les options de mise en réseau.
Étape 7 – Configuration de la mise en réseau et de l'ufw
Pour que notre VPN fonctionne, nous devons activer le transfert IP sur notre serveur. Pour cela, il suffit de décommenter la ligne 28 depuis le /etc/sysctl.conf fichier :
# Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1
Pour recharger les paramètres :
$ sudo sysctl -p
Nous devons également autoriser le transfert de paquets dans le pare-feu ufw en modifiant le /etc/default/ufw fichier et en modifiant le DEFAULT_FORWARD_POLICY de DROP pour ACCEPT (ligne 19 ):
# Set the default forward policy to ACCEPT, DROP or REJECT. Please note that # if you change this you will most likely want to adjust your rules DEFAULT_FORWARD_POLICY="ACCEPT"
Nous devons maintenant ajouter les règles suivantes au début du /etc/ufw/before.rules dossier. Ici, nous supposons que l'interface utilisée pour la connexion est eth0 :
*nat :POSTROUTING ACCEPT [0:0] -A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE COMMIT
Enfin, nous devons autoriser le trafic entrant pour le openvpn service dans le gestionnaire de pare-feu ufw :
$ sudo ufw allow openvpn
À ce stade, nous pouvons redémarrer ufw pour que les modifications soient appliquées. Si votre pare-feu n'a pas été activé à ce stade, assurez-vous que le ssh le service est toujours autorisé, sinon vous risquez d'être coupé si vous travaillez à distance.
$ sudo ufw disable && sudo ufw enable
Nous pouvons maintenant démarrer et activer le service openvpn.service au démarrage :
$ sudo systemctl restart openvpn && sudo systemctl enable openvpn
Étape 8 - Génération d'une clé client et d'une demande de certificat
La configuration de notre serveur est maintenant terminée. L'étape suivante consiste en la génération de la clé client et de la demande de certificat. La procédure est la même que celle que nous avons utilisée pour le serveur :nous utilisons simplement "client" comme nom au lieu de "sever", générons la clé et la demande de certificat, puis transmettons cette dernière à la machine CA à signer.
$ ./easyrsa gen-req client nopass
Comme précédemment, il nous sera demandé d'entrer un nom commun. Les fichiers suivants seront générés :
- /home/egdoc/openvpnserver/pki/reqs/client.req
- /home/egdoc/openvpnserver/pki/private/client.key
Copions le client.req à la machine CA :
$ scp pki/reqs/client.req egdoc@camachine:/home/egdoc
Une fois le fichier copié, sur camachine , nous importons la requête :
$ ./easyrsa import-req ~/client.req client
Ensuite, nous signons le certificat :
$ ./easyrsa sign-req client client
Après avoir entré le mot de passe CA, le certificat sera créé en tant que pki/issued/client.crt . Supprimons le fichier de requête et copions le certificat signé sur le serveur VPN :
$ rm ~/client.req $ scp pki/issued/client.crt egdoc@openvpnmachine:/home/egdoc
Pour plus de commodité, créons un répertoire pour contenir tous les éléments liés au client et y déplacer la clé et le certificat du client :
$ mkdir ~/client $ mv ~/client.crt pki/private/client.key ~/client
Bon, nous y sommes presque. Maintenant, nous devons copier le modèle de configuration du client, /usr/share/doc/openvpn/examples/sample-config-files/client.conf à l'intérieur du ~/client répertoire et modifiez-le en fonction de nos besoins :
$ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client
Voici les lignes que nous devons changer dans le fichier. À la ligne 42 mettez l'adresse IP ou le nom d'hôte réel du serveur à la place de my-server-1 :
remote my-server-1 1194
Aux lignes 61 et 62 supprimer le premier ; caractère pour rétrograder les privilèges après l'initialisation :
user nobody group nogroup
Sur les lignes 88 à 90 et 108 nous pouvons voir que le certificat CA, le certificat client, la clé client et la clé tls-auth sont référencés. Nous voulons commenter ces lignes, car nous mettrons le contenu réel des fichiers entre une paire de "balises" dédiées :
<ca></ca>pour le certificat CA<cert></cert>pour le certificat client<key></key>pour la clé client<tls-auth></tls-auth>pour la clé tls-auth
Une fois les lignes commentées, nous ajoutons le contenu suivant en bas du fichier :
<ca> # Here goes the content of the ca.crt file </ca> <cert> # Here goes the content of the client.crt file </cert> <key> # Here goes the content of the client.key file </key> key-direction 1 <tls-auth> # Here goes the content of the ta.key file </tls-auth>
Une fois l'édition du fichier terminée, nous le renommons avec le .ovpn suffixe :
$ mv ~/client/client.conf ~/client/client.ovpn
Il ne reste plus qu'à importer le fichier dans notre application cliente pour le faire se connecter à notre VPN. Si nous utilisons l'environnement de bureau GNOME, par exemple, nous pouvons importer le fichier depuis Réseau section du panneau de commande. Dans la section VPN, cliquez simplement sur le + puis sur « importer depuis fichier » pour sélectionner et importer le fichier « .ovpn » que vous avez précédemment transféré sur votre poste client.
Interface GNOME pour importer le fichier .ovpn
Conclusion
Dans ce tutoriel, nous avons vu comment créer une configuration OpenVPN fonctionnelle. Nous avons généré une autorité de certification et utilisé pour signer les certificats serveur et client que nous avons générés avec les clés correspondantes. Nous avons vu comment configurer le serveur et comment configurer la mise en réseau, permettant le transfert de paquets et effectuant les modifications nécessaires à la configuration du pare-feu ufw. Enfin, nous avons vu comment générer un client .ovpn fichier pouvant être importé depuis une application cliente afin de se connecter facilement à notre VPN. Amusez-vous !