Je suis en train de concevoir une configuration de réseau privé virtuel pour un environnement d'hébergement cloud. Compte tenu de nos exigences, je ne vois pas vraiment cela comme différent d'un environnement de serveur dédié. L'idée est que nous voulons permettre aux clients de pouvoir exiger que leurs utilisateurs se connectent à des machines virtuelles spécifiques ou à des serveurs dédiés à l'aide d'un VPN qui pourrait fournir un cryptage auxiliaire (par exemple pour les travaux d'impression soumis aux réseaux clients).
Nous envisageons de prendre en charge hôte à hôte IPSec (ESP et AH), et bien sûr les tunnels SSH, mais aucun de ces deux n'offre vraiment la possibilité d'utiliser des adaptateurs VPN. Nous envisageons par conséquent d'ajouter au moins certains des éléments suivants, mais comme l'espace est limité, nous souhaitons en standardiser un ou deux au maximum (un serait mieux):
- Prise en charge du tunnel IPSec sur l'hôte virtuel ou dédié
- tinc
- PPTP
Étant donné que nos serveurs effectuant des sauvegardes, etc. peuvent se trouver dans différents centres de données, nous préférerions pouvoir réutiliser notre approche VPN ici. Cela semblerait exclure PPTP. Ma pensée actuelle est qu'IPSec sera probablement meilleur parce que nous pouvons utiliser des adaptateurs VPN standard, mais la configuration du routage (en fonction des besoins des clients) sera probablement beaucoup plus difficile, c'est pourquoi nous examinons également tinc.
Lequel de ces deux est préférable? Ma crainte que la gestion du routage soit susceptible d'être un casse-tête sévère avec IPSec est-elle injustifiée? Existe-t-il un moyen simple de contourner cela? Y a-t-il d'autres problèmes concernant le tinc qui me manquent (c'est-à-dire autres que d'avoir besoin d'un client distinct)?
Mise à jour en réponse à la réponse de @ Wintermute :
Oui, cette question est du point de vue du serveur. La raison en est qu'il s'agit de serveurs effectivement déconnectés des réseaux du client. Oui, notre marché cible est le réseau des PME. Oui, nous nous attendons à utiliser des adresses IP publiques pour chaque serveur client, sauf si elles ont besoin de quelque chose de différent (et nous pourrons alors parler).
La solution vers laquelle nous nous penchons est celle où les clients définissent les tunnels IP et les gammes de réseaux accessibles par ces tunnels et où nous les enchaînons avec nos propres outils de gestion (en cours de développement), qui connectent les demandes des clients aux changements de configuration. Le problème est que, comme nous ne sommes pas susceptibles d'exécuter un logiciel de routage sur les serveurs virtuels et les serveurs, la table de routage doit être gérée de manière statique afin que les clients qui font des erreurs de configuration constatent que les VPN ne fonctionnent pas correctement.
Il est également probable que nous utiliserons ESP sur le réseau pour nos propres opérations internes (pour des choses comme les sauvegardes). L'ensemble de la configuration est plutôt complexe et a de nombreuses perspectives différentes, du serveur centré (notre client VPN à l'instance hébergée) au réseau centré (interne), en passant par la base de données (nos outils). Je ne dirais donc pas que la question est représentative de toute notre approche (et des questions sont posées sur un tas de sites SE).
Mais rien de tout cela n'affecte vraiment la question dans son ensemble. C'est peut-être un contexte utile cependant.