Archives de catégorie : Security

HTTPS ET SSL/TLS

Transport Layer Security (TLS), anciennement nommé Secure Sockets Layer (SSL), est un protocole de sécurisation des échanges sur Internet, développé à l’origine par Netscape (SSL version 2 et SSL version 3). Il a été renommé en Transport Layer Security (TLS) par l’IETF suite au rachat du brevet de Netscape par l’IETF en 2001.

  • FTPS est une extension de FTP (File Transfer Protocol) utilisant SSL.
  • HTTPS Finder est une extension (à l’état expérimental) pour Firefox qui permet de détecter automatiquement les connections HTTPS. Elle permet de travailler en collaboration avec l’extension HTTPS Everywhere.
  • Naviguer en HTTPS ne suffit pas. Si votre VPN n’est pas accepté par un site internet (car votre adresse IP est refusé, ce qui peut arriver si d’autres utilisateurs du VPN ont étés repérés comme étant spammeurs par exemple), même en HTTPS cela ne changera rien (car votre connection est crypté d’abord par le VPN ou SSH, puis est en clair entre le VPN ou SSH et le site web consulté, ou en crypté si vous avez HTTPS, mais c’est l’adresse du VPN ou SSH qui apparait et non votre adresse IP initiale bien sur).IPFuck/IPFlood peut vous permettre de changer d’adresse IP chaque seconde automatiquement (dans votre navigateur internet uniquement).
  • Nginx – Rediriger les requêtes en HTTP vers HTTPS: Si vous utilisez Nginx en reverse proxy et que vous cherchez la méthode pour rediriger de manière permanente (en 301) tout le trafic arrivant sur le HTTP vers du HTTPS pour apporter confort, sécurité et volupté à vos visiteurs, voici comment faire…

Divers

  • SPDY (prononcé « Speedy » pour rapide en anglais) est un protocole réseau expérimental — fonctionnant sur la couche application — créé pour transporter du contenu Web. SPDY est une proposition, conçue par Google, visant à augmenter les capacités du protocole HTTP sans toutefois remplacer ce dernier avec un chiffrement intégré.
  • HTTPCS est un scanner de vulnérabilité web offensive, capable de détecter tout types de vulnérabilité dans une application web, analyser les risques et proposer les contre-mesures. HTTPCS est une solution hébergée (SaaS) qui scanne de l’extérieur comme les personnes malveillantes (Hackers).
  • Voyez ce qu’est le GpgAuth qui est un système libre d’authentification forte (plus forte que SSL).

CONFIGURATION DU SERVICE OPENVPN

SSH signifie « Secure Shell ». Pour simplifier, il s’agit en fait d’un terminal sécurisé. Cela permet de remplacer le « telnet » et cela permet de faire plein d’autres choses plutôt marrantes.

Bon, le VPN… comment cela marche ?

VPN est l’acronyme de Virtual Private Network et c’est le fait de « créer » un « réseau privé sur le réseau Internet public ».

Par exemple, j’ai deux pécés à la maison qui sont reliés par un câble croisé, eh bien je peux leur mettre une adresse privée et réaliser des transferts de fichiers tranquille sous Windows. Il suffit de partager des répertoires puis de les déclarer d’une machine sur l’autre. Ces transferts se font en toute sécurité puisque l’on utilise le LAN. Le protocole utilisé est SMB, il s’agit d’un protocole utilisant les ports 137 à 139 et c’est du microsoft.

Bon, mettons que maintenant je suis sur un ordinateur portable, en déplacement, ou bien que je souhaite partager des fichiers avec mon frère qui se trouve à l’autre bout de la France, comment faire ?

Dans ce cas-là, on peut utiliser tout autre type de protocole de transfert de fichiers comme par exemple FTP pour garder la possibilité de restreindre l’accès aux fichiers. Toutefois, il serait plus « pratique » de mettre à disposition les partages Windows (répertoires et imprimantes pourquoi pas ?). Comment faire ?

Eh bien le moyen est de raccrocher l’ordinateur distant au LAN pour qu’il croit qu’il se retrouve en LAN, même s’il traverse l’internet !

La solution pour réaliser cela s’appelle le VPN !

En gros, on créé un tunnel entre les deux extrémités de notre futur VPN et l’on assigne une adresse privée à chaque extrémité de ce tunnel.

Schématiquement, cela ressemble à cela :

L’ordinateur distant possède une interface physique qui a pour adresse 193.121.12.134 qui le connecte sur Internet. Ensuite, on construit un tunnel. Pour cela, on créé une interface virtuelle qui aura pour adresse 192.168.0.51. Sur la passerelle, on trouve le même schéma, c’est à dire une interface physique et une ou plusieurs interfaces virtuelles.

Ainsi, l’ordinateur distant se retrouve, virtuellement, sur le même LAN que les pécés à la maison ! si aucune règle n’est ajoutée sur le firewall pour empêcher la diffusion du protocole SMB, alors il est possible d’exporter les répertoires et imprimantes partagées ! A ce niveau de définition de l’architecture VPN, on peut utiliser tout protocole unicast de niveau 3, TCP ou UDP. Par définition, les broadcasts ne passent pas les routeurs ou, dans notre cas, la passerelle qui sert entre autres, de routeur.

Ce dernier point est embêtant dans le cas où nous souhaitons jouer en réseau. En effet, la plupart des réseaux disposant d’une option de jeu en LAN diffuse des requêtes clients/serveur en broadcast ! Si notre passerelle, par défaut, ne permet pas de diffuser le broadcast, alors les jeux ne fonctionneront pas à travers le VPN.

Bon, mais ce qui nous intéresse, c’est de pouvoir jouer… alors comment faire ? eh bien la solution c’est de transformer notre routeur en pont ! (lire les articles à la pagehttp://www.commentcamarche.net/lan/connect.php3sur les ponts et routeurs, mais les explications sont un peu limitées…).

Bon, aller je réexplique différemment les ponts et routeurs. En fait, les deux équipements agissent à un niveau différent de la couche OSI. Pour rappel, la couche 1 est la couche physique, ce sont les câbles et interfaces électriques. Ensuite, nous trouvons la couche de liaison des données, couche 2, c’est ce protocole qui est utilisé dans les LAN, il s’agit en général du protocole ethernet. Ensuite, nous trouvons la couche 3 qui est une couche réseau, c’est la couche IP. En général, on associe le TCP et UDP à la couche 3.

Donc en simplifiant, nous avons :

( NIV 1 : PHYSIQUE )
( NIV 2 : ETHERNET ) ( NIV 2 : TOKEN RING ) .....
( NIV 3 : TCP / IP )

Un routeur agit au niveau 3, un pont au niveau 2. Un pont est, en général, utilisé pour transformer un protocole de niveau 2 en un autre protocole de niveau 2. Par exemple, certaines entreprises utilisent encore le protocole de niveau 2 propriétaire IBM « Token Ring ». Pour pouvoir raccrocher ces LAN aux LAN ethernet, on utilise le pont pour diffuser les informations d’un LAN ethernet vers un LAN token ring et inversement.

Bon bref, revenons en à notre VPN. En fait, pour diffuser les broadcasts, il suffit de définir un pont virtuel sur la passerelle et d’y inclure l’ensemble de nos interfaces, virtuelles et physiques, puis de définir un domaine de broadcast commun.

On obtient quelque chose comme (bon, cela semble compliqué mais c’est pas si compliqué…)

L’interface virtuelle est nommée « TAP ». On vient bien, par le schéma, les extrémités des tunnels et le fait qu’une principale interface virtuelle regroupe l’ensemble des interfaces.

 

Installation d’OpenVPN

Venons en maintenant à l’installation…

Tout d’abord, je propose d’utiliser une solution VPN très « light », il s’agit d’OpenVPN. Par rapport au schéma ci-dessus, je propose l’installation de la version 2.0 d’OpenVPN qui simplifie pas mal…. En fait, avec les versions inférieures, il fallait créer un serveur par client et ouvrir plusieurs ports d’écoute. Cette version permet la connexion de plusieurs clients sur le même serveur. Par contre la configuration est un peu plus compliquée… :-/

Donc les étapes sont simples : téléchargement des sources, décompression, compilation et installation.

A noter que pour utiliser une compression des données à la volée, vous pouvez aussi télécharger les librairies « LZO » disponibles sur le site www.oberhumer.com. Il faut télécharger, compiler et installer ces sources avant la configuration d’OpenVPN.

Vérification que la couche SSL est bien installée, si les librairies suivantes ne sont pas installées, eh bien… installez-les ! :)
# rpm -qa | grep ssl
openssl-0.9.7b-4mdk
libopenssl0.9.7-devel-0.9.7b-4mdk
libopenssl0.9.7-0.9.7b-4mdk
#Récupération du tarball
[/compil]# wget http://openvpn.net/release/openvpn-2.0.2.tar.gz

Décompression du tarball
[/compil]# tar xzvf openvpn-2.0.2.tar.gz
[/compil]# cd openvpn-2.0.2
[/compil/openvpn-2.0.2]# ./configure
[/compil/openvpn-2.0.2]# make
[/compil/openvpn-2.0.2]# make install

OpenVPN est installé dans le répertoire « /usr/local/sbin ». Personnellement, j’ai créé un lien symbolique vers « /sbin », comme cela le programme est dans mon « path ».
[/compil]# ln -s /usr/local/sbin/openvpn /sbin/openvpn
[/compil]# openvpn –version
OpenVPN 2.0.2 i686-pc-linux-gnu [SSL] [LZO] built on May 23 2004
Copyright (C) 2002-2004 James Yonan <jim@yonan.net>
[/compil]#

 

Configuration d’OpenVPN

Ca se complique car, eh bien, il faut installer tout un système de certificats alors qu’avec les versions précédentes, on pouvait utiliser une clé partagée. La gestion de cette couche est proposée par OpenSSL. Configurons donc OpenSSL !

Tout d’abord, retrouvé le fichier de configuration d’OpenSSL

[/root]# openssl ca
Using configuration from /usr/lib/ssl/openssl.cnf
<—— coupé —–>
[/root]#

Ok, donc éditons le fichier de configuration… J’ai quasiment tout laissé d’origine, excepté le répertoire où je vais stocker les certificats :

HOME = /usr/local/etc/ssl

[ CA_default ]dir = /usr/local/etc/ssl # Where everything is kept
….
private_key = $dir/private/cakey.pem
….

Il faut aussi créer un périphérique TUN sous Linux :

[/root]# mkdir /dev/net
[/root]# mknod /dev/net/tun c 10 200

Rajouter la ligne suivantedans le fichier /etc/modules.conf :

alias eth1 ne2k-pci
alias eth0 8139too
probeall usb-interface usb-ohci
alias sound-slot-0 es1371# Ligne à ajoutée pour la configuration du nouveau device au démarrage
alias char-major-10-200 tun

et enfin

On ajoute dynamiquement le module gérant les tunnels

[/root]# modprobe tun

Et on active le forwarding (voir la config du parefeu pour bien comprendre)

[/root]# echo 1 > /proc/sys/net/ipv4/ip_forward

Génération du certificat authentifiant (ou root CA)

On créé tout d’abord le répertoire où seront stockés les certifcats

[/root]# cd /usr/local/etc
[/usr/local/etc]# mkdir ssl
[/usr/local/etc]# cd ssl
[/usr/local/etc/ssl]# mkdir certs; mkdir private
[/usr/local/etc/ssl]# chmod 700 private
[/usr/local/etc/ssl]# echo ’01’ > serial
[/usr/local/etc/ssl]# touch index.txt

On génère maintenant le certifcat root avec un temps de validité très long

[/usr/local/etc/ssl]# openssl req -x509 -newkey rsa -out cacert.pem -outform PEM -days 10000
Generating a 1024 bit RSA private key
.++++++
…………….++++++
writing new private key to ‘privkey.pem’
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase: <
—–

—–
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:Root Certif
Email Address []:[/usr/local/etc/ssl]# ls
cacert.pem privkey.pem
[/usr/local/etc/ssl]# mv privkey.pem cakey.pem

Et l’on créé un fichier Dieffe-Helmann

[/usr/local/etc/ssl]# openssl dhparam -out dh1024.pem 1024

Maintenant, grâce à ce certifcat, notre machine pourra « signer » une requête de certificat d’une tierce personne.

Comment ça marche ? En fait, une personne va vouloir se connecter à notre VPN. Pour cela, il faut qu’elle s’authentifie avec un certificat. Ce certificat est envoyé à OpenVPN qui va contrôler sa validité, c’est à dire si ce certificat a été signé par notre certificat « root ».

Pour avoir un certificat valide, il faut que l’utilisateur envoie une requête de certificat qui contient des informations personnelles ainsi qu’une clé personnelle. OpenSSL, par l’utilisation du certificat « root », va transformer cette requête de certificat en certificat, en ajoutant sa propre clé, des informations supplémentaires, etc. Ce certificat peut être renvoyé à la personne avec la clé publique de notre serveur certifiant (cacert.pem).

La clé « cacert.pem » doit être envoyée à toutes les personnes souhaitant s’authentifier auprès de notre serveur SSL.

Génération des certificats individuels

Ok donc…. nous avons un système qui permet la création de certificats… La marche à suivre est simple. Normalement, la requête doit être exécutée par la personne souhaitant le certificat… mais bon….

Pour cela, vous pouvez utiliser le petit script « create_certs.sh » qui permet de simplifier la création des certificats. Copiez ce script dans le répertoire « /etc/openvpn »

mais avant d’utiliser ce script, copiez le cacert.pem dans le répertoire « /etc/openvpn »

[/usr/local/etc/ssl]# mkdir /etc/openvpn
[/usr/local/etc/ssl]# mv openvpn* /etc/openvpn
[/usr/local/etc/ssl]# cp cacert.pem /etc/openvpn
[/usr/local/etc/ssl]# cd /etc/openvpn
[/etc/openvpn/]# cp /usr/local/etc/ssl/cacert.pem .

Création d’un certificat pour le serveur OpenVPN

Avant de créer les certificats pour ses amis, il faut créer un premier certificat pour le serveur OpenVPN.

On génère le certificat pour le serveur OpenVPN

[/etc/openvpn/]# ./create_certs.sh openvpn
Generating a 1024 bit RSA private key …………………….++++++ .++++++
writing new private key to ‘openvpnkey.pem’
…..
Country Name (2 letter code) [GB]:FR
State or Province Name (full name) []:
Locality Name (eg, city) []:Chicago
Organization Name (eg, company) [My Company Ltd]:
…ETC…
un nouveau répertoire vient d’être créé « /etc/openvpn/openvpn », vous pouvez déplacer les certificats
[/etc/openvpn/]# mv openvpn/* . ; rm -rf openvpn
[/URL]

Création d’un certificat pour un ami

Maintenant, on génère un certifcat pour un ami,
[TEXTBOX]
[/etc/openvpn/]# ./create_certs.sh test
Generating a 1024 bit RSA private key …………………….++++++ .++++++
writing new private key to ‘openvpnkey.pem’
…..
Country Name (2 letter code) [GB]:FR
State or Province Name (full name) []:
Locality Name (eg, city) []:Chicago
Organization Name (eg, company) [My Company Ltd]:
…ETC…

Maintenant, on a le certificat définitif « testcert.cert », il suffit d’envoyer la clé publique de notre serveur « cacert.pem », la clé privée de la personne « testkey.pem » et le certificat qui lie le tout « testcert.cert ».

Bon, pour être tout à fait « secure » (comme on dit en ce moment), il faudrait que la clé privée soit générée directement par la personne, en bref je n’aurais pas du moi-même générer les clés des personnes qui viendront se connecter… Bref, aller pas grave !

 

Configuration du serveur OpenVPN

Et maintenant crééons le fichier de configuration « server.conf » :

# FICHIER DE CONFIG : /etc/openvpn/server.conf
# version 1.1 : usage of new option « server-bridge » and inactivity control
## On définit le port d’écoute sur le port 5000
port 5000
# On définit le type d’interface virtuelle, on veut une interface ethernet virtuelle
dev tap0

ca /etc/openvpn/cacert.pem
cert /etc/openvpn/openvpncert.cert
key /etc/openvpn/openvpnkey.pem
dh /usr/local/etc/ssl/dh1024.pem # je n’utilise pas d’encryptage, sinon je décommente la ligne suivante
#tls-cipher RC4-MD5
# la commande server-bridge remplace le bloc de commande suivant :
# mode server
# tls-server
# ifconfig-pool 192.168.0.32 192.168.0.64 255.255.255.0
# push « route-gateway 192.168.0.1 »

server-bridge 192.168.0.1 255.255.255.0 192.168.0.32 192.168.0.64

# comme on veut créer un pont entre les différentes interfaces, on utilise des tunnels persistents.
# Franchement, je ne sais pas si c’est utile avec la version 2.0 mais avec la 1.5, il le fallait…. donc…
persist-tun
persist-key
inactive 3600
ping 10
ping-exit 60

user nobody
group nobody

verb 4

 

Démarrage du serveur

Maintenant, on créé notre interface virtuelle et puis on lance le serveur… J’ai créé un script pour tout cela… Il est simple et ne fait aucune vérification….

A noter, pour diffuser les broadcasts, lancés par certains jeux en mode réseau, il faut créer une interface virtuelle particulière que l’on appelle pont ou bridge.

Pour commencer, il faut installer les outils de « bridging », dans la mandrake 9.2b le paquetage a installé est le suivant :

bridge-utils-0.9.6-2mdk.i586.rpm

[/root]# urpmi bridge-utils

Ensuite, il suffit de copier le script ci-dessous dans le répertoire « /etc/openvpn ».

#! /bin/sh
#
# Created by Raum
# changes:
# 04/11/22 : daemon option used instead of daemon in config file
#OPENVPN= »/sbin/openvpn »

# On commence par creer un tunnel persistant en mode TAP
$OPENVPN –mktun –dev tap0

# on cree un nouvelle interface de type « bridge »
brctl addbr br0

# et on ajoute l’interface INTERNE du reseau local et l’interface
# virtuelle TAP dans le bridge
brctl addif br0 tap0
brctl addif br0 eth0

# on configure les interfaces en mode promiscuite (elles écoutent tout
# meme ce qui les concerne pas)
ifconfig eth0 0.0.0.0 promisc up
ifconfig tap0 0.0.0.0 promisc up

# enfin on configure notre interface virtuelle « bridge »
ifconfig br0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255

# et on finit par demarrer OpenVPN.
$OPENVPN –daemon –config /etc/openvpn/server.conf –log-append /var/log/openvpn.log

Maintenant, il suffit de lancer le script (n’oubliez pas de lui donner les droits d’exécution 😉 chmod 700).

Ce script va créer une interface de type « pont » qui prendra l’adresse de notre interface eth0, adresse 192.168.0.1

Pour information, voici le résultat de la commande « ifconfig » après lancement du serveur :

# ifconfig
br0 Lien encap:Ethernet HWaddr 00:E0:7D:E2:
inet adr:192.168.0.1 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::2e0:7dff:fee2:4ba6/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
(…)
eth1 Lien encap:Ethernet HWaddr 00:E0:7D:72:
inet adr:82.67.XX.XX Bcast:82.67.XX.255 Masque:255.255.255.0
adr inet6: fe80::2e0:7dff:fe72:f33b/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
(…)
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
(…)
sit0 Lien encap:IPv6-dans-IPv4
adr inet6: ::82.67.XX.XX/96 Scope:Compat
adr inet6: ::127.0.0.1/96 Scope:Inconnu
UP RUNNING NOARP MTU:1480 Metric:1
(…)
tap0 Lien encap:Ethernet HWaddr A2:7C:27:B2:
adr inet6: fe80::a07c:27ff:feb2:6135/64 Scope:Lien
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

 

Connexion depuis un client Windows

Commencez par télécharger le fichier installant OpenVPN 2.0 toujours sur le site d’OpenVPN.

Une fois OpenVPN installé, une nouvelle interface virtuelle a été créé dans « vos favoris réseau ». Il suffit d’en ouvrir la propriété pour voir quelque chose comme « TAP-Win32 Driver ».

Créez un répertoire « C:\VPN » et copiez les fichiers « testcert.cert », « cacert.pem » et « testkey.pem » puis créez un fichier de configuration :

# FICHIER DE CONFIG : C:\VPN\client.conf# chez qui doit on se connecter et sur quel port ?
port 5000
dev tap
remote 82.46.73.52

# TLS parms
tls-client
ca c://VPN//cacert.pem
cert c://VPN//testcert.cert
key c://VPN//testkey.pem

# This parm is required for connecting
# to a multi-client server. It tells
# the client to accept options which
# the server pushes to us.
pull
ping 20

Puis, à partir d’une invite de commande, il suffit de taper :

C:\VPN> openvpn –config client.conf

Et dans une autre invite de commande :

On teste la joignabilité du pont
C:\> ping 192.168.0.1
Envoi d’une requête ‘ping’ sur 192.168.100.1 avec 32 octets de données :
Réponse de 192.168.0.1 : octets=32 temps<10 ms TTL=128On teste la joignabilité d’une machine sur le LAN
C:\> ping 192.168.0.2
Envoi d’une requête ‘ping’ sur 192.168.100.2 avec 32 octets de données :
Réponse de 192.168.0.2 : octets=32 temps<10 ms TTL=128

 

Lancement du serveur au démarrage

Vous pouvez aussi utiliser le script « openvpnd » suivant, à copier dans le répertoire « /etc/init.d ».

#!/bin/bash
#
#
# chkconfig: 345 40 60
# description: Start and stop OpenVPN service
#
# Created by Raum v0.1 (last change 22/11/04)
# 22/11/04 : chkconfig compatibility
## Source function library.
. /etc/init.d/functions

test -x /sbin/openvpn || exit 0

RETVAL=0

prog= »/sbin/openvpn »

start() {
# Check if atd is already running
if [ ! -f /var/lock/subsys/openvpn ]; then
gprintf « Starting %s:  » « $prog »
daemon /etc/openvpn/start.sh
RETVAL=$?
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/openvpn
echo
fi
return $RETVAL
}

stop() {
gprintf « Stopping %s:  » « $prog »
killproc /sbin/openvpn
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/openvpn
echo
return $RETVAL
}

restart() {
stop
start
}

reload() {
restart
}

status_at() {
status /sbin/openvpn
}

case « $1 » in
start)
start
;;
stop)
stop
;;
reload|restart)
restart
;;
condrestart)
if [ -f /var/lock/subsys/openvpn ]; then
restart
fi
;;
status)
status_at
;;
*)
gprintf « Usage: %s {start|stop|restart|condrestart|status}\n » « $0 »
exit 1
esac

exit $?
exit $RETVAL

Le lancement est simple :

[/root]# chkconfig –add openvpnd
[/root]# /etc/init.d/openvpnd start

Et là, la vie est belle… On peut tout faire ! jouer à un jeu en réseau en utilisant l’option LAN, on peut partager des répertoires, on peut utiliser le proxy, etc.

Attention: pour la configuration de l’adresse du proxy, vous pouvez utiliser l’adresse 192.168.0.254

 

Et lancer le serveur avec xinetd ?

Le problème est simple. Avec la méthode si dessus, nous avons une instance d’OpenVPN toujours en fonctionnement. Le nouveau mode « server » apporté par la version 2.0 ne permet pas le fonction avec xinetd. Pour utiliser xinetd, il faut créer un tunnel par client et chaque tunnel est instancié par xinetd pour chaque client… bref, une usine à gaz…. Voici toutefois la marche à suivre… en gros. 1/ Ajout du service dans le fichier xinetd.conf

#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}

service vpn
{
type = UNLISTED
port = 5000
socket_type = dgram
protocol = udp
user = root
wait = yes
server = /sbin/openvpn
server_args = –inetd wait –config /etc/openvpn/server.conf –log-append /var/log/openvpn.log –inactive 600 –user nobody
}

includedir /etc/xinetd.d

Ensuite, pour voir en temps réel, les lancements des services :

une première fenêtre avec :

# tail -f /var/log/messages | grep xinet

une deuxième fenêtre avec:

# tail -f /var/log/messages | grep xinet

Si vous avez installé OpenVPN en tant que service, arrêtez le et supprimez le du démarrage automatique :

# /etc/init.d/openvpnd stop
# chkconfig –del openvpnd

On relance le démon xinetd :

# /etc/init.d/xinetd restart
Arrêt de xinetd : [ OK ]
Lancement de xinetd : [ OK ]
#

On peut observer dans la première fenêtre de logs :

Nov 24 12:59:27 stargate xinetd[3408]: Exiting...
nov 24 12:59:27 stargate xinetd: Arrêt de xinetd succeeded
Nov 24 12:59:28 stargate xinetd[3432]: xinetd Version 2.3.11 started with libwrap options compiled in.
Nov 24 12:59:28 stargate xinetd[3432]: Started working: 1 available services
Nov 24 12:59:30 stargate xinetd: xinetd startup succeeded

Et un petit contrôle supplémentaire pour vérifier que le port 5000 est bien ouvert en écoute pour le protocole UDP :

# netstat -pan | grep xinetd
udp 0 0 0.0.0.0:5000 0.0.0.0:* 3432/xinetd

Bon, normalement tout devrait être bon, reste plus qu’à lancer le client pour le test final…. et cela donne la chose suivante :

Wed Nov 24 13:50:20 2004 OpenVPN 2.0.2 i686-pc-linux-gnu [SSL] [LZO] built on May 23 2004
Wed Nov 24 13:50:20 2004 Diffie-Hellman initialized with 1024 bit key
Wed Nov 24 13:50:20 2004 TUN/TAP device tap0 opened
Wed Nov 24 13:50:20 2004 /sbin/ifconfig tap0 192.168.100.253 netmask 255.255.255.0 mtu 1500 broadcast 192.168.100.255
....
Wed Nov 24 13:50:22 2004 81.254.0.230:5000 [Raum] Peer Connection Initiated with 82.251.0.230:5000
Wed Nov 24 13:50:24 2004 Raum/82.251.0.230:5000 PUSH: Received control message: 'PUSH_REQUEST'
Wed Nov 24 13:50:24 2004 Raum/82.251.0.230:5000 SENT CONTROL [Raum]: 'PUSH_REPLY,ifconfig 192.168.100.32 255.255.255.0' (status=1)

pour que cela fonctionne dans tous les cas, il faut modifier le fichier de configuration pour ne pas démarrer en mode « server » et créer un fichier de conf pour chaque utilisateur…

INTEROPÉRABILITÉ ET HYPER-CONVERGENCE : LES PIÈGES DE L’INCOMPATIBILITÉ

Les solutions hyper-convergées sont par essence l’œuvre d’un fournisseur unique, qui a conçu un ‘tout-en-un’ entièrement intégré et automatisé. D’où les questions légitimes sur l’interopérabilité, sinon la compatibilité entre les diverses solutions du marché.

L’une des principales motivations des DSI lorsqu’ils ont à choisir une nouvelle solution IT, est qu’elle permette de sortir d’un environnement « propriétaire », surtout si la solution a vocation à évoluer en capacité.

C’est l’assurance de réduire sinon de ne pas augmenter le cout total d’exploitation, de ne pas devoir repayer non seulement des matériels mais de nouvelles licences à des prix très élevés, etc..

Or, les solutions hyper-convergées peuvent, à juste titre, soulever quelques inquiétudes, car, par définition, ce sont des offres fermées ou, du moins, tellement intégrées qu’il est difficile de déterminer, a priori, le niveau d’interopérabilité avec d’autres solutions d’autres constructeurs, ou avec celles déjà installées.

Deux cas de figure

Deux scénarios se présentent :

  • Soit on s’en remet à un standard de facto : un acteur leader (comme HP, VMware, Cisco, EMC, IBM…), est déjà très présent dans l’environnement existant auquel cas il faudra vérifier qu’il y a bien compatibilité.
  • Soit on envisage un système « ouvert », ou réputé tel, et donc conforme aux développements Open source. Dès lors, se pose la question de l’interopérabilité avec les autres systèmes ouverts.

Sur le terrain, ces deux cas de figure peuvent se mêler : un système dit « propriétaire » peut, en partie, s’appuyer sur une pile logicielle Open source (comme OpenStack, par exemple).

L’argument de la compatibilité

Les solutions hyper-convergentes ne sont pas nécessairement compatibles entre elles. Or, comme elles incluent des mécanismes d’automatisation à partir d’une console centralisée, il faut qu’il existe une compatibilité effective si l’on doit y connecter des éléments externes. L’ensemble doit fonctionner correctement. Ce qui renvoie à  « la matrice de compatibilité ». Sur le papier, le matériel est dit « full compatible » et « maitrisé ». Mais ce sont des tests, ou les premiers clients, qui le vérifient.

Le paradoxe est que l’hyper-convergence est censée réduire la complexité de la mise œuvre. En pratique, mieux vaut vérifier et comparer, par exemple, avec le niveau d’intégration de solutions convergées matures, déjà éprouvées, telles que Vblock (VCE, VMware, Cisco, EMC) ou FlexPod Cisco,NetApp, VMware), dont la matrice de compatibilité a été affinée avec le temps. Mais ce sont des configurations non pas « hyper » mais convergentes.

Les start-ups de l’hyper-convergence – comme Atlantis Nutanix, Pivot, Simplivity ou ScaleComputing – ont plutôt bonne réputation sur ce plan de la compatibilité. Mais les tests restent de rigueur.

Compatibilité avec les standards de fait

Parmi les standards du marché, VMware ne figure pas en dernière place. Sa récente proposition EVO:RAIL, sorte d’appliance en OEM, est ancrée sur vSphere et reliée à vCenter pour l’administration, et donc la compatibilité est requise – notamment pour s’assurer des mise à jours et des ‘patch’. Est-on très éloigné d’un système « propriétaire»?

L’un des points à vérifier, par exemple, est si les hyperviseurs embarqués viennent bien s’ajouter correctement à l’inventaire vCenter comme n’importe quel autre sous-ensemble virtualisé ESXi déjà installé.

La compatibilité avec Virtual SAN, s’il y a cohabitation, serait également un point à vérifier. De même, le support de HorizonView 6 (VMware) ou des cartes graphiques NVidia ou des cartes accélératrices du type PCoIP APEX.

Au passage, HP, comparant à EVO:RAIL son offre ConvergedSystem200 HC sur son propre logiciel StoreVirtual (VSA), invoque une interopérabilité plus large.

Les cas Cisco, IBM

La compatibilité avec les leaders du marché se vérifie encore s’agissant de Cisco ou IBM. Le champion des solutions réseau, Cisco, délivre des certifications de compatibilité sur ses racks UCS (Unified computing system), la C-Series, dans le cadre de son programme Solution Partner.

De même, avec IBM, c’est la compatibilité avec son environnement, de systèmes de fichier GPFS (General parallel file system), qui prime, depuis son introduction en 1998 (impact sur les réseaux SAN).

Ces deux géants viennent d’ailleurs de se rapprocher autour d’une offre Cisco proposant d’intégrer les Storwize V7000 d’IBM à son portefeuille.

L’interopérabilité en pratique

L’interopérabilité, à la différence de la compatibilité, c’est en principe l’assurance de ne pas être verrouillé (locked down) par un éditeur ou un constructeur.
Dans l’hyper-convergence, cela se traduit par la liberté d’ajouter des équipements et des nœuds individuels à des clusters existants en puisant dans les meilleures offres du moment, puisqu’il est possible de les partager au niveau local ou distant.

Clairement, la référence Open source actuelle est OpenStack. Cette pile logicielle apporte la capacité de contrôler de vastes pools de ressources – serveurs, stockage et  réseau, au sein d’un même datacenter – et de les gérer depuis un tableau de bord unique. Il permet de créer les conditions d’un environnement SDDC (Software defined data center), donnant priorité au pilotage par la pile logicielle. L’interopérabilité ne paraît pas soulever de problèmes, comme par exemple autour du client Cinder, qui est l’interface de commande pour les interfaces API Block storage d’OpenStack.

Ce point est confirmé par un responsable de Nexenta (cf. entretien Frédéric Millon), une ex-startup fondée par des développeurs Open Source, qui avaient dès le départ, choisi de se focaliser précisément sur la connectivité et l’interopérabilité entre systèmes.

Stockage hyper-convergé : 3 familles en lice

Trois familles d’acteurs cohabitent dans l’univers de la convergence des solutions de stockage :

  • L’approche Data systems : CEPH, Gluster, Openstack, Microsoft, AWS…
  • Les solutions logicielles : VMware VSAN (virtualstorage SAN), Sanbolic, Nexenta, EMC ScaleiO, Datacore…
  • Les appliances : HP, Atlantis, Nutanix, SimpliVity (avec Dell, Cisco), ScaleComputing, Pivot…

Enfin, il y a aussi des acteurs atypiques, comme Wikibon ou Pluribus (Freedom Server-Switch et un hyperviseur, Networks Netvisor).

Frédéric Milon, Nexenta France : « L’hyper-convergence? C’est toujours plus de virtualisation ! »

Frédéric MILON, directeur commercial de Nexenta Europe du Sud, constate qu’il est toujours possible d’améliorer les plateformes de virtualisation. « C’est l’orientation vers l’hyper-convergence. Mais sans que l’on soit nécessairement intrusif ».

Comment qualifiez-vous l’hyper-convergence ?

L’hyper convergence consiste en une architecture basée sur les logiciels permettant une intégration de l’ensemble des besoins informatiques d’une entreprise. C’est le fait d’aller plus loin encore dans la virtualisation. Car les plateformes de virtualisation peuvent toujours être optimisées. Ainsi, nos solutions, comme NexentaConnect, apportent des fonctionnalités qui permettent d’améliorer l’efficacité des plateformes VMware -dont VSAN (qui fonctionne en mode ‘bloc’) ou Horizon, ainsi qu’un logiciel de stockage, NexentaStor, qui gère l’ensemble des besoins en ce domaine de nos clients, quelle que soit sa stratégie de gestion des données.

De quelles améliorations s’agit-il ?

Une solution comme NexentaConnect pour VDI, par exemple, permet d’augmenter le nombre de VM par serveur. L’amélioration peut aller jusqu’à 50%.
L’explication est que notre code intervient en amont de la gestion de la mémoire utilisée par VMware. (Et nous ne sommes pas limités par le nombre de disques).
Nous apportons également des ressources de caching, non pas au point de mémoire cache des traitements ESX , mais au niveau de la mémoire cache des VM elles-mêmes.

Nous pouvons également rajouter une couche NAS à VMWare VSAN, si utile, grâce, là encore à NexentaConnect. Mais sans être intrusifs.

En ce qui concerne NexentaStor, il est toujours possible de faire évoluer une configuration sans stopper la production ou de rajouter, à chaud, une JBOD d’un constructeur (Dell, Supermicro, HP, etc.), sans temps d’arrêt (arrêt de production). Et nous restons toujours neutres vis-à-vis des marques.

Historiquement, le système de fichiers ZFS était basé sur Solaris (Sun), avec une capacité d’adressage colossale sur 128 bits. Aujourd’hui, il est Open Source, il est donc resté un système de fichiers indépendant. Nexenta a travaillé à partir de ce noyau et nos 130 développeurs ont amélioré grandement la solution afin de proposer aujourd’hui ce qui est le produit phare du SDS (Software Defined Storage), NexentaStor. Nous possédons plus de 30 brevets dans ce domaine.

Comment le ‘Software Defined‘ modifie-t-il la donne?

Le Software defined permet de s’affranchir du lien entre le logiciel et le matériel, ce qui permet aux clients de réduire significativement leurs coûts de fonctionnement lié au stockage. D’autre part, du fait de  la capacité de NexentaStor à fédérer les environnements hétérogènes (physiques et virtualisés) ainsi que les différentes stratégies de stockage (fichier,  bloc et, demain, objet), nous permettons aux DSI d’envisager sereinement l’avenir, tout en contrôlant leurs investissements.

Il apporte également des avancées techniques significatives : avec leSoftware defined, les contrôleurs RAID, par exemple n’ont plus de raison d’être. Nous gérons tout, de façon logicielle. La corruption de données n’est plus possible. Chaque disque est ‘tagué’, en sorte que si l’on déplace un tiroir de disques, l’OS va automatiquement le détecter. Et on peut donc augmenter la capacité à chaud. C’est très souple.

A noter que le fait de supprimer les cartes RAID facilite énormément la reconstruction d’un disque. S’il contient 2 tera-octets, il sera possible de le reconstruire en 2 à 4 heures (contre 1 à 2 jours sur des environnements classiques). Ce n’est là qu’un exemple des multiples fonctionnalités de notre offre.

Donc comment vous positionnez-vous dans l’hyper-convergence ?

Nous sommes vus comme leader du SDS (Software defined storage). Nous avons un portefeuille de produits, qui s’inscrivent dans cette démarche. La solution NexentaStor appartient au domaine du SDS. Elle est transparente au niveau hardware.

En outre, nous sommes ouverts à tous les types de protocoles du stockage (modes bloc, fichier, objet…) et à tous les environnements applicatifs (bases de données, messaging, etc.)

Notre enjeu, c’est être capable de gérer tous les environnements existants (SAN, NAS, hybride, virtualisé…) ou être capable de rajouter le mode objet (avec NexentaEdge), par exemple.

Et que recouvre l’orientation ‘Software centric’ ?

C’est l’essence même de notre solution. Faire du matériel un produit de « commodité », et permettre au logiciel de délivrer la puissance et les fonctionnalités nécessaires à nos clients.

Dans ZFS, beaucoup de code a été rajouté, pour parvenir à l’hyper-convergence. C’est, par exemple, le fait d’être pré-configuré, prêt à l’emploi très rapidement, ou le fait de déployer très rapidement, le file manager ZFS en mode fichier ou en mode objet. L’intérêt du mode objet étant de permettre de constituer des conteneurs d’informations, par exemple, autour des dossiers patients complets, avec ordonnances ou imagerie médicale, etc. Pour un traitement rapide, on ajoute de la capacité CPU, de la mémoire, de la capacité disque. Mais plutôt que de puiser dans de nouvelles ressources, c’est un contrôleur qui détecte les ressources disponibles, jusque sur le Cloud, le cas échéant.

Quels arguments motivent les clients ?

Beaucoup de DSI souhaitent sortir des solutions propriétaires. Ils veulent retrouver de l’oxygène dans leur budget. Et être sereins quant à l’évolution de leur architecture. Donc, ils sont à la recherche de scénarios alternatifs. Avec notre offre, c’est le stockage qui s’adapte à l’applicatif, et pas le contraire.

L’interopérabilité autour d’OpenStack est-elle un acquis ?

Oui, l’interopérabilité est réelle, vérifiable. Non seulement nous sommes compatibles mais Nexenta  est un acteur important de cette communauté, comme l’a montré notre forte implication lors du dernier sommet OpenStack à Paris en novembre.

LES SOLUTIONS CONVERGÉES : UNE VRAIE ALTERNATIVE AUX SYSTÈMES EN SILOS ?

Pourquoi les solutions convergées – intégrant les couches serveurs, stockage et réseau – sont-elles une alternative crédible aux systèmes conventionnels en silos ? Faut-il miser tout de suite sur l’hyper-convergence ?

La tendance à l’intégration de l’informatique, c’est à dire sa concentration sur un minimum de volume ne date pas d’aujourd’hui. Elle remonte à la miniaturisation des composants et renvoie à la fameuse loi de Moore, ou, plus concrètement, à la progression phénoménale de la capacité des processeurs multi-coeurs, notamment dans les systèmes Intel x86, sur 64 bits.

Mais dès avant 2010, on a vu arriver de nouvelles architectures informatiques concentrant dans des racks, une puissance de calcul très dense ainsi que des unités de stockage, interconnectés par un réseau en ‘backplane‘ (en fond de rack), attachement direct (SAS) ou en réseau local (SAN) très intégrées.

Ces racks ont tiré parti des serveurs lames, extrêmement compacts et puissants (chez HP, Dell, IBM…) et des disques mémoires Flash SSD mais le coût, au départ, était un dissuasif et la fiabilité discutable.

En concurrence, sont alors apparues d’autres formes de serveurs en tiroirs très modulaires (comme l’architecture Moonshot de HP, ou des équivalents chez Dell), facilement démontables et interchangeables, procédé très utile pour la maintenance et les reconfigurations à la demande, mais… à la main.

La vague des hyperviseurs et de la virtualisation

En parallèle, côté plateforme logicielle, l’avènement des hyperviseurs et de la virtualisation va également constituer un tournant important avec ESX de VMware et Hyper-V de Microsoft, une sorte de réinvention du système VM d’IBM pour serveurs X86.

En avril 2009, Cisco prend le pari d’introduire son offre UCS (Unified computing system) en s’appuyant directement sur VMware ESX comme OS système – c’est le scénario ‘baremetal‘ (implémentation directe sur le système). Une option audacieuse, « disruptive », selon la terminologie de la SiliconValley. Conçue en partenariat avec Intel et VMware,  elle aura été une des toutes premières plateformes convergées industrielles, incluant les CPU, le réseau et les unités de stockage dans un rack unique de 19 pouces, l’ensemble étant géré par un seul logiciel d’administration.Le système supporte aussi Microsoft Hyper-V et Citrix.

L’argument était déjà de réduire le coût total d’exploitation (TCO) et de faciliter l’évolutivité (scalability). Ainsi le volume de stockage peut être étendu sur un réseau SAN, la connectivité réseau étant assurée par un ‘Fabric Interconnect’, conçu à partir du Nexus 5000, précurseur en matière de connexions virtualisées.

Des initiatives alliance, par alliance

Avec EMC et VMWare, Cisco va ensuite créer la ‘joint-venture‘ VCE dédiée à l’offre convergéevBlock, incluant des services de stockage extensibles (fin 2014, Cisco a cédé ses parts VCE à EMC).

Cette coopération avec EMC n’a pas empêché Cisco de signer également un partenariat avec NetApp pour l’offre de stockage intégré FlexPod, quasiment équivalente, toujours sur une base VMware. Et récemment, Cisco a également signé un partenariat avec Nimble, lequel, avec son architecture hybride CASL (Cache accelerated sequential layout), combine unités Flash SSD et disques durs conventionnels.

Le concept plus large d’infrastructure convergée

Dans le même temps, les autres grands acteurs du secteur informatique – HP, Dell, Bull, IBM, Oracle (Sun)… – ne sont pas restés inactifs. Ils avaient, pour certains, déjà engagé des initiatives de systèmes dédiés. Mais le principe d’infrastructure IT convergée a gagné du terrain, avec l’arrivée des offres Cloud.

Sur le modèle de vBlock et de FlexPod, on a ainsi vu se généraliser le concept, plus global, d’infrastructure convergée, qui consiste à organiser l’administration d’un data-centre autour d’un fournisseur et de ses partenaires. Le but est de recourir à des ensembles matériels et logiciels préconfigurés et très concentrés dans un châssis unique, de façon à simplifier l’exploitation de l’ensemble, et en ayant à faire qu’à un seul interlocuteur.

Le cabinet Gartner, pour établir son récent ‘Magic quadrant’ (cf. schéma ci-dessous) sur ce créneau de marché très prometteur (50% de progression par an sur les 3 années écoulées), a utilisé plus sobrement le terme d’« Integrated systems ». Parmi les leaders et visionnaires, il a positionné VCE (EMC), Cisco-NetApp et Oracle et, ensuite, HP, IBM, Dell, puis encore HDS (Hitachi), Fujitsu, mais également Teradata – et au moins des start-ups de l’hyper-convergence, dont Nutanix et Simplivity.

  

De la convergence à la future hyper-convergence

Après les systèmes convergés, on entre désormais dans l’ère de l’infrastructure définie par logiciel. Et là, la partie paraît plus intéressante encore, même si certains risques en découlent au moins pour les phases pilotes.

« Aujourd’hui, les systèmes d’infrastructure hyper-convergés fusionnent d’emblée leurs fonctions centrales de calcul, de stockage et de mise en réseau dans une seule et même solution logicielle ou matérielle », constate le cabinet IDC.

Les différences d’architectures entre un système hyper-convergé et un système convergé ou intégré ne sont pas négligeables. Avec l’hyper-convergence, on va au-delà de l’intégration avec pré-paramétrage fait en usine.

Une pile logicielle hyper-convergée est nécessairement distribuée; elle offre d’emblée une contiguïté des charges de travail, une conteneurisation et une abstraction matérielle », comme l’explique IDC. (lire l’article spécifique dans ce dossier sur l’hyper-convergence).

On entre ici sur le terrain du ‘Software defined’. VMware, avec son appliance EVO:RAIL, a ouvert la voie, reprise par HP (offres Converged System HC 200) ou EMC (EMC VSPEX Blue) et d’autres.

Mais, comme le précise l’article de ce dossier dédié à l’hyper-convergence, il existe des pionniers ou des ‘out-siders’ – comme Nutanix, Simplivity, Nimble et Datacore dans le domaine du stockage de données, ou encore Nexenta – un pionnier de l’univers Open Source. Futjitsu et Huawei, pour ne citer qu’eux, ont choisi de signer un partenariat avec Datacore. Mais rien n’est exclusif…

Une offre considérablement enrichie par des alliances

Tous les géants de l’informatique ont développé des offres intégrées, plus ou moins « convergées ». Certains sont ainsi plus mûrs que d’autres pour se hisser vers l’hyper-convergence. Mais rien n’est joué. Les jeux sont en cours.

HP : une longue lignée

HP a introduit, depuis plusieurs mois, toute une gamme Converged Systems, notamment à partir de son nouveau gestionnaire HP OneView et d’un ensemble d’interfaces programmatiques API unifiés et des ‘plug-ins’ VMware, Microsoft, Red Hat et OpenStack. Fin 2014, HP a annoncé l’utilisation de commutateurs Cisco en ‘top-of-rack’ de ses Converged Systems 700 (et non plus seulement, sa propre offre de commutateurs réseaux ProCurve), comme plateformes IaaS (Infrastructure-as-a-Service).

HP a également développé l’offre Helion pour le Cloud, dont le récent CloudSystem CS200-HC, qui intègre OpenStack (communauté Open Source) et plutôt orienté comme offre PaaS (Plateforme as a Service) et reposant sur la pile logicielle Cloud Foundry (Open source).

Et tout récemment (cf. un autre article de dossier), HP a également introduit deux solutions hyper-convergées, une reposant du EVO:RAIL de VMware et l’autre sur son portefeuille StoreVirtual (d’origine Lefthand Networks).

Oracle (Sun) et ses Exadata

Depuis plusieurs années déjà, Oracle, avec l’héritage « système » de Sun Microsystems, dispose de son offre Exadata. C’est une vraie plateforme convergée et mais dédiée, avec virtualisation. Elle embarque un moteur de bases de données Oracle, comme il se doit.

IBM : VersaStack ; et les PureSystems sans ‘blades’ X86

Fin 2014, IBM a signé un partenariat avec Cisco, dont il n’est plus concurrent s’agissant des serveurs X86 (activité cédée à Lenovo depuis le 1er octobre 2014). Il s’agit de l’offre intégrée VersaStack, qui vise les Clouds privés et les besoins de Big Data et d’applications analytiques.

Par ailleurs, IBM a lancé son architecture intégrée PureSystems, qui consiste, là aussi, à proposer des solutions complètes intégrées, matériel et logiciels, entièrement intégrées et configurées en usine.

Il repose sur les systèmes Flex Systems à base de processeurs Power7+ (puisque les modèles X86 sont désormais chez Lenovo), sous Windows ou Linux, capables de supporter des milliers de VM (machines virtuelles). Les unités de stockage intégrées, virtualisées, sont des IBM Storwize V7000, mais le client peut préférer ou combiner avec des équipements EMC ou NetApp.

IBM propose également PureFlex System (sur Power 7+, toujours) qui est une infrastructure Cloud complète. C’est une offre IaaS, préconfigurée en usine, prête à l’emploi, et administrée par une seule console de management unifiée.

IBM a également décliné l’offre pour des applications spécifiques: ce sont les PureApplication Systems pour des applications Web transactionnelles et bases de données. Là encore, le principe est celui de la simplicité de déploiement, de pré-paramétrage sur mesure. IBM y inclut des expertises métier. Ainsi, le tout récentPureData System est optimisé pour « fournir des services de données pour applications très exigeantes » (par exemple : ‘PureData for Analytics‘).

Dell : du développement et des partenariats

Dell a développé plusieurs générations de systèmes intégrés, dont les VRTX (ensemble que l’on peut qualifier de « boite noire »), mais également la gamme Active Systems sur serveurs lames (1000, 800 et 200) sur le principe d’ensembles pré-équipés et très extensibles, conçus pour constituer des plateformes Cloud, supportant aussi bien Windows que Linux, que des applicatifs Microsoft SQL, Lync ou SharePoint, ou encore Oracle, SAP, etc.

Tout récemment, pour évoluer vers l’hyper-convergence et l’intégration sur le Cloud, Dell s’est rapproché, d’une part, deFireHost, et a conçu des plateformes convergées incluant, là encore, serveurs, stockage, sur virtualisation VMware (NSX).

Dell a, d’autre part, développé un partenariat avec Nutanix, qui a donné lieu à l’offre Dell XC Web-scale Converged Appliance, avec 3 modèles (1 U, supportant VDI, tests ou Cloud privé) et deux de 2U, supportant respectivement Exchange, SharePoint, Big data; ou  SQL, Oracle).