Projet

Général

Profil

VirtualisationService » Historique » Version 5

Version 4 (Laurent GUERBY, 09/09/2013 22:45) → Version 5/39 (Raphaël Durand, 10/09/2013 22:50)

{{>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, ...) sur host pour redispatch par domaine sur VM1+VM2
- tcp/443 => idem
- 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.

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 serveur.
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 *.domaine;
location / {
proxy_pass http://10.255.254.1;
}
}
server {
listen 443;
server_name ultrawaves.fr;
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, l'IP de 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