From ce7eb45001633691d1d28cc57058d51c881a3626 Mon Sep 17 00:00:00 2001
From: LecygneNoir
Cela va permettre d'activer l'ip forwarding sur votre interface, et va faire en sorte que toutes vos VM en 192.168.0.0/16 seront nattées lorsqu'elles essaieront de joindre une machine qui n'est pas en 192.168.0.0/16.
Ceci va permettre de rajouter à la machine VMID une interface eth1, branchée sur vmbr1. L'adresse MAC sera générée automatiquement. Le --save rend la modification permanente même après redémarrage de la VM.
@@ -119,7 +119,7 @@ vzctl set VMID --netif_add eth1,,,,vmbr1 --save
echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -o vmbr0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -o vmbr0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j MASQUERADE
-
+```
De cette façon, le NAT sera configuré au démarrage sur vmbr0.
@@ -129,7 +129,7 @@ post-down iptables -t nat -D POSTROUTING -o vmbr0 -s 192.168.0.0/16 ! -d 192.168
addresse 192.168.0.1
netmask 255.255.0.0
broadcast 192.168.0.255
-
+```
diff --git a/content/Système/configurer-reverse-proxy-apache.md b/content/Système/configurer-reverse-proxy-apache.md
index 6a406ca..3eaf088 100644
--- a/content/Système/configurer-reverse-proxy-apache.md
+++ b/content/Système/configurer-reverse-proxy-apache.md
@@ -81,17 +81,17 @@ Status: published
Connectez vous sur votre serveur (mandataire), puis tapez : Redémarrez ensuite Apache un petit coup Editez un fichier dans /etc/apache2/site-available/ Puis configurez votre hôte comme suit : Faites pour chaque fichier que vous avez créé. Ensuite, rechargez la configuration Apache (pas besoin de redémarrer) Il vous faudra activer le SSL sur votre reverse proxy : Ensuite, placez vos certificats (clef publique, clef privée) dans le dossier /etc/apache2/ssl/. Créez l'hôte virtuel qui servira pour votre redirection : Et remplissez le avec ceci : N'oubliez pas bien sûr d'activer votre nouvel hôte virtuel : Et voila, votre reverse proxy doit fonctionner en HTTPS :) Si vous voulez plus de détails sur les versions à installer, rendez vous sur http://haproxy.debian.net/ Nous allons voir ici une configuration de frontend basique. Il est possible de faire des choses très compliquées, mais on va rester simple pour l'instant :-) Attention, l'indentation est importante ! Maintenant que notre frontend est prêt à recevoir les requêtes publiques, il faut créer le backend qui sera à même de savoir où envoyer ces requêtes. De la même manière que pour le frontend, attention à l'indentation pour que les paramètres soient décalés en dessous du mot clef backend Bien sûr, redémarrez haproxy pour appliquer la configuration. Mettre en place un frontend https est tout ce qu'il y a de plus simple. On va tout simplement créer un deuxième frontend, cette fois bindé sur le port 443 On voit quelques différences par rapport à la configuration définie plus haut. Cela se fait très simplement, en utilisant plusieurs acl dans le frontend, par exemple : Vous pouvez ensuite utiliser un ou plusieurs backend selon les acl : Ou encore : Cela peut permettre de créer une acl qui gérera tout ce qui se termine par site.tdl, tout ce qui contient www., etc Vous êtes ensuite libre d'utiliser ces acl dans les backend que vous voulez. Pour cela, il suffit d'ajouter dans le frontend le mot clef default_backend qui permet de définir un backend qui sera utilisé pour les requêtes n'ayant matché aucune acl dans le frontend, et de créer un backend qui renverra par exemple une erreur 403 "accès interdit" : Mais il est également possible de définir des poids pour ces serveurs, si par exemple l'un d'eux est plus puissant, plus à même de recevoir des requêtes Ici server2 encaissera 2 fois plus de requêtes que server1 Vous pouvez utiliser le mot clef backup : Ici, server1 recevra toutes les requêtes, mais si haproxy détecte qu'il n'est plus accessible, alors il enverra automatiquement toutes les requêtes vers server2 Il est possible de dire à haproxy, dans votre frontend sur le port 80, que tel site doit absolument utiliser l'HTTPS. Auquel cas, si haproxy reçoit une requête en HTTP, alors il redirigera immédiatement le visiteur vers exactement la même requête mais en HTTPS : Ici, on va forcer via un code 301 (redirection permanente) la redirection vers l'HTTPS (on détecte que le protocole ssl n'est pas utilisé) pour les accès sur site1.tld et sousdomaine.site1.tld, mais on reste en HTTP et on utilise backend2 si la visite est sur toto.site2.tld Par exemple, si le frontend devant le backend est en https, vous pouvez ajouter un en-tête qui indiquera au serveur web derrière qu'il y a eu traitement https, ce même si le serveur web ne voit jamais le certificat puisque c'est haproxy qui s'en occupe : Vous pouvez ainsi écrire (ou réécrire) n'importe quel en-tête. Par exemple pour réécrire l'en tête serveur :
Cependant, l'un des gros problèmes d'un script automatique, c'est qu'un mot de passe, il a un peu de mal à le taper. Alors, on peut bidouiller me direz-vous :
Pourquoi pas. Mais bon, ça oblige à mettre le mot de passe en clair, ça ne marche pas toujours selon la configuration de votre serveur ssh, et la connexion en root, c'est mal.
Si ce n'est pas déjà fait, installez donc le client openssh :
(Bien sûr, openssh serveur est installé sur votre machine distante)
Ensuite, générez la clé pour votre client :
Il vous faut ensuite répondre à plusieurs questions. La valeur par défaut est correcte, il suffit donc d'appuyer sur Entrée à chaque fois. Pour la passphrase, laissez vide pour qu'elle ne soit pas utilisée (c'est ce que l'on veut pour la connexion automatique)
@@ -69,7 +69,7 @@ Generating public/private rsa key pair.
Your identification has been saved in /home/utilisateur/.ssh/id_rsa.
Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub.
The key fingerprint is:
-XX:8a:XX:91:XX:ae:XX:23:XX:2e:XX:ed:XX:4e:XX:b8 utilisateur@machinecliente
+XX:8a:XX:91:XX:ae:XX:23:XX:2e:XX:ed:XX:4e:XX:b8 utilisateur@machinecliente```
Les deux clés (publique et privée) sont donc stockées directement dans votre dossier home, dans un dossier caché nommé .ssh/
$ iptables -t nat -A POSTROUTING -o vmbr0 -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j MASQUERADE
$ echo 1 > /proc/sys/net/ipv4/ip_forward
-
+```
vzctl set VMID --netif_add eth1,,,,vmbr1 --save
-
+```
+```
$ sudo a2enmod proxy
-$ sudo a2enmod proxy_http
+$ sudo a2enmod proxy_http```
-$sudo /etc/init.d/apache restart
+```
+$sudo /etc/init.d/apache restart```
-$ sudo nano /etc/apache2/sites-available/monsite
+```
+$ sudo nano /etc/apache2/sites-available/monsite```
+```
<VirtualHost *:80>
#
ServerName nomdedomaine.tld #
@@ -119,7 +119,7 @@ ProxyRequests off
ProxyPass / http://IPSERVEURWEBINTERNE/
ProxyPassReverse / http://IPSERVEURWEBINTERNE/
#
-</VirtualHost>
+</VirtualHost>```
+```
$ sudo a2ensite monsite
-
+```
-$ sudo /etc/init.d/apache2 reload
+```
+$ sudo /etc/init.d/apache2 reload```
+```
$ sudo a2enmod ssl
$ sudo /etc/init.d/apache2 restart
-
+```
+```
$ sudo cp moncertificat.* /etc/apache2/ssl/
-
+```
+```
sudo nano /etc/apache2/site-available/monproxySSL
-
+```
+```
<VirtualHost *:443>
# Décommentez cette ligne et indiquez-y l'adresse courriel de l'administrateur du site
@@ -290,14 +290,14 @@ sudo nano /etc/apache2/site-available/monproxySSL
Redirect permanent / https://monsite.tld/
</VirtualHost>
-
+```
+```
$ sudo a2ensite monproxyssl
$ sudo /etc/init.d/apache2 reload
-
+```
+```
aptitude update
-aptitude install haproxy
+aptitude install haproxy```
### Global et default
@@ -97,14 +97,14 @@ aptitude install haproxy
+```
frontend http-in
bind IP_PUBLIQUE:80
mode http
option httplog
acl your_acl hdr(host) votresiteweb.tld
use_backend backend1 if your_acl
-
+```
+```
backend backend1
mode http
option httpchk
option forwardfor except 127.0.0.1
http-request add-header X-Forwarded-Proto https if { ssl_fc }
server web-server1 IP_SERVEUR_WEB:80 maxconn 32
-
+```
-systemctl restart haproxy
+```
+systemctl restart haproxy```
## Un peu plus loin : https
@@ -168,14 +168,14 @@ systemctl restart haproxy
+```
frontend https-in
bind IP_PUBLIQUE:443 ssl crt /etc/haproxy/cert/ no-sslv3
mode http
option httplog
acl your_acl hdr(host) votresiteweb.tld
use_backend backend1 if your_acl
-
+```
-cat domain.tld.crt domain.tld.key > domain.tld.pem
+```
+cat domain.tld.crt domain.tld.key > domain.tld.pem```
+```
acl site1 hdr(host) site1.tld
acl sous-domaine hdr(host) sousdomain.site1.tld
acl toto-site2 hdr(host) toto.site2.tld
-
+```
-use_backend backend1 if site1 or sous-domaine or toto-site2
+```
+use_backend backend1 if site1 or sous-domaine or toto-site2```
+```
use_backend backend1 if site1 or sous-domaine
-use_backend backend2 if toto-site2
+use_backend backend2 if toto-site2```
### Test de domaine dans un frontend
@@ -251,11 +251,11 @@ use_backend backend2 if toto-site2
+```
acl test1 hdr_beg(host) www. #On match ce qui commence par www.
acl test2 hdr_end(host) domain.tld #On match tout ce qui termine par domain.tld
acl test3 hdr_reg(host) REGEX #On match tout ce qui correspond à l'expression régulière REGEX
-
+```
+```
frontend http-in
[...]
default_backend poubelle
@@ -273,7 +273,7 @@ frontend http-in
backend poubelle
mode http
http-request deny
-
+```
### Répartition de charge avec un backend
@@ -281,23 +281,23 @@ backend poubelle
+```
backend backend1
[...]
server server1 ip1:80 weight 1
server server2 ip2:80 weight 2
-
+```
+```
backend backend1
[...]
server server1 ip1:80
server server2 ip2:80 backup
-
+```
+```
frontend http-in
[...]
# On a plusieurs acl
@@ -317,7 +317,7 @@ frontend http-in
redirect scheme https code 301 if !{ ssl_fc } site1.tld or sous-domaine
use_backend backend2 if toto-site2
-
+```
+```
backend backend1
[...]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
-
+```
+```
backend backend1
[...]
rspidel ^server #On commence par effacer l'en tête serveur déjà présent
rspadd Server:\ Vous\ utilisez\ mon\ super\ serveur\ ! #On rajoute un nouvel en-tete Server (attention à bien protéger les espaces par des \)
-
+```
-echo "motdepasse" ssh root@serveurIP
+echo "motdepasse" ssh root@serveurIP```
-$ sudo aptitude update && sudo aptitude install openssh-client
+$ sudo aptitude update && sudo aptitude install openssh-client```
$ ssh-keygen -t rsa -b 4096
-Generating public/private rsa key pair.
+Generating public/private rsa key pair.```
$ ssh-copy-id -i /home/login/.ssh/id_rsa.pub login@machineserveur -Password :+Password :```
Entrez votre mot de passe, et la clé sera directement copiée dans le dossier .ssh/authorized_keys de votre serveur. Ce dossier est dans le home de l'utilisateur du serveur (pas root hein ??)
Now try logging into the machine, with "ssh 'login@machineserveur'", and check in: .ssh/authorized_keys -to make sure we haven't added extra keys that you weren't expecting.+to make sure we haven't added extra keys that you weren't expecting.```
Une fois celà fait, vous pouvez maintenant vous connecter à votre serveur sans avoir besoin d'aucun mot de passe.
Pour testez, faites donc un petit :
-ssh login@machineserveur+ssh login@machineserveur```
La connexion doit s'effectuer sans mot de passe ! Vous pouvez maintenant utiliser à loisir ssh, scp, rsync, ... dans vos scripts !
## Problèmes éventuels : il peut arriver que... @@ -107,30 +107,30 @@ ssh login@machineserveur Les droits du dossier personnel de votre utilisateur sont corrects :$ ls -l /home -drwxr-xr-x 5 login login 4096 3 jui. 2012 login+drwxr-xr-x 5 login login 4096 3 jui. 2012 login``` Les droits doivent être identiques à l'exemple, c'est à dire en 755. Pour eventuellement corriger ça, faites
-$ chmod 755 /home/login+$ chmod 755 /home/login```
$ ls -l /home/login -drwx------ 2 login login 4096 9 sept. 2011 .ssh+drwx------ 2 login login 4096 9 sept. 2011 .ssh``` De même que précedemment, si les droits ne sont pas corrects, faites
-$ chmod 700 /home/login/.ssh+$ chmod 700 /home/login/.ssh```
$ ls -l /home/login/.ssh/authorized_keys --rw------- 2 login login 4096 9 sept. 2011 authorized_keys+-rw------- 2 login login 4096 9 sept. 2011 authorized_keys``` Si ce n'est pas correct, un petit :
-$ chmod 600 /home/login/.ssh/authorized_keys+$ chmod 600 /home/login/.ssh/authorized_keys``` devrait faire l'affaire
-$ ssh-copy-id -i /home/login/.ssh/id_dsa.pub '-pPORT login@machineserveur'+$ ssh-copy-id -i /home/login/.ssh/id_dsa.pub '-pPORT login@machineserveur'```
En fait vous pouvez même passer toutes les options propres à ssh en mettant ça entre ''. (Par exemple l'algorithme de chiffrement, ...)
diff --git a/content/Système/use-letsencrypt-haproxy.md b/content/Système/use-letsencrypt-haproxy.md index 282f750..5628aad 100644 --- a/content/Système/use-letsencrypt-haproxy.md +++ b/content/Système/use-letsencrypt-haproxy.md @@ -86,12 +86,12 @@ You can next directly use the binary to get your new certificate (at least, onceSo we are going to configure a haproxy ACL which match this path to redirect it to a specific backend!
-+``` frontend http-in acl app_letsencrypt path_beg /.well-known/acme-challenge/ [...] use_backend bk-letsencrypt if app_letsencrypt -+```
About the backend, we are going to configure it to redirect request to the server launched by Let's Encrypt client.
-+``` backend bk-letsencrypt log global mode http server srv_letsencrypt 127.0.0.1:63443 -+```
Of course, you need to reload haproxy after doing these modifications.
--systemctl reload haproxy.service+``` +systemctl reload haproxy.service``` ## Configure and use of Let's Encrypt @@ -134,12 +134,12 @@ systemctl reload haproxy.service
By default, the client uses the file /etc/letsencrypt/cli.ini. So this is the file we are going to edit.
-+``` rsa-key-size = 4096 email = your_admin_email authenticator = standalone standalone-supported-challenges = http-01 -+```
The command line to use to generate your certificate is the following:
--/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos+``` +/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos```
In order to use with haproxy, you need to concatenate fullchain.pem and privkey.pem, and store it where haproxy read its certificates.
--cat fullchain.pem privkey.pem > domain.tld.pem+``` +cat fullchain.pem privkey.pem > domain.tld.pem```
For example for the following HTTPS frontend:
-+``` frontend https-in bind IP:443 ssl crt /etc/haproxy/cert/ -+```
Here we need to store the domain.tld.pem file in /etc/haproxy/cert/
@@ -208,13 +208,13 @@ frontend https-inSo remember to configure a cron job on your server to renew certificate:
-+``` crontab -e -+``` -
+``` #renew certificate -30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew+30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew```
This cron task will launch the renew command each 10 days to be sure your certificates will stay valids.
diff --git a/content/Système/utiliser-letsencrypt-haproxy.md b/content/Système/utiliser-letsencrypt-haproxy.md index 519c3e7..901a512 100644 --- a/content/Système/utiliser-letsencrypt-haproxy.md +++ b/content/Système/utiliser-letsencrypt-haproxy.md @@ -88,12 +88,12 @@ Vous pouvez ensuite directement utiliser le binaire pour activer vos certificatsNous allons donc configurer une acl qui cherchera cette chaine pour la rediriger vers un backend spécifique !
-+``` frontend http-in acl app_letsencrypt path_beg /.well-known/acme-challenge/ [...] use_backend bk-letsencrypt if app_letsencrypt -+```
Concernant le backend, nous allons le configurer pour rediriger les requêtes vers le serveur qui sera lancé en local par le client Let's Encrypt.
-+``` backend bk-letsencrypt log global mode http server srv_letsencrypt 127.0.0.1:63443 -+```
Bien sûr, rechargez haproxy après ces modifications.
--systemctl reload haproxy.service+``` +systemctl reload haproxy.service``` ## Configurer et utiliser Let's Encrypt @@ -136,12 +136,12 @@ systemctl reload haproxy.service
Let's Encrypt utilise par défaut le fichier /etc/letsencrypt/cli.ini. Nous allons donc taper dedans directement.
-+``` rsa-key-size = 4096 email = your_admin_email authenticator = standalone standalone-supported-challenges = http-01 -+```
La ligne de commande à utiliser pour générer votre certificat est la suivante :
--/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos+``` +/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos```
Pour haproxy, vous devez concaténer fullchain.pem et privkey.pem dans un seul fichier, et le placer là ou votre haproxy lit ses certificats.
--cat fullchain.pem privkey.pem > domain.tld.pem+``` +cat fullchain.pem privkey.pem > domain.tld.pem```
Un exemple :
-+``` frontend https-in bind IP:443 ssl crt /etc/haproxy/cert/ -+```
Ici, nous devons mettre notre fichier.pem dans le répertoire /etc/haproxy/cert/
@@ -210,10 +210,10 @@ frontend https-inPensez donc à configurer une tache cron sur votre serveur pour renouveler le certificat régulièrement
-+``` crontab -e #renew certificate -30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew+30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew```
Cette tâche permettra de lancer la commande tous les 10 jours, afin d'être sur d'avoir des certificats à jour.