VpnHood!

Définir les adresses IP de votre serveur

Une clé d'accès indique aux applications à quelle adresse se connecter. Le serveur la détermine en général automatiquement, mais sur une machine dotée de plusieurs adresses IP, vous devez parfois la définir manuellement : l'adresse sur laquelle le serveur écoute et celle qu'il inclut dans les clés.

Comment le serveur détecte son adresse

Par défaut, le serveur écoute sur toutes les adresses de la machine, sur le port TCP 443.

Pour générer les clés, il détermine son adresse grâce à son propre trafic sortant en interrogeant un service web. Pour un serveur géré, VpnHood! MANAGER applique le même principe via Automatic Configuration et configure les points d'accès en conséquence. Cette option est activée sur chaque nouveau serveur.

Cette méthode fonctionne sur la plupart des machines. Une configuration manuelle reste nécessaire dans les cas suivants :

  • La machine envoie son trafic depuis une autre adresse que celle utilisée par les utilisateurs, par exemple avec une adresse IP sortante dédiée. La détection automatique récupérerait alors l'IP sortante.
  • La machine possède plusieurs adresses IP publiques et les clés doivent utiliser une adresse précise.
  • La détection automatique échoue, par exemple si la machine ne parvient pas à joindre le service web. Un serveur autonome ne démarrera pas et indiquera PublicEndPoints has not been configured properly. dans ses journaux.

Sur un serveur géré

Dans VpnHood! MANAGER, ouvrez Servers, sélectionnez le serveur et accédez à ses Access Points. Chaque point d'accès correspond à une adresse du serveur, avec ses ports.

Points d'accès d'un serveur dans VpnHood! MANAGER, avec la configuration automatique désactivée
La nouvelle adresse, 203.0.113.10, est intégrée aux clés. L'ancienne, 198.51.100.20, en est exclue, mais le serveur continue de l'écouter pour les applications utilisant une clé antérieure.

Pour les configurer manuellement, désactivez Automatic Configuration : tant qu'elle est active, la liste reste verrouillée. MANAGER demande confirmation avant de redémarrer le serveur avec ses nouveaux paramètres.

Deux paramètres définissent l'usage de chaque adresse :

  • Mode détermine qui reçoit l'adresse. PublicInToken l'ajoute à chaque clé d'accès du parc de serveurs. Public l'exclut des clés, et MANAGER ne la transmet à une application que lorsqu'il la redirige vers ce serveur. Private ne la communique jamais aux applications.
  • Listen détermine si le serveur écoute sur cette adresse. Activez-le sur Yes uniquement si votre hébergeur route cette adresse vers la machine : sous Linux, le serveur ajoute automatiquement au réseau toute adresse d'écoute non configurée sur la machine.

UDP Port et QUIC Port sont facultatifs ; -1 permet de les désactiver.

Sur un cloud où la machine n'a que des adresses privées (AWS, Google Cloud, Azure ou Oracle Cloud), ajoutez l'adresse privée avec Mode sur Private et Listen sur Yes, puis l'IP publique avec PublicInToken et Listen sur No, sur le même port. Automatic Configuration applique cette configuration automatiquement.

Pour vérifier, ouvrez le parc de serveurs : sa page liste toutes les adresses intégrées aux clés dans Access Points.

Sur un serveur autonome

Le serveur lit sa configuration dans /opt/VpnHoodServer/storage/appsettings.json. Ce fichier n'existant pas après une nouvelle installation, créez-le pour remplacer la configuration par défaut. Deux paramètres sous FileAccessManager permettent de définir les adresses :

  • TcpEndPoints liste les adresses et ports sur lesquels le serveur écoute.
  • PublicEndPoints liste les adresses et ports intégrés aux clés d'accès. Renseignez uniquement des adresses réelles : indiquer 0.0.0.0 ou [::] empêchera le serveur de démarrer.

Fichier complet : le serveur écoute sur toutes les adresses et intègre 203.0.113.10 dans les clés 

{
  "FileAccessManager": {
    "TcpEndPoints": [ "0.0.0.0:443", "[::]:443" ],
    "PublicEndPoints": [ "203.0.113.10:443" ],
    "SslCertificatesPassword": null
  },
  "ServerConfig": {
    "LogAnonymizer": true,
    "AddListenerIpsToNetwork": "*"
  },
  "LogLevel": "Information"
}

Pour écouter sur une seule adresse, comme avec une IP sortante dédiée, indiquez également cette adresse dans TcpEndPoints. Hors environnement Docker, le serveur configure automatiquement sur la machine toute adresse d'écoute manquante.

Si vous utilisez aussi UdpEndPoints ou QuicEndPoints, attribuez-leur la même adresse que pour le protocole TCP.

Dans un cloud où la machine ne dispose que d'adresses privées (AWS, Google Cloud, Azure ou Oracle Cloud), écoutez sur l'adresse privée ou sur toutes les adresses, puis renseignez l'adresse IP publique dans PublicEndPoints.

Redémarrez ensuite le serveur avec sudo systemctl restart VpnHoodServer, ou avec sudo docker restart VpnHoodServer sous Docker. Pour vérifier la configuration, générez une clé avec vhserver gen : la ligne HostEndPoints: affiche les adresses associées.

Clés déjà distribuées

Une clé intègre les adresses définies lors de sa création ; une application dotée d'une ancienne clé continuera donc de solliciter l'ancienne adresse. Comme chaque application récupère automatiquement la clé à jour lors de sa connexion, laissez le serveur écouter sur l'ancienne adresse pendant quelques jours avant de la supprimer.

Sur un serveur géré, conservez-la comme point d'accès avec Mode sur Private et Listen sur Yes : les applications recevront la nouvelle clé grâce à Push token to clients actif par défaut. Sur un serveur autonome, conservez l'ancienne adresse uniquement dans TcpEndPoints.

Si une application ne parvient plus à joindre l'ancienne adresse, vous devrez lui fournir une nouvelle clé. Avec un nom de domaine et un certificat délivré par une autorité de certification, les clés localisent la nouvelle adresse via le DNS, évitant ainsi toute interruption.

Étapes suivantes

Télécharger Passer au Premium Se connecter