VPN dans les environnements d'hébergement cloud / serveurs dédiés, tunnels IPSec vs tinc

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):

1. Prise en charge du tunnel IPSec sur l'hôte virtuel ou dédié
2. tinc
3. 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.

Pas sûr de tinc mais IPSEC est presque obligatoire. Aucune entreprise sérieuse ne ferait confiance à PPTP.

Je ne sais pas comment IPSEC affecte le routage. Un tunnel est un tunnel est un tunnel quel que soit le cryptage. Vous rencontrerez les mêmes problèmes: tunnel divisé ou non, amener les clients à comprendre le concept / oh regardez les conflits IP LAN d'un client particulier avec le pool VPN que vous avez choisi, etc.

On dirait que vous visez le marché des PME (serveurs individuels, connexion directe, etc.), ce qui exclut les solutions plus sophistiquées, mais je vais quand même énumérer deux approches possibles

• une sorte de concentrateur VPN qui permet les profils. Tous les clients se connectent au concentrateur VPN, puis en fonction de leur profil / groupe / quelle que soit la technologie du fournisseur, obtiennent les autorisations pour utiliser le protocole X à IP Y (c'est-à-dire leur propre serveur).

• Routeurs virtuels Cisco ASR1000V - chaque client en obtient un, vous pouvez ensuite exécuter des tunnels IPSEC directs (avec des VTI pour faciliter le routage) ou même rediriger MPLS vers les clients pour que le routeur apparaisse comme une autre branche de leur topologie, puis allouer vos VNIC VLAN, etc. à l'intérieur pour obtenir une belle «branche» virtuelle.

• une version à plus petite échelle de ce qui précède, nous avons utilisé le monowall à cet effet (c'est-à-dire que chaque client obtient un appareil virtuel de couche 3 qui agit comme un routeur / pare-feu, il VPN dans cet appareil et a accès à leurs VLAN uniquement) , cependant, chaque routeur / pare-feu a besoin de sa propre adresse IP publique.

Re: votre approche actuelle, vous vous rendez compte que chaque serveur a besoin d'une adresse IP publique ou que vous avez un système compliqué et compliqué de NAT où le chemin VPN de chaque client se voit allouer un seul port ou similaire.

Je recommanderais d'avoir un réseauteur à temps plein pour examiner toute conception / proposition que vous avez, il semble que vous y parveniez à partir d'un arrière-plan de serveur.

Oui tu as raison. Il semble que vous devrez gérer des adresses IP distinctes, sauf si elles sont agrégées via un concentrateur VPN. TBH le concentrateur est probablement le meilleur pari, vous aurez juste besoin d'une adresse IP supplémentaire pour toutes les connexions VPN, mais son interface extérieure devra résider dans un sous-réseau / VLAN différent des hôtes IP publics. J'irais avec ça sinon vous configurez IPSEC VPN directement sur chaque serveur individuel, quel cauchemar