• Contenu
• VirtualisationService
  • Objet
  • Solutions
  • Liens
  • Configuration d'un reverse proxy nginx
  • Documentation
  • Bénévoles

VirtualisationService¶

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

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.

Liens¶

TODO

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

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;
    }
}

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.

Documentation¶

TODO
nginx
apache
varnish
iptables
shorewall
netcat

Bénévoles¶

TODO toulibre ou capitole du libre