diff --git a/content/Réseaux/proxmox-lan-au-sein-d-une-dedibox-online.md b/content/Réseaux/proxmox-lan-au-sein-d-une-dedibox-online.md index 3537b8f..a03d4eb 100644 --- a/content/Réseaux/proxmox-lan-au-sein-d-une-dedibox-online.md +++ b/content/Réseaux/proxmox-lan-au-sein-d-une-dedibox-online.md @@ -80,7 +80,7 @@ Status: published
$ 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 -+```
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.
@@ -96,7 +96,7 @@ Status: published
vzctl set VMID --netif_add eth1,,,,vmbr1 --save -+```
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 :
-+``` $ sudo a2enmod proxy -$ sudo a2enmod proxy_http+$ sudo a2enmod proxy_http```
Redémarrez ensuite Apache un petit coup
--$sudo /etc/init.d/apache restart+``` +$sudo /etc/init.d/apache restart```
@@ -103,14 +103,14 @@ $sudo /etc/init.d/apache restart
Editez un fichier dans /etc/apache2/site-available/
--$ sudo nano /etc/apache2/sites-available/monsite+``` +$ sudo nano /etc/apache2/sites-available/monsite```
Puis configurez votre hôte comme suit :
-+``` <VirtualHost *:80> # ServerName nomdedomaine.tld # @@ -119,7 +119,7 @@ ProxyRequests off ProxyPass / http://IPSERVEURWEBINTERNE/ ProxyPassReverse / http://IPSERVEURWEBINTERNE/ # -</VirtualHost>+</VirtualHost>```
@@ -133,9 +133,9 @@ ProxyPassReverse / http://IPSERVEURWEBINTERNE/
Faites
-+``` $ sudo a2ensite monsite -+```
pour chaque fichier que vous avez créé.
@@ -143,8 +143,8 @@ $ sudo a2ensite monsiteEnsuite, rechargez la configuration Apache (pas besoin de redémarrer)
--$ sudo /etc/init.d/apache2 reload+``` +$ sudo /etc/init.d/apache2 reload```
@@ -184,26 +184,26 @@ $ sudo /etc/init.d/apache2 reload
Il vous faudra activer le SSL sur votre reverse proxy :
-+``` $ sudo a2enmod ssl $ sudo /etc/init.d/apache2 restart -+```
Ensuite, placez vos certificats (clef publique, clef privée) dans le dossier /etc/apache2/ssl/.
-+``` $ sudo cp moncertificat.* /etc/apache2/ssl/ -+```
Créez l'hôte virtuel qui servira pour votre redirection :
-+``` sudo nano /etc/apache2/site-available/monproxySSL -+```
Et remplissez le avec ceci :
-+``` <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> -+```
N'oubliez pas bien sûr d'activer votre nouvel hôte virtuel :
-+``` $ sudo a2ensite monproxyssl $ sudo /etc/init.d/apache2 reload -+```
Et voila, votre reverse proxy doit fonctionner en HTTPS :)
diff --git a/content/Système/configurer-reverse-proxy-haproxy.md b/content/Système/configurer-reverse-proxy-haproxy.md index 91912f6..14a0853 100644 --- a/content/Système/configurer-reverse-proxy-haproxy.md +++ b/content/Système/configurer-reverse-proxy-haproxy.md @@ -79,9 +79,9 @@ Status: publishedSi vous voulez plus de détails sur les versions à installer, rendez vous sur http://haproxy.debian.net/
-+``` aptitude update -aptitude install haproxy+aptitude install haproxy``` ### Global et default @@ -97,14 +97,14 @@ aptitude install haproxy
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 :-)
-+``` frontend http-in bind IP_PUBLIQUE:80 mode http option httplog acl your_acl hdr(host) votresiteweb.tld use_backend backend1 if your_acl -+```
Attention, l'indentation est importante !
@@ -131,14 +131,14 @@ frontend http-inMaintenant 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.
-+``` 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 -+```
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
@@ -157,8 +157,8 @@ backend backend1Bien sûr, redémarrez haproxy pour appliquer la configuration.
--systemctl restart haproxy+``` +systemctl restart haproxy``` ## Un peu plus loin : https @@ -168,14 +168,14 @@ systemctl restart haproxy
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
-+``` 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 -+```
On voit quelques différences par rapport à la configuration définie plus haut.
@@ -186,8 +186,8 @@ frontend https-in-cat domain.tld.crt domain.tld.key > domain.tld.pem+``` +cat domain.tld.crt domain.tld.key > domain.tld.pem```
Cela se fait très simplement, en utilisant plusieurs acl dans le frontend, par exemple :
-+``` acl site1 hdr(host) site1.tld acl sous-domaine hdr(host) sousdomain.site1.tld acl toto-site2 hdr(host) toto.site2.tld -+```
Vous pouvez ensuite utiliser un ou plusieurs backend selon les acl :
--use_backend backend1 if site1 or sous-domaine or toto-site2+``` +use_backend backend1 if site1 or sous-domaine or toto-site2```
Ou encore :
-+``` 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
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
-+``` 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 -+```
Vous êtes ensuite libre d'utiliser ces acl dans les backend que vous voulez.
@@ -265,7 +265,7 @@ acl test3 hdr_reg(host) REGEX #On match tout ce qui correspond à l'expression rPour 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" :
-+``` 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
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
-+``` backend backend1 [...] server server1 ip1:80 weight 1 server server2 ip2:80 weight 2 -+```
Ici server2 encaissera 2 fois plus de requêtes que server1
Vous pouvez utiliser le mot clef backup :
-+``` backend backend1 [...] server server1 ip1:80 server server2 ip2:80 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
@@ -307,7 +307,7 @@ backend backend1Il 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 :
-+``` 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 -+```
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
@@ -329,22 +329,22 @@ frontend http-inPar 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 :
-+``` backend backend1 [...] http-request add-header X-Forwarded-Proto https if { ssl_fc } -+```
Vous pouvez ainsi écrire (ou réécrire) n'importe quel en-tête.
Par exemple pour réécrire l'en tête serveur :
-+``` 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 \) -+```
diff --git a/content/Système/connexion-ssh-par-cle.md b/content/Système/connexion-ssh-par-cle.md index f7505bc..fcb3deb 100644 --- a/content/Système/connexion-ssh-par-cle.md +++ b/content/Système/connexion-ssh-par-cle.md @@ -21,7 +21,7 @@ Status: published
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 :
-echo "motdepasse" ssh root@serveurIP+echo "motdepasse" ssh root@serveurIP```
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.
@@ -53,14 +53,14 @@ echo "motdepasse" ssh root@serveurIPSi ce n'est pas déjà fait, installez donc le client openssh :
-$ sudo aptitude update && sudo aptitude install openssh-client+$ sudo aptitude update && sudo aptitude install openssh-client```
(Bien sûr, openssh serveur est installé sur votre machine distante)
Ensuite, générez la clé pour votre client :
$ ssh-keygen -t rsa -b 4096 -Generating public/private rsa key pair.+Generating public/private rsa key pair.```
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/
## Envoi de la clé au serveur : tuyau crypté @@ -79,19 +79,19 @@ XX:8a:XX:91:XX:ae:XX:23:XX:2e:XX:ed:XX:4e:XX:b8 utilisateur@machinecliente Pour ça, le meilleur moyen reste encore ssh ! Il va vous falloir une dernière fois votre mot de passe pour vous connecter au serveur. Grâce aux outils ssh, il suffit de faire :$ 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.