One place for hosting & domains

      configurer

      Comment installer et configurer Postfix en tant que serveur SMTP à envoi uniquement sur Ubuntu 18.04


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Postfix est un agent de transfert de courriel (MTA), une application utilisée pour envoyer et recevoir des courriels. Elle peut être configurée de manière à ce qu’elle puisse être utilisée pour envoyer des courriels par application locale uniquement. Cela est utile dans les situations où vous devez régulièrement envoyer des notifications par courrier électronique à partir de vos applications, ou simplement en cas de trafic sortant important qu’un fournisseur de services de courrier électronique tiers n’autoriserait pas. C’est également une alternative plus légère à l’exploitation d’un serveur SMTP complet, tout en conservant les fonctionnalités requises.

      Dans ce tutoriel, vous allez installer et configurer Postfix en tant que serveur SMTP pour l’envoi uniquement. Vous allez également demander des certificats TLS gratuits à Let’s Encrypt pour votre domaine et crypter les courriels sortants à l’aide de ces certificats.

      Conditions préalables

      • Un serveur Ubuntu 20.04 configuré avec la Configuration initiale du serveur avec Ubuntu 20.04 y compris la création d’un sudo non root user.
      • Un nom de domaine entièrement enregistré. Ce tutoriel utilisera your_domain. Vous pouvez acheter un nom de domaine sur Namecheap, en obtenir un gratuitement sur Freenom, ou utiliser le bureau d’enregistrement de domaine de votre choix.
      • Un enregistrement DNS A avec your_domain pointant sur l’adresse IP publique de votre serveur. Vous pouvez suivre cette introduction à DigitalOcean DNS pour savoir comment les ajouter.

      Note : Le nom d’hôte de votre serveur et le nom de votre Droplet doivent correspondre à your_domain car DigitalOcean établit automatiquement des enregistrements PTR pour l’adresse IP de la Droplet en fonction de son nom. 

      Vous pouvez vérifier le nom d’hôte du serveur en tapant hostname à l’invite de commande. La sortie doit correspondre au nom que vous avez donné à la Droplet lors de sa création.

      Étape 1 — Installer Postfix

      Dans cette étape, vous allez installer Postfix. Le moyen le plus rapide est d’installer le paquet mailutils qui regroupe Postfix avec quelques programmes supplémentaires que vous utiliserez pour tester l’envoi de courrier électronique. 

      Tout d’abord, mettez à jour la base de données des paquets :

      Ensuite, installez Postfix en exécutant la commande suivante :

      • sudo apt install mailutils

      Vers la fin du processus d’installation, la fenêtre de configuration de Postfix vous sera présentée :

      Sélectionnez Internet Site dans le menu, puis appuyez sur la touche TAB pour sélectionner<Ok>puis ENTRÉE 

      L’option par défaut est Site Internet. C’est l’option recommandée pour votre cas d’utilisation, donc appuyez sur TAB, puis ENTRÉE. Si vous ne voyez que le texte de la description, appuyez sur TAB pour sélectionner OK, puis sur ENTER. 

      S’il ne s’affiche pas automatiquement, exécutez la commande suivante pour le démarrer :

      • sudo dpkg-reconfigure postfix

      Après cela, vous obtiendrez une autre invite de configuration concernant le nom de messagerie du système :

      Entrez votre nom de domaine, puis appuyez sur TAB pour sélectionner<Ok>ENTRÉE

      Le nom de messagerie du système doit être le même que celui que vous avez attribué à votre serveur lors de sa création. Lorsque vous avez terminé, appuyez sur TAB, puis sur ENTRÉE.

      Vous avez maintenant installé Postfix et vous êtes prêt à commencer à le configurer.

      Étape 2 — Configurer Postfix

      Au cours de cette étape, vous configurerez Postfix pour envoyer et recevoir des courriels uniquement à partir du serveur sur lequel il fonctionne, c’est-à-dire à partir de localhost.

      Pour que cela arrive, Postfix doit être configuré pour écouter uniquement sur l’interface de bouclage, l’interface de réseau virtuel que le serveur utilise pour communiquer en interne. Pour effectuer les changements, vous devrez modifier le fichier de configuration principal de Postfix appelé main.cf, stocké sous etc/postfix. 

      Ouvrez-le pour l’éditer à l’aide de votre éditeur de texte préféré :

      • sudo nano /etc/postfix/main.cf

      Trouvez les lignes suivantes :

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = all
      . . .
      

      Définissez la valeur du paramètre inet_interfaces à loopback-only :

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = loopback-only
      . . .
      

      Une autre directive que vous devrez modifier est la directive mydestination qui spécifie la liste des domaines qui sont distribués via le transport de courrier local_transport. Par défaut, les valeurs sont similaires à celles-ci :

      /etc/postfix/main.cf

      . . .
      mydestination = $myhostname, your_domain, localhost.com, , localhost
      . . .
      

      Changez la ligne pour qu’elle ressemble à ceci :

      /etc/postfix/main.cf

      . . .
      mydestination = localhost.$mydomain, localhost, $myhostname
      . . .
      

      Si votre domaine est en fait un sous-domaine, et que vous souhaitez que les courriels aient l’air d’avoir été envoyés depuis le domaine principal, vous pouvez ajouter la ligne suivante à la fin de main.cf:

      /etc/postfix/main.cf

      ...
      masquerade_domains = your_main_domain
      

      Le paramètre facultatif masquerade_domains spécifie pour quels domaines la partie de sous-domaine sera supprimée dans l’adresse e-mail.

      Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Note : Si vous hébergez plusieurs domaines sur un seul serveur, les autres domaines peuvent également être transmis à Postfix en utilisant la directive mydestination.

      Ensuite, redémarrez Postfix en exécutant la commande suivante :

      • sudo systemctl restart postfix

      Vous avez configuré Postfix pour n’envoyer des courriels qu’à partir de votre serveur. Vous allez maintenant le tester en envoyant un exemple de message à une adresse électronique.

      Étape 3 — Tester le serveur SMTP

      Au cours de cette étape, vous allez tester si Postfix peut envoyer des courriels à un compte de messagerie externe en utilisant la commande mail qui fait partie du paquet mailutils que vous avez installé lors de la première étape.

      Pour envoyer un courriel de test, exécutez la commande suivante :

      • echo "This is the body of the email" | mail -s "This is the subject line" your_email_address

      Vous pouvez changer le corps et l’objet du courriel à votre convenance. N’oubliez pas de remplacer your_email_address avec une adresse électronique valide à laquelle vous pouvez accéder. 

      Maintenant, vérifiez l’adresse électronique à laquelle vous avez envoyé ce message. Vous devriez voir le message dans votre boîte de réception. S’il n’y est pas, vérifiez votre dossier de courrier indésirable. À ce stade, tous les courriers électroniques que vous envoyez ne sont pas cryptés, ce qui fait penser aux fournisseurs de services qu’il s’agit probablement de spam. Vous mettrez en place le cryptage plus tard, à l’étape 5.

      Si vous recevez une erreur de la part de la commande mail ou que vous n’avez pas reçu de message après une période prolongée, vérifiez que la configuration de Postfix que vous avez modifiée est valide et que le nom de votre serveur et le nom d’hôte sont définis pour votre domaine.

      Notez qu’avec cette configuration, l’adresse dans le champ de départ pour les courriels de test que vous envoyez sera sous la forme your_user_name@your_domain, où your_user_name est le nom d’utilisateur de l’utilisateur du serveur sous lequel vous avez exécuté la commande. 

      Vous avez maintenant envoyé un courriel à partir de votre serveur et vérifié qu’il a bien été reçu. Dans l’étape suivante, vous mettrez en place une redirection de courrier électronique pour root. 

      Étape 4 — Transférer le courrier système

      Au cours de cette étape, vous configurerez le transfert de courrier électronique pour l’utilisateur root afin que les messages générés par le système qui lui sont envoyés sur votre serveur soient transférés à une adresse électronique externe.

      Le fichier /etc/aliases contient une liste de noms alternatifs pour les destinataires du courrier électronique. Ouvrez-le pour le modifier :

      Dans son état par défaut, il ressemble à ceci :

      /etc/aliases

      # See man 5 aliases for format
      postmaster:    root
      

      La seule directive présente précise que les courriels générés par le système sont envoyés à root.

      Ajoutez la ligne suivante à la fin du fichier :

      /etc/aliases

      ...
      root:          your_email_address
      

      Avec cette ligne, vous précisez que les courriels envoyés à root finissent par être transférés à une adresse électronique. N’oubliez pas de remplacer your_email_address avec votre adresse électronique personnelle. Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Pour que le changement prenne effet, exécutez la commande suivante :

      L’exécution de newaliases permet de constituer une base de données des alias utilisés par la commande mail, qui sont extraits du fichier de configuration que vous venez d’éditer.

      Testez que l’envoi de courriels vers root fonctionne, en exécutant :

      • echo "This is the body of the email" | mail -s "This is the subject line" root

      Vous devriez recevoir le courriel à votre adresse électronique. S’il n’y est pas, vérifiez votre dossier spam.

      Dans cette étape, vous avez mis en place le transfert des messages générés par le système vers votre adresse électronique. Vous allez maintenant activer le cryptage des messages de sorte que tous les courriers électroniques envoyés par votre serveur sont à l’abri de toute altération pendant leur transit et seront considérés comme plus légitimes.

      Étape 5 — Activation du cryptage SMTP

      Vous allez maintenant activer le cryptage SMTP en demandant un certificat TLS gratuit à Let’s Encrypt pour votre domaine (en utilisant Certbot) et en configurant Postfix pour l’utiliser lors de l’envoi de messages.

      Ubuntu inclut Certbot dans ses référentiels de paquets par défaut ; vous pouvez donc l’installer en exécutant la commande suivante :

      Lorsqu’on vous demande une confirmation, tapez Y et appuyez sur ENTER .

      Lors de la configuration initiale du serveur dans les conditions préalables, vous avez installé ufw, le pare-feu non compliqué. Vous devrez le configurer pour autoriser le port HTTP 80 afin que la vérification du domaine puisse être effectuée. Exécutez la commande suivante pour l’activer :

      La sortie finale ressemblera à ceci :

      Output

      Rule added Rule added (v6)

      Maintenant que le port est ouvert, lancez Certbot pour obtenir un certificat :

      • sudo certbot certonly --standalone --rsa-key-size 4096 --agree-tos --preferred-challenges http -d your_domain

      Cette commande ordonne à Certbot d’émettre des certificats avec une clé RSA de 4096 bits pour faire fonctionner un serveur Web autonome temporaire (--standalone) pour la vérification, et pour vérifier via le port 80 (--preferred-challenges http). N’oubliez pas de remplacer your_domain par votre domaine avant d’exécuter la commande, et entrez votre adresse électronique lorsque vous y êtes invité. 

      Le résultat sera similaire à celui-ci :

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for `your_domain` Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-07-11. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Comme indiqué dans les notes, votre certificat et votre fichier de clé privée ont été enregistrés sous /etc/letsencrypt/live/your_domain. 

      Maintenant que vous avez votre certificat, ouvrez main.cf pour l’éditer :

      • sudo nano /etc/postfix/main.cf

      Trouvez la section suivante :

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
      smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Modifiez-le pour qu’il ressemble à ceci, en remplaçant your_domain par votre domaine, si nécessaire. Cela permettra de mettre à jour vos paramètres TLS pour Postfix :

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/letsencrypt/live/your_domain/fullchain.pem
      smtpd_tls_key_file=/etc/letsencrypt/live/your_domain/privkey.pem
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Une fois que vous avez terminé, enregistrez et fermez le fichier.

      Pour appliquer les changements, redémarrez Postfix :

      • sudo systemctl restart postfix

      Maintenant, essayez d’envoyer à nouveau un courriel :

      • echo "This is the body of an encrypted email" | mail -s "This is the subject line" your_email_address

      Ensuite, vérifiez l’adresse électronique que vous avez fournie. Il est possible que vous voyiez le message dans votre boîte de réception immédiatement car les fournisseurs de messagerie électronique sont beaucoup plus susceptibles de marquer les messages non cryptés comme étant du spam.

      Vous pouvez vérifier les informations techniques concernant le message électronique dans votre client pour voir si le message est effectivement crypté.

      Conclusion

      Vous disposez maintenant d’un serveur de courrier électronique à envoi unique, alimenté par Postfix. Le cryptage de tous les messages sortants est un premier pas efficace pour que les fournisseurs de services de messagerie électronique ne marquent pas purement et simplement vos messages comme du spam. Si vous faites cela dans un scénario de développement, alors cette mesure devrait suffire.

      Cependant, si votre cas d’utilisation est l’envoi de courriels aux utilisateurs potentiels du site (comme des courriels de confirmation pour l’inscription à un forum), vous devriez envisager de créer des registres SPF afin que les courriels de votre serveur soient encore plus susceptibles d’être considérés comme légitimes.



      Source link

      Comment configurer l’accès à distance pour MongoDB sur Ubuntu 20.04


      Une version antérieure de ce tutoriel a été écrite par Brennan Bearnes.

      Introduction

      MongoDB, également connu sous le nom de Mongo, est une base de données de documents open-source utilisée couramment dans des applications web modernes. Par défaut, il n’autorise que les connexions provenant du même serveur que celui où il est installée. Si vous souhaitez gérer MongoDB à distance ou le connecter à un serveur d’application distinct, vous devrez apporter quelques changements à la configuration par défaut.

      Dans ce tutoriel, vous allez configurer une installation MongoDB pour permettre un accès sécurisé à partir d’un ordinateur distant de confiance. Pour ce faire, vous allez mettre à jour vos règles de pare-feu pour permettre à la machine distante d’accéder au port sur lequel MongoDB écoute des connexions, puis vous mettrez à jour son fichier de configuration pour modifier son paramètre de liaison IP. Ensuite, comme dernière étape, vous testerez si votre machine distante est capable de se connecter avec succès à votre base de données.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

      • Un serveur fonctionnant sous Ubuntu 20.04 Ce serveur doit avoir un non-root user administratif et un pare-feu configuré avec UFW. Pour cela, suivez notre guide de configuration initiale du serveur pour Ubuntu 20.04.
      • MongoDB installé sur votre serveur. Ce tutoriel suppose que vous avez installé MongoDB 4.4 ou une version plus récente. Vous pouvez installer cette version en suivant notre tutoriel Comment installer MongoDB sur Ubuntu 20.04.
      • Un deuxième ordinateur à partir duquel vous allez accéder à votre instance MongoDB. Pour plus de simplicité, ce tutoriel suppose que cette machine est un autre serveur Ubuntu 20.04, avec un utilisateur administratif non root et un pare-feu UFW configuré en suivant notre guide de configuration initiale du serveur pour Ubuntu 20.04. Cependant, les étapes 1 et 2, qui décrivent la procédure réelle d’activation de la connectivité à distance sur le serveur de base de données, fonctionneront quel que soit le système d’exploitation de la machine distante.

      Enfin, bien que ce ne soit pas nécessaire pour terminer ce tutoriel, nous vous recommandons fortement de sécuriser votre installation MongoDB en créant un compte utilisateur administratif pour la base de données et en activant l’authentification. Pour ce faire, suivez notre tutoriel Comment sécuriser MongoDB sur Ubuntu 20.04.

      Étape 2 — Ajustement du pare-feu

      En supposant que vous ayez suivi le tutoriel de configuration initiale du serveur et activé un pare-feu UFW sur votre serveur, votre installation MongoDB sera inaccessible depuis Internet. Si vous avez l’intention d’utiliser MongoDB uniquement en local avec des applications fonctionnant sur le même serveur, il s’agit de la configuration recommandée et sécurisée. Cependant, si vous souhaitez pouvoir vous connecter à votre serveur MongoDB à distance, vous devez autoriser les connexions entrantes sur le port où la base de données est à l’écoute en ajoutant une nouvelle règle UFW.

      Commencez par vérifier quel port votre installation MongoDB écoute avec la commande lsof. Cette commande renvoie généralement une liste contenant tous les fichiers ouverts d’un système, mais lorsqu’elle est combinée à l’option -i, elle ne répertorie que les fichiers ou les flux de données liés au réseau.

      La commande suivante redirigera la sortie produite par lsof -i vers une commande grep qui recherche une chaîne nommée mongo :

      • sudo lsof -i | grep mongo

      Cet exemple de sortie montre que MongoDB écoute les connexions sur son port par défaut, 27017 :

      Output

      mongod 82221 mongodb 11u IPv4 913411 0t0 TCP localhost:27017 (LISTEN)

      Dans la plupart des cas, MongoDB ne doit être accessible qu’à partir de certains lieux de confiance (un autre serveur hébergeant une application, par exemple). Une façon de configurer cette méthode consiste à exécuter la commande suivante sur votre serveur MongoDB, qui ouvre un accès sur le port par défaut de MongoDB tout en n’autorisant explicitement que l’adresse IP de l’autre serveur de confiance.

      Exécutez la commande suivante, en vous assurant de remplacer trusted_server_ip par l’adresse IP de la machine distante de confiance que vous utiliserez pour accéder à votre instance MongoDB :

      Remarque : si la sortie de la commande précédente a indiqué que votre installation de MongoDB écoute sur un port non par défaut, utilisez ce numéro de port à la place de 27017 dans cette commande.

      • sudo ufw allow from trusted_server_ip to any port 27017

      À l’avenir, si jamais vous souhaitez accéder à MongoDB à partir d’une autre machine, exécutez à nouveau cette commande avec l’adresse IP de la nouvelle machine à la place de trusted_server_ip.

      Vous pouvez vérifier le changement dans les paramètres de pare-feu avec ufw :

      La sortie montrera que le trafic vers le port 27017 du serveur distant est maintenant autorisé :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 27017 ALLOW trusted_server_ip OpenSSH (v6) ALLOW Anywhere (v6)

      Vous pouvez trouver des paramètres de pare-feu plus avancés pour restreindre l’accès aux services dans les Essentiels d’UFW : Règles et commandes communes du pare-feu.

      Ensuite, vous allez lier MongoDB à l’adresse IP publique du serveur afin de pouvoir y accéder à partir de votre machine distante.

      Étape 2 — Configurer une bindIP publique

      À ce stade, même si le port est ouvert, MongoDB est actuellement lié à 127.0.0.1, l’interface du réseau de rebouclage local. Cela signifie que MongoDB n’est en mesure d’accepter que les connexions originaires du serveur où il est installé.

      Pour permettre des connexions distantes, vous devez modifier le fichier de configuration de MongoDB — /etc/mongod.conf — pour lier également MongoDB à l’adresse IP routable publique de votre serveur. De cette façon, votre installation MongoDB sera en mesure d’écouter les connexions faites à votre serveur MongoDB à partir de machines distantes.

      Ouvrez le fichier de configuration de MongoDB dans votre éditeur de texte préféré. L’exemple suivant utilise nano :

      • sudo nano /etc/mongod.conf

      Trouvez la section network interfaces, puis la valeur bindIp :

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1
      
      . . .
      

      Ajoutez une virgule à cette ligne suivie de l’adresse IP publique de votre serveur MongoDB :

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1,mongodb_server_ip
      
      . . .
      

      Enregistrez et fermez le fichier. Si vous avez utilisé nano, faites-le en appuyant sur CTRL+X, Y, puis ENTER.

      Ensuite, redémarrez MongoDB pour mettre ce changement en vigueur :

      • sudo systemctl restart mongod

      Suite à cela, votre installation MongoDB sera en mesure d’accepter des connexions à distance à partir de toutes les machines que vous avez autorisées à accéder au port 27017. En dernière étape, vous pouvez vérifier si le serveur distant de confiance que vous avez autorisé à travers le pare-feu à l’Étape 1 peut atteindre l’instance de MongoDB exécutée sur votre serveur.

      Étape 3 — Test de la connectivité à distance

      Maintenant que vous avez configuré votre installation MongoDB pour écouter des connexions qui proviennent de son adresse IP publique routable et que vous avez accordé à votre machine distante l’accès au port par défaut de Mongo via le pare-feu de votre serveur, vous pouvez tester si la machine distante est capable de se connecter.

      Remarque : comme mentionné dans la section Conditions préalables, ce tutoriel suppose que votre machine distante est un autre serveur fonctionnant sous Ubuntu 20.04. La procédure d’activation des connexions à distance décrite aux Étapes 1 et 2 devrait fonctionner indépendamment du système d’exploitation de votre machine distante, mais les méthodes de test décrites dans cette étape ne fonctionnent pas de manière universelle pour tous les systèmes d’exploitation.

      Une façon de tester si votre serveur distant de confiance est capable de se connecter à l’instance MongoDB, consiste à utiliser la commande nc. nc, abréviation de netcat, est un utilitaire utilisé pour établir des connexions réseau avec TCP ou UDP. Il est utile pour effectuer des tests dans des cas comme celui-ci car il vous permet de spécifier à la fois une adresse IP et un numéro de port.

      Tout d’abord, connectez-vous à votre serveur de confiance en utilisant SSH :

      • ssh sammy@trusted_server_ip

      Ensuite, exécutez la commande nc suivante, qui inclut l’option -z. Cela limite nc à ne chercher qu’un démon d’écoute sur le serveur cible sans lui envoyer de données. Rappelez-vous du tutoriel d’installation préalable qui explique que MongoDB fonctionne en tant que démon service, ce qui rend cette option utile pour tester la connectivité. Elle inclut également l’option v qui augmente la verbosité de la commande, ce qui fait que netcat renvoie des données qu’il ne renverrait pas autrement.

      Exécutez la commande nc suivante à partir de votre serveur distant de confiance, en vous assurant de remplacer mongodb_server_ip par l’adresse IP du serveur sur lequel vous avez installé MongoDB :

      • nc -zv mongodb_server_ip 27017

      Si le serveur de confiance peut accéder au démon MongoDB, sa sortie indiquera que la connexion a réussi :

      Output

      Connection to mongodb_server_ip 27017 port [tcp/*] succeeded!

      En supposant que vous disposez d’une version compatible du shell mongo installé sur votre serveur distant, vous pouvez à ce stade vous connecter directement à l’instance de MongoDB installée sur le serveur hôte.

      Une façon de se connecter est d’utiliser une chaîne de connexion URI, comme celle-ci :

      • mongo "mongodb://mongo_server_ip:27017"

      Remarque : si vous avez suivi le tutoriel recommandé Comment sécuriser MongoDB sur Ubuntu 20.04, vous aurez fermé l’accès à votre base de données aux utilisateurs non authentifiés. Dans ce cas, vous devrez utiliser une URI spécifiant un nom d’utilisateur valide, comme celle-ci :

      • mongo "mongodb://username@mongo_server_ip:27017"

      Le shell vous invitera automatiquement à entrer le mot de passe de l’utilisateur.

      Avec cela, vous avez confirmé que votre serveur MongoDB pouvait accepter les connexions du serveur de confiance.

      Conclusion

      Vous pouvez maintenant accéder à votre installation MongoDB à partir d’un serveur distant. À ce stade, vous pouvez gérer à distance votre base de données Mongo du serveur de confiance. Vous pouvez également configurer une application pour qu’elle s’exécute sur le serveur de confiance et utiliser la base de données à distance.

      Si vous n’avez pas configuré d’utilisateur administratif et activé l’authentification, toute personne ayant accès à votre serveur distant peut également accéder à votre installation MongoDB. Si vous ne l’avez pas encore fait, nous vous recommandons fortement de suivre notre guide Comment sécuriser MongoDB sur Ubuntu 20.04 pour ajouter un utilisateur administratif et verrouiller les choses plus avant.



      Source link

      Comment configurer un serveur VPN IKEv2 avec StrongSwan sur Ubuntu 20.04


      Une version précédente de ce tutoriel a été rédigée par Justin Ellingwood et Namo

      Introduction

      Un réseau privé virtuel, ou VPN, vous permet de crypter en toute sécurité le trafic qui transite par des réseaux non fiables, comme ceux d’un coffee shop, d’une conférence ou d’un aéroport.

      Internet Key Exchange v2, ou IKEv2, est un protocole qui permet de créer un tunnel IPSec direct entre le serveur et le client. Dans les implémentations VPN IKEv2, IPSec assure le cryptage du trafic réseau. IKEv2 est pris en charge en natif sur certaines plateformes (OS X 10.11+, iOS 9.1+ et Windows 10) sans aucune application supplémentaire, et il gère les problèmes clients de manière assez fluide.

      Dans ce tutoriel, vous allez configurer un serveur VPN IKEv2 en utilisant StrongSwan sur un serveur Ubuntu 20.04. Vous apprendrez ensuite comment vous y connecter avec les clients Windows, macOS, Ubuntu, iOS et Android.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      Étape 1 — Installation de StrongSwan

      Tout d’abord, nous allons installer StrongSwan, un démon iPSec open source que nous allons configurer en tant que serveur VPN. Nous allons également installer le composant infrastructure de clé publique (ICP) afin que nous puissions créer une autorité de certification (AC) pour fournir des identifiants pour notre infrastructure.

      Commencez par mettre à jour le cache local du paquets :

      Ensuite, installez le logiciel en tapant :

      • sudo apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins

      Le paquet supplémentaire libcharon-extauth-plugins est utilisé pour vous assurer que divers clients puissent s’authentifier sur votre serveur à l’aide d’un nom d’utilisateur et d’une phrase de passe partagés.

      Maintenant que tout est installé, passons à la création de nos certificats.

      Étape 2 — Création d’une autorité de certification

      Un serveur IKEv2 requiert un certificat pour s’identifier auprès de ses clients. Pour vous aider à créer le certificat requis, le paquet strongswan-pki est livré avec un utilitaire appelé pki pour générer une autorité de certification et des certificats serveurs.

      Pour commencer, créons quelques répertoires pour stocker tous les actifs sur lesquels nous allons travailler. La structure du répertoire correspond à certains des répertoires dans /etc/ipsec.d, où nous allons déplacer tous les éléments que nous créons :

      • mkdir -p ~/pki/{cacerts,certs,private}

      Ensuite, nous verrouillerons les autorisations afin que nos fichiers privés ne puissent pas être vus par d’autres utilisateurs :

      Maintenant que nous avons une structure de répertoire pour tout stocker, nous pouvons générer une clé racine. Il s’agira d’une clé RSA 4096-bit qui sera utilisée pour signer notre autorité de certification racine.

      Exécutez ces commandes pour générer la clé :

      • pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/ca-key.pem

      Ensuite, nous pouvons passer à la création de notre autorité de certification racine, en utilisant la clé que nous venons de générer pour signer le certificat racine :

      • pki --self --ca --lifetime 3650 --in ~/pki/private/ca-key.pem
      • --type rsa --dn "CN=VPN root CA" --outform pem > ~/pki/cacerts/ca-cert.pem

      Le drapeau --lifetime 3650 est utilisé pour garantir que le certificat racine de l’autorité de certification sera valable pour 10 ans. Le certificat root pour une autorité ne change généralement pas, puisqu’il doit être redistribué à chaque serveur et chaque client qui en dépend, de sorte que 10 ans est une valeur de d’expiration par défaut sûre.

      Vous pouvez changer la valeur du nom distinctif (DN) par autre chose si vous le souhaitez. Le nom commun (champ CN) n’est que l’indicateur, il n’a donc pas à correspondre à quoi que ce soit dans votre infrastructure.

      Maintenant que nous disposons d’une autorité de certification racine opérationnelle, nous pouvons créer un certificat que le serveur VPN utilisera.

      Étape 3 — Génération d’un certificat pour le serveur VPN

      Nous allons maintenant créer un certificat et une clé pour le serveur VPN. Ce certificat permettra au client de vérifier l’authenticité du serveur à l’aide du certificat AC que nous venons de produire.

      Tout d’abord, créez une clé privée pour le serveur VPN avec la commande suivante :

      • pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/server-key.pem

      Maintenant, créez et signez le certificat serveur VPN avec la clé de l’autorité de certification que vous avez créée à l’étape précédente. Exécutez la commande suivante, mais changez le nom commun (CN) et le champ Subject Alternate Name (SAN) par le nom DNS ou à l’adresse IP de votre serveur VPN :

      • pki --pub --in ~/pki/private/server-key.pem --type rsa
      • | pki --issue --lifetime 1825
      • --cacert ~/pki/cacerts/ca-cert.pem
      • --cakey ~/pki/private/ca-key.pem
      • --dn "CN=server_domain_or_IP" --san server_domain_or_IP
      • --flag serverAuth --flag ikeIntermediate --outform pem
      • > ~/pki/certs/server-cert.pem

      Remarque : si vous utilisez une adresse IP au lieu d’un nom DNS, vous devrez spécifier plusieurs entrées --san. La ligne dans le bloc de commande précédent où vous spécifiez le nom distinct (--dn ...) devra être modifiée avec l’entrée supplémentaire comme la ligne extraite suivante :

      --dn "CN=IP address --san @IP_address --san IP_address 
      

      La raison de cette entrée supplémentaire --san @IP_address est que certains clients vérifieront si le certificat TLS comporte à la fois une entrée DNS et une entrée d’adresse IP pour un serveur lorsqu’ils vérifieront son identité.

      L’option server -flag Auth est utilisée pour indiquer que le certificat sera utilisé explicitement pour l’authentification du serveur, avant que le tunnel crypté ne soit établi. L’option --flag ikeIntermediate est utilisée pour soutenir les clients plus anciens de macOS.

      Maintenant que nous avons généré tous les fichiers TLS/SSL dont StrongSwan a besoin, nous pouvons déplacer les fichiers a leur place dans le répertoire /etc/ipsec.d en tapant :

      • sudo cp -r ~/pki/* /etc/ipsec.d/

      Au cours de cette étape, nous avons créé une paire de certificats qui sera utilisée pour sécuriser les communications entre le client et le serveur. Nous avons également signé les certificats avec la clé AC, afin que le client puisse vérifier l’authenticité du serveur VPN à l’aide du certificat AC. Une fois tous ces certificats prêts, nous allons passer à la configuration du logiciel.

      Étape 4 — Configuration de StrongSwan

      StrongSwan dipose d’un fichier de configuration par défaut avec quelques exemples, mais nous allons devoir faire la plupart de la configuration nous-mêmes. Sauvegardons le fichier pour référence avant de repartir de zéro :

      • sudo mv /etc/ipsec.conf{,.original}

      Créez et ouvrez un nouveau fichier de configuration vide à l’aide de votre éditeur de texte préféré. Ici, nous utiliserons nano :

      • sudo nano /etc/ipsec.conf

      Remarque : en parcourant cette section pour configurer la partie server de votre VPN, vous rencontrerez des paramètres qui font référence aux côtés gauche (left) et droit (right) d’une connexion. Lorsque vous travaillez avec les VPN d’IPSec, le côté left par convention fait référence au système local que vous configurez, dans ce cas le serveur. Les directives du côté droit de ces paramètres renverra à des clients distants comme des téléphones et autres ordinateurs.

      Lorsque vous passerez à la configuration des clients plus loin dans ce tutoriel, les fichiers de configuration du client se référeront à eux-mêmes en utilisant diverses directives left, et le serveur sera mentionné en utilisant la terminologie right.

      Tout d’abord, nous allons demander à StrongSwan d’enregistrer les états des démons pour le débogage et d’autoriser les connexions en double. Ajoutez ces lignes au fichier :

      /etc/ipsec.conf

      config setup
          charondebug="ike 1, knl 1, cfg 0"
          uniqueids=no
      

      Ensuite, nous allons créer une section de configuration pour notre VPN. Nous allons également indiquer à StrongSwan de créer des tunnels VPN IKEv2 et de charger automatiquement cette section de configuration au démarrage. Ajoutez les lignes suivantes au fichier :

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          auto=add
          compress=no
          type=tunnel
          keyexchange=ikev2
          fragmentation=yes
          forceencaps=yes
      

      Nous allons également configurer la détection de dead-peer pour effacer les connexions “en suspens” au cas où le client se déconnecte de manière inattendue. Ajoutez ces lignes :

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          dpdaction=clear
          dpddelay=300s
          rekey=no
      

      Ensuite, nous allons configurer les paramètres iPSec côté “left” du serveur. Chacun des paramètres suivants garantit que le serveur est configuré pour accepter les connexions des clients et pour s’identifier correctement. Vous ajouterez chacun de ces paramètres au fichier /etc/ipsec.conf une fois que vous serez familiarisé avec ce qu’ils sont et pourquoi ils sont utilisés :

      • left=%any La valeur %any garantit que le serveur utilisera l’interface réseau où il reçoit les connexions entrantes pour les communications ultérieures avec les clients. Par exemple, si vous connectez un client sur un réseau privé, le serveur utilisera l’adresse IP privée où il reçoit le trafic pour le reste de la connexion.
      • leftid=@server_domain_or_IP Cette option contrôle le nom que le serveur présente aux clients. Combiné à l’option suivante leftcert, l’option leftid garantit que le nom configuré du serveur et le nom distinctif (DN) contenus dans le certificat public correspondent.
      • leftcert=server-cert.pem Cette option est le chemin d’accès au certificat public pour le serveur que vous avez configuré à l’Étape 3. Sans celui-ci, le serveur ne pourra pas s’authentifier lui-même aupr1es des clients, ou terminer de négocier la configuration d’IKEv2.
      • leftsendcert=always La valeur always garantit que tout client qui se connecte au serveur recevra toujours une copie du certificat public du serveur dans le cadre de la configuration initiale de la connexion.
      • leftsubnet=0.0.0.0/0 La dernière option de côté “left” que vous ajouterez indique aux clients les sous réseaux qui sont accessibles derrière le serveur. Dans ce cas, 0.0.0.0/0 est utilisé pour représenter l’ensemble des adresses IPv4, ce qui signifie que le serveur indiquera aux clients d’envoyer tout leur trafic sur le VPN par défaut.

      Maintenant que vous êtes familiarisé avec chacune des options du côté “left”, ajoutez-les toutes dans le fichier, comme ceci :

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          left=%any
          leftid=@server_domain_or_IP
          leftcert=server-cert.pem
          leftsendcert=always
          leftsubnet=0.0.0.0/0
      

      Remarque : Lorsque vous configurez l’ID du serveur (leftid), n’incluez le caractère @ que si votre serveur VPN sera identifié par un nom de domaine :

      /etc/ipsec.conf

          . . .    leftid=@vpn.example.com
          . . .
      

      Si le serveur doit être identifié par son adresse IP, ajoutez simplement l’adresse IP :

      /etc/ipsec.conf

          . . .
          leftid=your_server_ip
          . . .
      

      Ensuite, nous pouvons configurer les paramètres iPSec du côté “right” du client. Chacun des paramètres suivants indique au serveur comment accepter les connexions des clients, comment les clients devraient s’authentifier auprès du serveur, et les plages d’adresse IP privées et les serveurs DNS que les clients utiliseront. Ajoutez chacun de ces paramètres au fichier /etc/ipsec.conf une fois que vous êtes familiarisé avec ce qu’ils sont et pourquoi ils sont utilisés :

      • right=%any L’option %any pour le côté right de la connexion permet au serveur d’accepter les connexions entrantes d’un client distant.
      • rightid=%any Cette option garantit que le serveur ne rejettera pas les connexions des clients qui fournissent une identité avant que le tunnel crypté ne soit établi.
      • rightauth=eap-mschapv2 Cette option configure la méthode d’authentification que les clients utiliseront pour s’authentifier sur le serveur. eap-mschapv2 est utilisé ici pour une large compatibilité pour prendre en charge des clients comme Windows, macOS et Android.
      • rightsourceip=10.10.10.0/24 Cette option permet au serveur d’attribuer des adresses IP privées aux clients du pool d’IP 10.10.10.0/24 spécifié.
      • rightdns=8.8.8.8,8.8.4.4 Ces adresses IP sont les résolveurs DNS publics de Google. Ils peuvent être modifiés pour utiliser d’autres paramètres publics, les résolveurs du serveur VPN ou tout autre résolveur que les clients peuvent atteindre.
      • rightsendcert=never Cette option indique au serveur que les clients n’ont pas à envoyer de certificat pour s’authentifier.

      Maintenant que vous êtes familiarisé avec les options du côté “right” nécessaires pour le VPN, ajoutez les lignes suivantes dans /etc/ipsec.conf :

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          right=%any
          rightid=%any
          rightauth=eap-mschapv2
          rightsourceip=10.10.10.0/24
          rightdns=8.8.8.8,8.8.4.4
          rightsendcert=never
      

      Nous allons maintenant indiquer à StrongSwan de demander au client ses identifiants d’utilisateur lorsqu’ils se connectent :

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          eap_identity=%identity
      

      Enfin, ajoutez les lignes suivantes pour prendre en charge les clients Linux, Windows, macOS, iOS et Android. Ces lignes spécifient les différents algorithmes d’échange de clés, de hachage,d’authentification et de cryptage (communément appelés Suites de chiffrement) que StrongSwan permettra à différents clients d’utiliser :

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
          esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
      

      Chaque suite de chiffrement prise en charge est délimitée des autres par une virgule. Par exemple, chacha20poly1305-sha512-curve25519-prfsha512 est une suite, et aes256gcm16-sha384-prfsha384-ecp384 est une autre. Les suites de chiffrement qui sont énumérées ici sont sélectionnées pour garantir la plus large compatibilité entre les clients Windows, macOS, iOS, Android et Linux.

      La configuration complète devrait ressembler à ceci :

      /etc/ipsec.conf

      config setup
          charondebug="ike 1, knl 1, cfg 0"
          uniqueids=no
      
      conn ikev2-vpn
          auto=add
          compress=no
          type=tunnel
          keyexchange=ikev2
          fragmentation=yes
          forceencaps=yes
          dpdaction=clear
          dpddelay=300s
          rekey=no
          left=%any
          leftid=@server_domain_or_IP
          leftcert=server-cert.pem
          leftsendcert=always
          leftsubnet=0.0.0.0/0
          right=%any
          rightid=%any
          rightauth=eap-mschapv2
          rightsourceip=10.10.10.0/24
          rightdns=8.8.8.8,8.8.4.4
          rightsendcert=never
          eap_identity=%identity
          ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
          esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
      

      Sauvegardez et fermez le fichier une fois que vous avez vérifié que vous avez correctement ajouté chaque ligne. Si vous avez utilisé nano, faites-le en appuyant sur CTRL+X, Y, puis ENTER.

      Maintenant que nous avons configuré les paramètres VPN, passons à la création d’un compte afin que nos utilisateurs puissent se connecter au serveur.

      Étape 5 — Configuration de l’authentification VPN

      Notre serveur VPN est maintenant configuré pour accepter les connexions client, mais nous n’avons pas encore configuré d’identifiants. Nous allons devoir configurer quelques éléments dans un fichier de configuration spécial appelé ipsec.secrets :

      • Nous devons indiquer à StrongSwan où trouver la clé privée pour notre certificat de serveur, afin que le serveur puisse s’authentifier auprès de ses clients.
      • Nous devons également mettre en place une liste d’utilisateurs qui seront autorisés à se connecter au VPN.

      Ouvrons le fichier secrets pour le modifier :

      • sudo nano /etc/ipsec.secrets

      Tout d’abord, nous allons indiquer à StrongSwan où trouver notre clé privée :

      /etc/ipsec.secrets

      : RSA "server-key.pem"
      

      Ensuite, nous définirons les identifiants de l’utilisateur. Vous pouvez choisir toute combinaison de nom d’utilisateur ou de mot de passe que vous souhaitez :

      /etc/ipsec.secrets

      your_username : EAP "your_password"
      

      Enregistrez et fermez le fichier. Maintenant que nous avons fini de travailler avec les paramètres du VPN, nous allons redémarrer le service VPN afin que notre configuration soit appliquée :

      • sudo systemctl restart strongswan-starter

      Maintenant que le serveur VPN a été entièrement configuré avec les options du serveur et les identifiants de l’utilisateur, il est temps de passer à la configuration de la partie la plus importante : le pare-feu.

      Étape 6 — Configuration du pare-feu et de la redirection du noyau IP

      Une fois la configuration de StrongSwan terminée, nous devons configurer le pare-feu pour autoriser le passage et la redirection du trafic VPN au travers de celui-ci.

      Si vous avez suivi le guide de configuration initiale du serveur, vous devriez disposer d’un pare-feu UFW activé. Si vous n’avez pas encore configuré UFW, vous devriez commencer par ajouter une règle pour autoriser les connexions SSH au travers du pare-feu afin que votre session actuelle ne se ferme pas lorsque vous activez UFW :

      Ensuite, activez le pare-feu en tapant :

      Ensuite, ajoutez une règle pour autoriser le trafic UDP aux ports IPSec standard, 500 et 4500 :

      • sudo ufw allow 500,4500/udp

      Ensuite, nous allons ouvrir l’un des fichiers de configuration d’UFW pour ajouter quelques politiques de bas niveau pour le routage et la transmission de paquets IPSec. Mais avant cela, nous devons trouver quelle interface réseau sur notre serveur est utilisée pour l’accès à Internet. Trouvez cette interface en recherchant le périphérique associé à la route par défaut :

      Votre interface publique doit suivre le mot “dev”. Par exemple, ce résultat montre l’interface nommée eth0, qui est mise en évidence dans l’exemple qui suit  :

      Output

      default via your_server_ip dev eth0 proto static

      Lorsque vous disposez de votre interface de réseau public, ouvrez le fichier /etc/ufw/before.rules dans votre éditeur de texte. Les règles dans ce fichier sont ajoutées au pare-feu avant le reste des règles habituelles d’entrée et de sortie. Elles sont utilisées pour configurer la traduction d’adresse du réseau (NAT) afin que le serveur puisse correctement acheminer les connexions vers et depuis les clients et l’Internet.

      • sudo nano /etc/ufw/before.rules

      En haut du fichier (avant la ligne *filtre), ajoutez le bloc de configuration suivant. Modifiez chaque instance de eth0 dans la configuration ci-dessus pour qu’elle corresponde au nom de l’interface que vous avez trouvé avec ip route. Les lignes *nat créent des règles afin que le pare-feu puisse correctement acheminer et manipuler le trafic entre les clients VPN et Internet. La ligne *mangle ajuste la taille maximale du segment de paquets pour prévenir les problèmes potentiels avec certains clients VPN :

      /etc/ufw/before.rules

      *nat
      -A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT
      -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
      COMMIT
      
      *mangle
      -A FORWARD --match policy --pol ipsec --dir in -s 10.10.10.0/24 -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
      COMMIT
      
      *filter
      :ufw-before-input - [0:0]
      :ufw-before-output - [0:0]
      :ufw-before-forward - [0:0]
      :ufw-not-local - [0:0]
      . . .
      

      Ensuite, après les lignes *filter et de définition de chaîne, ajoutez un autre bloc de configuration :

      /etc/ufw/before.rules

      . . .
      *filter
      :ufw-before-input - [0:0]
      :ufw-before-output - [0:0]
      :ufw-before-forward - [0:0]
      :ufw-not-local - [0:0]
      
      -A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s 10.10.10.0/24 -j ACCEPT
      -A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d 10.10.10.0/24 -j ACCEPT
      

      Ces lignes indiquent au pare-feu qu’il doit acheminer le trafic ESP (Encapsulating Security Payload) afin que les clients VPN puissent se connecter. ESP fournit une sécurité supplémentaire pour nos paquets VPN lorsqu’ils traversent les réseaux non fiables.

      Lorsque vous avez terminé, sauvegardez et fermez le fichier après avoir vérifié que vous avez correctement ajouté chaque ligne. Si vous avez utilisé nano, faites-le en appuyant sur CTRL+X, Y, puis ENTER.

      Avant de redémarrer, nous allons modifier certains paramètres du noyau réseau pour permettre le routage d’une interface à une autre. Le fichier qui contrôle ces paramètres est appelé /etc/ufw/sysctl.conf. Nous allons devoir configurer quelques éléments dans le fichier, et notamment :

      Le premier transfert de paquets IPv4 doit être activé afin que le trafic puisse circuler entre le VPN et les interfaces réseau publiques sur le serveur. Ensuite, nous allons désactiver la découverte de Path MTU pour prévenir les problèmes de fragmentation des paquets. Enfin, nous n’accepterons pas les redirections ICMP ni n’enverrons de redirections ICMP pour prévenir les attaques man-in-the-middle.

      Ouvrez le fichier de configuration des paramètres du noyau d’UFW en utilisant nano ou votre éditeur de texte préféré :

      • sudo nano /etc/ufw/sysctl.conf

      Ajoutez maintenant le paramètre net/ipv4/ip_forward=1 suivant à la fin du fichier pour activer la transmission de paquets entre les interfaces :

      /etc/ufw/sysctl.conf

      . . .
      net/ipv4/ip_forward=1
      

      Ensuite, bloquez l’envoi et la réception de paquets de redirection ICMP en ajoutant les lignes suivantes à la fin du fichier :

      /etc/ufw/sysctl.conf

      . . .
      net/ipv4/conf/all/accept_redirects=0
      net/ipv4/conf/all/send_redirects=0
      

      Enfin, désactivez la découverte de Path MTU en ajoutant cette ligne à la fin du fichier :

      /etc/ufw/sysctl.conf

      . . .
      net/ipv4/ip_no_pmtu_disc=1
      

      Enregistrez le fichier lorsque vous avez terminé. Nous pouvons maintenant activer toutes nos modifications en désactivant et en réactivant le pare-feu, car UFW applique ces paramètres à chaque fois qu’il redémarre :

      • sudo ufw disable
      • sudo ufw enable

      Vous serez invité à confirmer le processus. Tapez Y pour réactiver UFW avec les nouveaux paramètres.

      Étape 7 — Test de la connexion VPN sur Windows, macOS, Ubuntu, iOS et Android

      Maintenant que vous avez tout configuré, il est temps essayerd’. Tout d’abord, vous devrez copier le certificat AC que vous avez créé et l’installer sur votre ou vos dispositif(s) client(s) qui se connecteront au VPN. La manière la plus simple de le faire consiste à vous connecter à votre serveur et à générer le contenu du fichier de certificat :

      • cat /etc/ipsec.d/cacerts/ca-cert.pem

      Vous verrez une sortie semblable à celle-ci :

      Output

      -----BEGIN CERTIFICATE----- MIIFNDCCAxygAwIBAgIIHCsidG5mXzgwDQYJKoZIhvcNAQEMBQAwODELMAkGA1UE . . . H2YUdz8XNHrJHvMQKWFpi0rlEcMs+MSXPFWE3Q7UbaZJ/h8wpSldSUbQRUlphExJ dJ4PX+MUJO/vjG1/ie6Kh25xbBAc3qNq8siiJZDwrg6vjEK7eiZ1rA== -----END CERTIFICATE-----

      Copiez cette sortie sur votre ordinateur, y compris les lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----,et enregistrez-la dans un fichier avec un nom reconnaissable, tel que ca-cert.pem Assurez-vous que le fichier que vous créez porte bien l’extension .pem.

      Vous pouvez également utiliser le protocole SFTP pour transférer le fichier à votre ordinateur.

      Une fois le fichier ca-cert.pem téléchargé sur votre ordinateur, vous pouvez configurer la connexion au VPN.

      Connexion à partir de Windows

      Il existe de multiples façons d’importer le certificat racine et configurer Windows pour qu’il se connecte à un VPN. La première méthode utilise des outils graphiques pour chaque étape. La deuxième méthode utilise les commandes PowerShell, qui peuvent être scriptées et modifiées en fonction de votre configuration VPN.

      Remarque : ces instructions ont été testées sur les installations Windows 10 exécutant les versions 1903 et 1909.

      Configuration de Windows avec des outils graphiques

      Tout d’abord, importez le certificat racine en suivant ces étapes :

      1. Appuyez sur WINDOWS+R pour faire apparaître la boîte de dialogue Run, et entrez mmc.exe pour lancer la console de gestion de Windows.
      2. Dans le menu File, naviguez jusqu’à Add or Remove Snap-in, sélectionnez Certificates dans la liste des instantanés disponibles, et cliquez sur Add.
      3. Nous voulons que le VPN fonctionne avec n’importe quel utilisateur, donc sélectionnez Computer Account et cliquez sur Next.
      4. Nous configurons les choses sur l’ordinateur local, donc sélectionnez Local Computer, puis cliquez sur Finish.
      5. Sous le nœud Console Root, développez l’entrée Certificates (Local Computer), développez Trusted Root Certification Authorities, puis sélectionnez l’entrée CertificatesCertificates view

      6. Dans le menu Action, sélectionnez All tasks et cliquez sur Import pour afficher l’Assistant d’importation de certificat. Cliquez sur Next pour passer l’introduction.

      7. Dans l’écran de File to Import, cliquez sur le bouton Browse, veillez à changer le type de fichier de “X.509 Certificate (.cer;.crt)” à “All Files (. )”, et sélectionnez le fichier ca-cert.pem que vous avez enregistré. Ensuite, cliquez sur Next.

      8. Assurez-vous que le Certificate Store est configuré à Trusted Root Certification Authorities, et cliquez sur Next.

      9. Cliquez sur Finish pour importer le certificat.

      Ensuite, configurez le VPN avec ces étapes :

      1. Lancez Control Panel, puis naviguez jusqu’au Network and Sharing Center.
      2. Cliquez sur Set up a new connection or network, puis sélectionnez Connect to a workplace.
      3. Sélectionnez Use my Internet connection (VPN).
      4. Entrez les détails du serveur VPN. Entrez le nom de domaine ou l’adresse IP du serveur dans le champ Internet address, puis remplissez Destination name avec quelque chose qui décrit votre connexion VPN. Ensuite, cliquez sur Done.

      Configuration de Windows en utilisant PowerShell

      Pour importer le certificat racine AC à l’aide de PowerShell, ouvrez d’abord une invite PowerShell avec des privilèges d’administrateur. Pour ce faire, cliquez avec le bouton droit sur l’icône du menu Démarrer et sélectionnez Windows PowerShell (Admin). Vous pouvez également ouvrir une invite de commande en tant qu’administrateur et taper powershell.

      Ensuite, nous allons importer le certificat en utilisant le cmdlet PowerShellImport-Certificate. Dans la commande suivante, le premier argument -CertStoreLocation garantira que le certificat est importé dans le magasin Trusted Root Certification Authorities de l’ordinateur afin que tous les programmes et utilisateurs puissent vérifier le certificat du serveur VPN. L’argument -FilePath doit indiquer l’emplacement où vous avez copié le certificat. Dans l’exemple suivant, le chemin est C:UserssammyDocumentsca-cert.pem. Assurez-vous de modifier la commande pour qu’elle corresponde à l’emplacement que vous avez utilisé.

      • Import-Certificate `
      • -CertStoreLocation cert:LocalMachineRoot `
      • -FilePath C:userssammyDocumentsca-cert.pem

      La commande produira quelque chose comme ce qui suit :

      Output

      PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot Thumbprint Subject ---------- ------- DB00813B4087E9367861E8463A60CEA0ADC5F002 CN=VPN root CA

      Maintenant pour configurer le VPN en utilisant PowerShell, exécutez la commande suivante. Remplacez le nom DNS ou l’adresse IP de votre serveur sur la ligne -ServerAddress Les différents drapeaux veilleront à ce que Windows soit correctement configuré avec les paramètres de sécurité appropriés qui correspondent aux options que vous avez définies dans /etc/ipsec.conf.

      • Add-VpnConnection -Name "VPN Connection" `
      • -ServerAddress "server_domain_or_IP" `
      • -TunnelType "IKEv2" `
      • -AuthenticationMethod "EAP" `
      • -EncryptionLevel "Maximum" `
      • -RememberCredential `

      Si la commande est réussie, il n’y aura pas de sortie. Pour confirmer que le VPN est correctement configuré, utilisez l’applet de commande Get-VPNConnection :

      • Get-VpnConnection -Name "VPN Connection"

      Vous allez recevoir une sortie comme suit :

      Output

      Name : VPN Connection ServerAddress : your_server_ip AllUserConnection : False Guid : {B055A1AB-175C-4028-B4A8-D34309A2B20E} TunnelType : Ikev2 AuthenticationMethod : {Eap} EncryptionLevel : Maximum L2tpIPsecAuth : UseWinlogonCredential : False EapConfigXmlStream : #document ConnectionStatus : Disconnected RememberCredential : True SplitTunneling : False DnsSuffix : IdleDisconnectSeconds : 0

      Par défaut, Windows choisit les algorithmes plus anciens et plus lents. Exécutez l’applet de commande Set-VpnConnectionIPsecConfiguration pour mettre à niveau les paramètres de cryptage que Windows utilisera pour l’échange de clés IKEv2 et pour crypter les paquets :

      • Set-VpnConnectionIPsecConfiguration -Name "VPN Connection" `
      • -AuthenticationTransformConstants GCMAES256 `
      • -CipherTransformConstants GCMAES256 `
      • -DHGroup ECP384 `
      • -IntegrityCheckMethod SHA384 `
      • -PfsGroup ECP384 `
      • -EncryptionMethod GCMAES256

      Remarque : si vous souhaitez supprimer la connexion VPN et la reconfigurer avec différentes options, vous pouvez exécuter l’applet de commande Remove-VpnConnection.

      • Remove-VpnConnection -Name "VPN Connection" -Force

      Le drapeau -Force sautera l’invitation à confirmer la suppression. Vous devez être déconnecté du VPN si vous essayez de le supprimer à l’aide de cette commande.

      Connexion au VPN

      Une fois le certificat importé et le VPN configuré en utilisant l’une ou l’autre méthode, votre nouvelle connexion VPN sera visible sous la liste des réseaux. Sélectionnez le VPN et cliquez sur Connect. Vous serez invité à indiquer votre nom d’utilisateur et votre mot de passe. Entrez ces éléments, cliquez sur OK, et vous serez connecté.

      Connexion à partir de macOS

      Suivez ces étapes pour importer le certificat :

      1. Double-cliquez sur le fichier de certificat. Keychain Access apparaîtra avec une boîte de dialogue indiquant “Keychain Access essaie de modifier le keychain système. Entrez votre mot de passe pour l’autoriser.”
      2. Entrez votre mot de passe, puis cliquez sur Modify Keychain
      3. Double-cliquez sur le certificat VPN nouvellement importé. Cela génère une petite fenêtre de propriétés dans laquelle vous pouvez spécifier les niveaux de confiance. Définissez IP Security (IPSec) sur Always Trust et vous serez invité à nouveau à introduire votre mot de passe. Ce paramètre s’enregistre automatiquement après avoir entré le mot de passe.

      Maintenant que le certificat est importé et fiable, configurez la connexion VPN en suivant ces étapes :

      1. Allez dans les System Preferences et choisissez Network.
      2. Cliquez sur le petit bouton “plus” dans la partie inférieure à gauche de la liste des réseaux.
      3. Dans le popup qui apparaît, définissez Interface sur VPN, définissez VPN Type sur IKEv2 et donnez un nom à la connexion.
      4. Dans le champ Server et Remote ID , entrez le nom de domaine ou l’adresse IP du serveur. Laissez Local ID vierge.
      5. Cliquez sur Authentication Settings, sélectionnez Username, et entrez votre nom d’utilisateur et votre mot de passe que vous avez configuré pour votre utilisateur VPN. Ensuite, cliquez sur OK.

      Enfin, cliquez sur Connect pour vous connecter au VPN. Vous devriez maintenant être connecté au VPN.

      Connexion à partir d’Ubuntu

      Pour vous connecter à partir d’une machine Ubuntu, vous pouvez configurer et gérer StrongSwan comme service ou utiliser une commande unique chaque fois que vous souhaitez vous connecter. Des instructions sont fournies pour les deux.

      Gérer StrongSwan en tant que service

      Pour gérer StrongSwan en tant que service, vous devrez effectuer les étapes de configuration suivantes.

      Tout d’abord, mettez à jour votre cache local de paquets en utilisant apt

      Ensuite, installez StrongSwan et les plugins nécessaires à l’authentification :

      • sudo apt install strongswan libcharon-extra-plugins

      Vous aurez maintenant besoin d’une copie du certificat AC dans le répertoire /etc/ipsec.d/cacerts afin que votre client puisse vérifier l’identité du serveur. Exécutez la commande suivante pour copier le fichier ca-cert.pem en place :

      • sudo cp /tmp/ca-cert.pem /etc/ipsec.d/cacerts

      Pour vous assurer que le VPN fonctionne uniquement sur demande, utilisez systemctl pour désactiver l’exécution automatique de StrongSwan :

      • sudo systemctl disable --now strongswan-starter

      Ensuite, configurez le nom d’utilisateur et le mot de passe que vous utiliserez pour vous authentifier auprès du serveur VPN. Modifiez /etc/ipsec.secrets en utilisant nano ou votre éditeur préféré :

      • sudo nano /etc/ipsec.conf

      Ajoutez la ligne suivante, en modifiant les valeurs du nom d’utilisateur et du mot de passe mis en évidence pour qu’ils correspondent à celles que vous avez configurées sur le serveur :

      /etc/ipsec.conf

      your_username : EAP "your_password"
      

      Enfin, modifiez le fichier /etc/ipsec.conf pour configurer votre client afin qu’il corresponde à la configuration du serveur :

      /etc/ipsec.conf

      config setup
      
      conn ikev2-rw
          right=server_domain_or_IP
          # This should match the `leftid` value on your server's configuration
          rightid=server_domain_or_IP
          rightsubnet=0.0.0.0/0
          rightauth=pubkey
          leftsourceip=%config
          leftid=username
          leftauth=eap-mschapv2
          eap_identity=%identity
          auto=start
      

      Pour vous connecter au VPN, tapez :

      • sudo systemctl start strongswan-starter

      Pour vous déconnecter à nouveau, tapez :

      • sudo systemctl stop strongswan-starter

      Utilisation du client charon-cmd pour les connexions uniques.

      Pour gérer StrongSwan en tant que service, vous devrez effectuer les étapes de configuration suivantes.

      Tout d’abord, mettez à jour votre cache local de paquets en utilisant apt

      Ensuite, installez StrongSwan et les plugins nécessaires à l’authentification :

      • sudo apt install strongswan libcharon-extra-plugins

      Vous aurez maintenant besoin d’une copie du certificat AC dans le répertoire /etc/ipsec.d/cacerts afin que votre client puisse vérifier l’identité du serveur. Exécutez la commande suivante pour copier le fichier ca-cert.pem en place :

      • sudo cp /tmp/ca-cert.pem /etc/ipsec.d/cacerts

      À ce stade, vous pouvez vous connecter au serveur VPN avec charon-cmd en utilisant le certificat AC du serveur, l’adresse IP du serveur VPN et le nom d’utilisateur que vous avez configuré.

      Exécutez la commande suivante chaque fois que vous souhaitez vous connecter au VPN :

      • sudo charon-cmd --cert ca-cert.pem --host vpn_domain_or_IP --identity your_username

      Lorsque vous y êtes invité, fournissez le mot de passe de l’utilisateur VPN et vous serez connecté au VPN. Pour vous déconnecter, appuyez sur CTRL+C dans le terminal et attendez que la connexion se ferme.

      Connexion à partir d’iOS

      Pour configurer la connexion VPN sur un appareil iOS, procédez comme suit :

      1. Envoyez-vous un email avec le certificat racine en annexe.
      2. Ouvrez l’adresse électronique sur votre appareil iOS et appuyez sur le fichier de certificat joint, puis appuyez sur Install et entrez votre code secret. Une fois qu’il s’installe, appuyez sur Done.
      3. Allez dansSs,etting General, VPN et appuyez sur Add VPN Configuration. Cela fera apparaître l’écran de configuration de connexion VPN.
      4. Appuyez sur Type et sélectionnez IKEv2.
      5. Dans le champ Description , entrez un nom court pour la connexion VPN. Cela peut être tout ce que vous voulez.
      6. Dans le champ Server et Remote ID , entrez le nom de domaine ou l’adresse IP du serveur. Le champ Local ID peut être laissé vierge.
      7. Entrez votre nom d’utilisateur et votre mot de passe dans la section Authentication, puis appuyez sur Done.
      8. Sélectionnez la connexion VPN que vous venez de créer, appuyez sur l’interrupteur en haut de la page, et vous serez connecté.

      Connexion à partir d’Android

      Suivez ces étapes pour importer le certificat :

      1. Envoyez-vous un email avec le certificat AC en annexe. Sauvegardez le certificat AC dans votre dossier de téléchargements.
      2. Téléchargez le client VPN StrongSwan dans le Play Store.
      3. Ouvrez l’application. Appuyez sur l’icône “more” () dans le coin supérieur droit et sélectionnez CA certificates.
      4. Appuyez à nouveau sur l’icône “more” () dans le coin supérieur droit. Sélectionnez Import certificat.
      5. Naviguez vers le fichier certificat AC dans votre dossier de téléchargements et sélectionnez-le pour l’importer dans l’application.

      Maintenant que le certificat est importé dans l’application StrongSwan, vous pouvez configurer la connexion VPN en suivant ces étapes :

      1. Dans l’application, appuyez sur ADD VPN PROFILE en haut.
      2. Remplissez Server avec le nom de domaine ou l’adresse IP publique de votre serveur VPN.
      3. Assurez-vous que IKEv2 EAP (Username/Password) est sélectionné comme Type de VPN.
      4. Remplissez les champs Username et Password avec les identifiants que vous avez définis sur le serveur.
      5. Désélectionnez Select automatically dans la section CA certificate et cliquez sur Select CA certificate.
      6. Appuyez sur l’onglet IMPORTED en haut de l’écran et choisissez l’AC que vous avez importé (il sera nommé “VPN root CA” si vous n’avez pas changé le nom “DN” auparavant).
      7. Si vous le souhaitez, remplissez Profile name (optional) avec un nom plus descriptif.

      Lorsque vous souhaitez vous connecter au VPN, cliquez sur le profil que vous venez de créer dans l’application StrongSwan.

      Dépannage des Connexions

      Si vous n’êtes pas en mesure d’importer le certificat, vérifiez que le fichier a l’extension .pem, et non pas .pem.txt.

      Si vous n’êtes pas en mesure de vous connecter au VPN, vérifiez le nom du serveur ou l’adresse IP que vous avez utilisée. Le nom de domaine ou l’adresse IP du serveur doit correspondre à ce que vous avez configuré en tant que nom commun (CN) en créant le certificat. S’ils ne correspondent pas, la connexion VPN ne fonctionnera pas. Par exemple, si vous configurez un certificat avec le CN de vpn.example.com, vous devez utiliser vpn.example.com lorsque vous entrez les détails du serveur VPN. Vérifiez scrupuleusement la commande que vous avez utilisée pour générer le certificat, et les valeurs que vous avez utilisées lors de la création de votre connexion VPN.

      Enfin, vérifiez bien la configuration VPN pour vous assurer que la valeur leftid est configurée avec le symbole @ si vous utilisez un nom de domaine :

      /etc/ipsec.conf

          leftid=@vpn.example.com
      

      Si vous utilisez une adresse IP, veillez à ce que le symbole @ soit absent. Assurez-vous également que lorsque vous avez généré le fichier server-cert.pem, vous avez inclus à la fois les drapeaux --san @IP_address et --san IP_address.

      Conclusion

      Dans ce tutoriel, vous avez construit un serveur VPN qui utilise le protocole IKEv2. Vous avez appris les directives qui contrôlent les côtés left et right d’une connexion, tant sur le serveur et que sur les clients. Vous avez également configuré un client Windows, macOS, iOS, Android ou Linux pour vous connecter au VPN.

      Pour ajouter ou supprimer des utilisateurs, passez à nouveau à l’Étape 5. Chaque ligne dans /etc/ipsec.secrets est pour un utilisateur, donc ajouter ou supprimer les utilisateurs, ou modifier les mots de passe requiert simplement d’éditer le fichier.

      Vous pouvez désormais êtres vous assuré que vos activités en ligne resteront sécurisées où que vous alliez et avec tout appareil que vous utilisez pour accéder à Internet.



      Source link