{{>toc}}

h1. VirtualisationService

h2. Objet

Dans l'environnement tetaneutral.net un adhérent a le choix d'utiliser plusieurs IPv4 publiques et un bridge avec son interface pour virtualiser mais ceci consomme plusieurs IPv4 publiques.

Une alternative est de n'utiliser qu'une IPv4 publique et de creer des VMs sur un bridge interne (qui n'a pas l'interface de sortie comme port) avec des IPv4 privées et de se servir de l'hote pour router les requetes de service suivant les ports. Par exemple 

- tcp/2222 => ssh host

- tcp/2223 => ssh VM1

- tcp/2224 => ssh VM2

- tcp/2225 => ssh VM3

- tcp/80 => reverse proxy (nginx, apache, varnish, ...) sur host pour redispatch par domaine sur VM1+VM2

- tcp/443 => idem (ouais mais faut gérer le SSL alors !?)

- udp/1194 => serveur openvpn sur VM3

En IPv6 il n'y a pas de probleme car l'adhérent a un /56 donc pas de limite aux IPs de service, il suffit de demander l'activation du routage IPv6 coté tetaneutral.net

h2. Solutions

Solarus : - Pour mutualiser une IPv4 sur HTTP on peut mettre en place un proxy nginx. J'en ai déjà un en place sur mon serveur. Je peux le prêter ou en faire un tuto pour en monter un.

- Pour le reste des flux, je conseille de monter un NAT/PAT et configurer les redirections de port entrants. On peut faire ça avec IPtables sous Linux ou BSD. On peut utiliser une machine virtuelle ou un OpenWRT si on veut le faire sur une machine séparée.

Fab :

- En cas de reverse proxy HTTP, faut gérer le SSL pour le HTTPS...galère, galère

- On peut déjà migrer tous les services internes à TTNN sur des IP RFC 1918, quitte à superviser les VM/machines via un rebond SSH (possible dans cmk) ou qu'en IPv6 (possible aussi)

- Pour tout ce qui est serveur de mail, on peut proposer un (ou même plusieurs) MTA qui accepte tous les domaines des MTA hébergés sur les VMs et qui redispatche (une sorte de reverse proxy mail, en fait)

- Pour certaines VMs/machines qui n'hébergent pas de services ouverts ont peut sensibiliser les adhérents à l'IPv6 only (c'est ce que je fait sur ma VM)

h2. Liens

TODO

h2. Configuration d'un reverse proxy nginx

Ci-dessous voici une conf typique pour mettre en place un reverse-proxy nginx afin de partager une IP publique pour plusieurs serveurs.

Le systeme fonctionne par Virtual Host (comme sous Apache)

Pour chaque Virtual Host, il faut créer un fichier de ce type dans /etc/nginx/sites-enabled

<pre>

server {

        listen   80;

        server_name  *.exemple.tld;

        location / {

                proxy_pass         http://10.255.254.1;

    }

}

server {

        listen 443;

        server_name  *.exemple.tld;

        ssl                     on;

        ssl_certificate     certificat_ssl.crt;

        ssl_certificate_key certificat_ssl.crt;

        location / {

                proxy_pass         https://10.255.254.1;

    }

}

</pre>

Les champs à remplir sont 'server_name' avec le domaine du virtual host et 'proxy_pass' avec l'IP privée du serveur.

Le deuxième bloc servira uniquement si vous voulez faire du HTTPS, il vous restera alors à renseigner les emplacements des certificats.

Cette méthode présente un inconvénient c'est que l'IP des visiteurs n'est pas directement visible,ce qui peut être gênant pour les blogs et les système de commentaires.

h2. Documentation

TODO

nginx

apache

varnish

iptables

shorewall

netcat

h2. Bénévoles

TODO toulibre ou capitole du libre