Architecture ESXI dedibox

Cet article a pour but d’expliquer l’architecture mise en place sur mon serveur dédié dedibox et les problématiques rencontrées.

Objectif

L’objectif est de disposer d’un hyperviseur distant permettant de créer autant de machines virtuelles que voulu pour pouvoir maquetter différents projets en condition réelle. L’idéal serait de disposer d’un réseau local distant, sécurisé et accessible partout.

Contexte:

  • Le serveur dédié est un dedibox hébergé chez Online.net
  • L’hyperviseur installé est ESXI 5.5

Problématique IP publique

Pour réaliser une telle architecture, il se pose un problème d’IP publique. En effet, nous ne disposons que d’une adresse IP publique déjà affectée à notre hyperviseur. En théorie il faudrait acheter une IP publique par machine virtuelle créée.

Dans ces conditions, le prix peut très vite « grimper » selon le nombre de VM voulu. Chaque VM serait également accessible directement depuis Internet, ce qui peut poser des problèmes de sécurité. De plus, l’administration de la solution se « complexifie », il faut par exemple gérer un pare-feu par VM.

Heureusement, il existe une parade où seul l’achat d’une deuxième IP publique est nécessaire. Cette IP servira à créer une VM faisant office de routeur entre le réseau local virtuel et le réseau public.

Schéma réseau

ESXIL’ESXI dispose de sa propre IP publique, de deux Vswitch et d’une VM routeur :

  • le premier Vswitch servira à communiquer avec le réseau Online.net par l’intermédiaire de notre seconde IP publique affectée à la VM routeur.
  • le deuxième Vswitch servira à communiquer avec le réseau local par l’intermédiaire d’une adresse IP privée affectée à la VM routeur.
  • la VM routeur disposera d’une patte dans chaque réseau et permettra aux VM derrière le réseau local virtuel de sortir sur Internet.

Remarque : un problème se pose ici, les IP publiques supplémentaires achetées sur Online.net ne disposent pas de passerelle vers Internet. Pour pouvoir sortir sur Internet, il est donc nécessaire de créer une route entre la seconde IP publique et la passerelle de l’IP publique de l’ ESXI, le tout sur la VM routeur.

Autres rôles VM routeur

La VM routeur fera également office de pare-feu afin de protéger et de sécuriser notre réseau : j’utiliserai ici IPtable et Fail2ban.

Un VPN bridgé propulsé par OpenVPN sera également installé. L’intérêt d’un VPN bridgé est de pouvoir atteindre l’ensemble du réseau local distant pour pouvoir travailler dessus en toute simplicité et sécurité.

Conclusion

En finalité, nous avons un réseau local où nous pouvons ajouter autant de VM que voulu avec un accès Internet, le tout sécurisé. Cette architecture laisse présager de nombreuses solutions, libre court à votre imagination…

Bookmarquez le permalien.
  • flipper

    Du coup si on veut acceder a ssh sur une des VM, il faut que chaque VM ecoute SSH sur un port différent pour attaquer la bonne VM. De même pour les autre services non? Puisque il y a un seul point d’entrée.

  • powtos

    Tu as deux choix :

    Soit tu écoutes SSH sur un port différent par VM, que tu NAT depuis la VM routeur.
    Soit tu les attaques en local une fois le VPN installé, c’est ce que je fais.

    En effet c’est le même principe pour les autres protocoles.