VpnHood!

Connexion via un nom de domaine

Par défaut, le serveur utilise un certificat auto-signé générique et ses clés d'accès pointent vers son adresse IP. Associez-lui votre propre nom de domaine avec un certificat reconnu pour que votre trafic ressemble à une simple visite sur un site web.

Pourquoi utiliser un nom de domaine ?

Les clés générées après coup intègrent ce domaine. Les applications résolvent le nom et vérifient le certificat comme le ferait un navigateur : si l'adresse IP du serveur change, il suffit de mettre à jour le domaine pour que les clés continuent de fonctionner.

Les clés conservent également l'adresse IP du serveur : si une application ne peut pas résoudre le domaine, elle se connecte comme auparavant.

Avant de commencer

  • Un domaine ou sous-domaine que vous contrôlez, par exemple vpn.example.com. Utilisez un nom d'hôte précis, pas un joker (wildcard).
  • Un enregistrement DNS pointant vers l'IP de connexion du serveur : un enregistrement A, et un enregistrement AAAA si le serveur utilise IPv6. Pointez directement vers le serveur, sans passer par le proxy d'un CDN.
  • Sur un serveur géré, maintenez le port TCP 80 ouvert en permanence : il sert à valider le certificat et à le renouveler automatiquement tous les quelques mois.

Sur un serveur géré

  1. Dans VpnHood! MANAGER, ouvrez Server Farms puis votre groupe de serveurs. Sous SSL / TLS Certificates, cliquez sur Add, saisissez le domaine dans Domain Name et validez avec Create. MANAGER crée alors un certificat auto-signé et l'affiche.
  2. Modifiez Signing et choisissez AutoSign. MANAGER demande un certificat à Let's Encrypt, qui valide le domaine via votre serveur sur le port TCP 80. Une fois validé, Signature indique CA Signed, et MANAGER renouvellera le certificat automatiquement avant expiration.
  3. Modifiez ensuite Visibility pour sélectionner PublicInToken. Toutes les clés du groupe intègrent désormais le domaine, et l'ancien certificat du groupe passe en Public.

Les clés copiées depuis MANAGER intègrent désormais ce domaine. Les applications avec une ancienne clé recevront automatiquement la mise à jour à la connexion grâce à l'option Push token to clients activée par défaut. Conservez l'ancien certificat jusque-là : les anciennes clés en ont besoin pour fonctionner.

En cas d'échec de la vérification, Signing en indique la raison ; après plusieurs tentatives infructueuses, l'état repasse à Manual. Corrigez vos DNS ou ouvrez le port requis, puis sélectionnez de nouveau AutoSign.

Pour vérifier, ouvrez le groupe de serveurs : sous Access Points, votre domaine doit apparaître en premier.

La page dédiée à chaque serveur contient aussi une section SSL / TLS Certificates. Tout certificat ajouté ici ne concerne que ce serveur précis : pensez bien à ajouter au groupe le domaine destiné à vos clés.

Sur un serveur autonome

Un serveur autonome ne peut pas obtenir de certificat automatiquement. Procurez-vous-en un pour le domaine auprès d'une autorité de certification (fichier PFX avec sa clé privée), puis remplacez /opt/VpnHoodServer/storage/access/certificates/default.pfx en conservant le même nom.

Indiquez ensuite le mot de passe du fichier dans SslCertificatesPassword et définissez IsValidHostName sur true, tous deux sous FileAccessManager dans /opt/VpnHoodServer/storage/appsettings.json. Ce fichier n'existe pas sur une nouvelle installation : créez-le pour que le serveur l'utilise à la place de sa configuration initiale.

Le fichier complet, en remplaçant la valeur d'exemple par le mot de passe de votre certificat

{
  "FileAccessManager": {
    "SslCertificatesPassword": "your-pfx-password",
    "IsValidHostName": true
  },
  "ServerConfig": {
    "LogAnonymizer": true,
    "AddListenerIpsToNetwork": "*"
  },
  "LogLevel": "Information"
}

Le serveur extrait directement le domaine depuis le certificat : aucun paramètre supplémentaire n'est requis.

Redémarrez le serveur avec sudo systemctl restart VpnHoodServer, ou avec sudo docker restart VpnHoodServer sous Docker. En cas de mot de passe incorrect, il ne démarrera pas et le journal indiquera The server could not start..

Les clés créées avant la modification ne fonctionneront plus car elles sont associées à l'ancien certificat. Générez-les à nouveau et transmettez-les à vos utilisateurs : leurs options et leur utilisation restent inchangées. L'ID d'une clé correspond au nom de son fichier dans /opt/VpnHoodServer/storage/access, sans l'extension .token2.

Lister les clés, puis afficher à nouveau une clé via son ID

sudo ls /opt/VpnHoodServer/storage/access
sudo /opt/VpnHoodServer/vhserver print 2b9d4a6e-1c3f-4e8a-9b7d-5f0e8c2a1d34

Sous Docker, exécutez la même commande via sudo docker exec VpnHoodServer /app/vhsupervisor, comme pour vhserver gen.

Les nouvelles clés intègrent le domaine et ne dépendent plus directement du certificat : elles continuent donc de fonctionner après un renouvellement. Il vous suffit de remplacer le fichier et de redémarrer le serveur.

Étapes suivantes