Bon jusque là, les choses se passent plutôt pas mal.

Partie 1 : Présentation de proxmox et de la virtualisation
Partie 2 : Configuration du réseau interne
Partie 3 : Un petit Stress test pour la route
Partie 4 : Quelques optimisations Webserver
Partie 5 : HTTPS et IPV6
Partie 6 : Le Monitoring
Partie 7 : Les Backup

On a un blog qui tourne, un serveur qui va bien. On va pouvoir commencer à ajouter quelques feature avancées.
Comme le nom de l’article l’annonce, on va pouvoir dans cette 5e partie, s’attaquer au HTTPS et à l’IPV6.

Le HTTPS

Le https, suffit pas de rajouter un s à l’url ?

Pour faire fonctionner le https et donc utiliser ssl, il va falloir plusieurs points :

• Pouvoir accéder aux sites web sur le port 443
• Avoir un ou plusieurs certificats
• Modifier les vhost des sites pour prendre ça en compte

Et ce pour chaque serveur qui a besoin de https.

Autant dire que ça devient vite chiant à gérer dès qu’on a plus de 2~3 sites web où l’on veut activer le https.

Et la solution ?

La solution est assez simple, on va configurer le reverse proxy pour qu’il s’occupe du ssl.
Ainsi, on centralise les certificats et les configurations sur le proxy et on n’a plus besoin de toucher aux différents serveurs web.
L’utilisateur se connecte en https jusqu’à notre reverse proxy, qui lui établit une connexion en http sur notre venet.

C’est compliqué de faire ça ?

Non pas tellement, allez c’est parti.
Donc on se dirige vers notre fameux nginx, sur lequel on va créer les certificats dont on a besoin.
N’ayant pas plusieurs centaines d’euros à balancer à la poubelle, je vais faire des certificats autosignés.

mkdir /etc/nginx/ssl
cd /etc/nginx/ssl

 

# Autority
openssl genrsa -des3 -out ca.key 2048
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

# on peut la vérifier avec
openssl x509 -in elao-ca.crt -text -noout

Voilà donc ce petit bout de code va nous permettre de générer un premier certificat, qui va servir à signer tous ceux qu’on fera ensuite.
Lors de la 2nd commande, il devrait vous être demandé quelques informations.
Seul le champ « Common Name » est utile :

#Voici quelques-unes des questions
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Rhone-alpes
Locality Name (eg, city) []:Annecy
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kef Network
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:*.ganbaranai.fr
Email Address []:webmaster@ganbaranai.fr

Voilà, donc on a notre certificat d’origine ca.crt, maintenant on va pouvoir en générer pour tous nos noms de domaines.
Et oui pas possible d’utiliser un certificat pour plusieurs domaines différents.
Voici le code à réitérer pour chaque serveur :

# Server
openssl genrsa -des3 -out ganbaranai-server.key 1024
openssl req -new -key ganbaranai-server.key -out ganbaranai-server.csr
openssl x509 -req -in ganbaranai-server.csr -out ganbaranai-server.crt -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650
# on test
openssl x509 -in ganbaranai-server.crt -text -noout
# on genere un .key sans passphrase
openssl rsa -in ganbaranai-server.key -out ganbaranai-server.nopass.key

Et voilà donc pour ce serveur, on obtient un fichier ganbaranai-server.nopass.key, c’est celui qui sera utilisé par nginx.

C’est déjà bien compliqué non ?

Bah vous avez déjà fait le plus dur coté proxy.
Maintenant il ne reste plus qu’à mettre à jour la config de vos sites nginx pour lesquels vous souhaitez activer https.
Allez, je vais reprendre l’exemple du blog, donc dans /etc/nginx/sites-enabled/blog
J’avais déjà :

server {
server_name blog.ganbaranai.fr;

access_log /var/log/nginx/perso.access.log;
...
}

on va rajouter un second bloc serveur pour le https (avec quasiment les mêmes règles)

server {
listen 443;
server_name blog.ganbaranai.fr blog.remilia.fr;
ssl on;
ssl_certificate /etc/nginx/ssl/ganbaranai-server.crt;
ssl_certificate_key /etc/nginx/ssl/ganbaranai-server.nopass.key;

access_log /var/log/nginx/perso.access.log;
...

location / {
...

proxy_set_header X-Forwarded-Proto $scheme;
add_header Front-End-Https on;
}
}

Et voilà, la config https est bonne, il ne reste plus qu’à faire un /etc/init.d/nginx reload

C’est enfin fini pour le https ?

Oui et non, coté config réseau oui c’est bon. Normalement votre site répond aussi bien en http qu’en https.
Par contre, il est fort probable que votre site soit pas mal broken en https.
La raison est simple, une page en https ne doit charger que des fichiers en https.

Hors souvent les css, js, img présent dans les pages ont été intégrés avec des « http:// »
Il faut donc modifier un peu le code du site pour qu’il prenne ça en compte.
Si vous utilisez un CMS ça a surement été prévu, il suffit de lui indiquer qu’on fait du https.
Pour wordpress, dans wp-config.php, j’ai ajouté :

/** Mise en place du HTTPS derrière un proxy **/
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'){
$_SERVER['HTTPS'] = 'on';
}

Il reste ensuite à fixer quelques css, js présent dans le thème du blog et voilà.
Vous pouvez tester, le blog fonctionne maintenant https

L’IPV6

Bah il suffit de faire apt-get install ipv6 non?

Dans la plupart des cas, votre serveur aura déjà une plage d’ipv6 fourni (et configuré) par votre hébergeur.
Dans le cas d’ovh, j’ai sur mes deux serveurs une /64 et une /128 (avec le temps, ils sont moins généreux).

Le problème de l’ipv6 est jusque là, l’impossibilité de faire du nat (c’est dispo depuis le kernel linux 3.7, mais faut tout upgrade).
On ne peut donc pas se contenter de faire un copier/coller de notre infra ipv4 pour que ça tourne.

L’idée et de seulement permettre l’accès aux sites web en ipv6, et pour ça comme on l’a vu pour l’https précédemment c’est assez simple.
On ne va pas mettre une ipv6 à chaque VM, mais à une seul, le reverse-proxy.

J’ai lu que c’était compliqué ?

Oui ça peut-être vite compliqué comme super simple.
Je vais vous présenter une méthode très simple et très courte.

Alors pour éviter de vous embrouillez par la suite, il va vous falloir 3 IPv6 :
* l’ip de votre serveur physique
* l’ip qui vous souhaitez attribuer à votre vm
* l’ip de gateway

Dans mon cas, la seule info que j’ai d’ovh est dans leur manager est 2001:41d0:1:bdc2::1/64, c’est l’ipv6 du serveur physique.
* l’ip que je souhaite attribuer à ma VM 2001:41d0:1:bdc2::2
* l’ip de gateway 2001:41D0:1:BDff:ff:ff:ff:ff (c’est comme en ipv4 avec 255.255.255, ici ce sont des FF:FF:FF)

Une fois que vous avez ces infos, ça va être assez rapide.
Tout d’abord, il va falloir activer sur votre hôte, le forwarding pour l’ipv6.

C’est l’heure de bosser

Donc ouvrez /etc/sysctl.conf et ajoutez :

# Activate Forwarding
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp = 1

Maintenant le trafic ipv6 va pouvoir transiter entre internet et le venet.
Mais encore faut-il qu’il soit routable, et pour ça j’ai fait un script très simple (set-ipv6.sh)

ip -6 ro add @IP_DU_NETWORK dev vmbr0
ip -6 ro add default via @IP_DE_LA_GATEWAY dev vmbr0
vzctl set @IP_DE_LA_VM --ipadd --save
ip -6 neigh add proxy @IP_DE_LA_VM dev vmbr0

pour moi, voici les info qu’il prend

ip -6 ro add 2001:41D0:1:BDff::/64 dev vmbr0
ip -6 ro add default via 2001:41D0:1:BDff:ff:ff:ff:ff dev vmbr0
vzctl set 100 --ipadd 2001:41D0:1:BDc2::2 --save
ip -6 neigh add proxy 2001:41D0:1:BDc2::2 dev vmbr0

Il ne reste plus qu’à faire un coup de

chmod +x set-ipv6.sh
./set-ipv6.sh

Et Bam, votre VM va se trouver avec une IPV6 (il est parfois nécessaire de faire un restart de la VM).

Si vous avez un autre serveur, vous pouvez tester la connectivité via ping6 qui fonctionne comme la commande ping mais en ipv6.
Exemple : ping6 google.fr ou ping6 2001:41D0:1:BDc2::2

P.S. Il va falloir bien entendu lancer automatiquement ce script au démarrage du serveur.

Et c’est bon là ?

Non pas encore, il va falloir allez changer les règles DNS. Et oui, tous les sous-domaines sont saisies via des entrées A.
C’est un entrée uniquement IPV4, il va falloir rajouter des entrées AAAA et saisir l’ip de notre vm si dessus.
Après quelques minutes ping6 blog.ganbarai.fr répond correctement.

Mais il reste un tout petit détail à régler. Nginx n’est pas encore au courant de nos changements et il n’écoute pas forcément sur le port 80 de l’ipv6.
Il va falloir modifier les vhost encore une fois. On retourne donc dans notre /etc/nginx/sites-enabled/blog
Et ajouter ces paramètres :

server {
listen 80 default_server;
listen [::]:80 ipv6only=on default_server;
server_name blog.ganbaranai.fr;
...
}
server {
listen 443 ssl default_server;
listen [::]:443 ipv6only=on ssl default_server;
server_name blog.ganbaranai.fr;
...
}

Encore une fois, un petit /etc/init.d/nginx reload et normalement cette fois-ci c’est bon.
Voici un site qui vous permet de tester que ça fonctionne : http://ipv6-test.com/

Allez ++