@ -101,7 +101,7 @@ La première chose que l'on va faire, c'est dégager telnet et configurer ssh.
Pour cela, on va se reconnecter une dernière fois en telnet. **Notez que OpenWRT par défaut utilise 192.168.1.0/24 comme réseau.**
..code::
..code-block:: bash
$ telnet 192.168.1.1
Trying 192.168.1.1...
@ -114,7 +114,7 @@ Pour cela, on va se reconnecter une dernière fois en telnet. **Notez que OpenWR
Comme l'indique si gentiment le motd, il suffit de configurer un mot de passe à l'aide de ``passwd`` pour activer le SSH et désactiver telnet, il n'y a plus qu'à :
..code::
..code-block:: bash
root@OpenWrt:/# passwd
Changing password for root
@ -162,7 +162,7 @@ Openwrt n'a pas de base les drivers nécessaires pour reconnaître les périphé
Connectez vous en SSH au routeur et installez les paquets :
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.</p>
@ -96,7 +96,7 @@ Status: published
<p>
<preclass="brush:bash;">
vzctl set VMID --netif_add eth1,,,,vmbr1 --save
</pre>
```
<p>
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.</p>
<p>
@ -119,7 +119,7 @@ vzctl set VMID --netif_add eth1,,,,vmbr1 --save
<p>Si vous voulez plus de détails sur les versions à installer, rendez vous sur <ahref="http://haproxy.debian.net/">http://haproxy.debian.net/</a></p>
<pre>
```
aptitude update
aptitude install haproxy</pre>
aptitude install haproxy
```
### Global et default
@ -97,14 +98,14 @@ aptitude install haproxy
<p>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 :-)</p>
<pre>
```
frontend http-in
bind IP_PUBLIQUE:80
mode http
option httplog
acl your_acl hdr(host) votresiteweb.tld
use_backend backend1 if your_acl
</pre>
```
<p>Attention, l'indentation est importante !</p>
@ -131,14 +132,14 @@ frontend http-in
<p>Maintenant que notre frontend est prêt à recevoir les requêtes publiques, il faut créer le backend qui sera à même de savoir <strong>où</strong> envoyer ces requêtes.</p>
<pre>
```
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
</pre>
```
<p>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 <em>backend</em></p>
@ -157,8 +158,8 @@ backend backend1
<p>Bien sûr, redémarrez haproxy pour appliquer la configuration.</p>
<pre>
systemctl restart haproxy</pre>
```
systemctl restart haproxy```
## Un peu plus loin : https
@ -168,14 +169,14 @@ systemctl restart haproxy
<p>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</p>
<p>On voit quelques différences par rapport à la configuration définie plus haut.</p>
@ -186,8 +187,8 @@ frontend https-in
<li>crt /etc/haproxy/cert/ : définit le répertoire dans lequel vous mettre vos certificats. haproxy gère les certificats au format pem, que vous pouvez simplement créer de la façon suivante en mergeant le .crt et le .key :</li>
<p>Cela se fait très simplement, en utilisant plusieurs acl dans le frontend, par exemple :</p>
<pre>
```
acl site1 hdr(host) site1.tld
acl sous-domaine hdr(host) sousdomain.site1.tld
acl toto-site2 hdr(host) toto.site2.tld
</pre>
```
<p>Vous pouvez ensuite utiliser un ou plusieurs backend selon les acl :</p>
<pre>
use_backend backend1 if site1 or sous-domaine or toto-site2</pre>
```
use_backend backend1 if site1 or sous-domaine or toto-site2```
<p>Ou encore :</p>
<pre>
```
use_backend backend1 if site1 or sous-domaine
use_backend backend2 if toto-site2</pre>
use_backend backend2 if toto-site2```
### Test de domaine dans un frontend
@ -251,11 +252,11 @@ use_backend backend2 if toto-site2
<p>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</p>
<pre>
```
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
</pre>
```
<p>Vous êtes ensuite libre d'utiliser ces acl dans les backend que vous voulez.</p>
@ -265,7 +266,7 @@ acl test3 hdr_reg(host) REGEX #On match tout ce qui correspond à l'expression r
<p>Pour cela, il suffit d'ajouter dans le frontend le mot clef <em>default_backend</em> 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" :</p>
<pre>
```
frontend http-in
[...]
default_backend poubelle
@ -273,7 +274,7 @@ frontend http-in
backend poubelle
mode http
http-request deny
</pre>
```
### Répartition de charge avec un backend
@ -281,23 +282,23 @@ backend poubelle
<p>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</p>
<pre>
```
backend backend1
[...]
server server1 ip1:80 weight 1
server server2 ip2:80 weight 2
</pre>
```
<p>Ici server2 encaissera 2 fois plus de requêtes que server1</p>
<p>Vous pouvez utiliser le mot clef backup :</p>
<pre>
```
backend backend1
[...]
server server1 ip1:80
server server2 ip2:80 backup
</pre>
```
<p>Ici, server1 recevra <strong>toutes</strong> les requêtes, <strong>mais</strong> si haproxy détecte qu'il n'est plus accessible, alors il enverra automatiquement toutes les requêtes vers server2</p>
@ -307,7 +308,7 @@ backend backend1
<p>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 :</p>
<pre>
```
frontend http-in
[...]
# On a plusieurs acl
@ -317,7 +318,7 @@ frontend http-in
redirect scheme https code 301 if !{ ssl_fc } site1.tld or sous-domaine
use_backend backend2 if toto-site2
</pre>
```
<p>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</p>
@ -329,22 +330,22 @@ frontend http-in
<p>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 :</p>
<pre>
```
backend backend1
[...]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
</pre>
```
<p>Vous pouvez ainsi écrire (ou réécrire) n'importe quel en-tête.</p>
<p>Par exemple pour réécrire l'en tête serveur :</p>
<pre>
```
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 \)
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 :</p>
<preclass="brush:bash;">
echo "motdepasse" ssh root@serveurIP</pre>
```
echo "motdepasse" ssh root@serveurIP
```
<p>
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.</p>
Sur votre machine cliente, il va d'abord falloir générer la fameuse clé. Ou plutôt, le couple de clé, la clé publique et la clé privée. <ahref="http://fr.wikipedia.org/wiki/Cryptographie_asymétrique">(Voir la cryptographie asymétrique)</a></p>
<p>
Si ce n'est pas déjà fait, installez donc le client openssh :</p>
(Bien sûr, openssh serveur est installé sur votre machine distante)</p>
<p>
Ensuite, générez la clé pour votre client :</p>
<preclass="brush:php;">
```
$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.</pre>
<p>
Generating public/private rsa key pair.
```<p>
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)</p>
<p>
Une fois la clé générée, un petit resumé est affiché :</p>
<preclass="brush:bash;">
```
Your identification has been saved in /home/utilisateur/.ssh/id_rsa.
Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub.
Les deux clés (publique et privée) sont donc stockées directement dans votre dossier home, dans un dossier caché nommé .ssh/</p>
## Envoi de la clé au serveur : tuyau crypté
<p>
Le moment délicat est arrivé. Il vous faut transmettre votre clé au serveur, de préférence via un moyen crypté. (Bah oui, envoyer la clé en clair via ftp par exemple vous expose à vous la faire piquer, et donc potentiellement pirater...)</p>
<p>
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 :</p>
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 ??)</p>
<preclass="brush:bash;">
```
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.</pre>
to make sure we haven't added extra keys that you weren't expecting.
```
<p>
Une fois celà fait, vous pouvez maintenant vous connecter à votre serveur sans avoir besoin d'aucun mot de passe.</p>
<p>
Pour testez, faites donc un petit :</p>
<preclass="brush:bash;">
ssh login@machineserveur</pre>
```
ssh login@machineserveur
```
<p>
La connexion doit s'effectuer sans mot de passe ! Vous pouvez maintenant utiliser à loisir ssh, scp, rsync, ... dans vos scripts !</p>
## Problèmes éventuels : il peut arriver que...
@ -105,32 +109,38 @@ ssh login@machineserveur
<ol>
<li>
Les droits du dossier personnel de votre utilisateur sont corrects :
<p>By default, the client uses the file <em>/etc/letsencrypt/cli.ini</em>. So this is the file we are going to edit.</p>
<pre>
```
rsa-key-size = 4096
email = your_admin_email
authenticator = standalone
standalone-supported-challenges = http-01
</pre>
```
<ul>
<li>rsa-key-size: tell letsencrypt to direclty generate 4096 bits certificate, more strong that default 2048. You can downgrade to 2048 (but never less!) if your server is low performance to gain some generation time</li>
<li>path_beg : cherche les URL dont le path (ce qui est après le premier / de l'url) commence par <em>.well-known/acme-challenge/</em></li>
@ -109,12 +109,12 @@ frontend http-in
<p>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.</p>
<pre>
```
backend bk-letsencrypt
log global
mode http
server srv_letsencrypt 127.0.0.1:63443
</pre>
```
<ul>
<li>mode http : permet, tant qu'à faire, de vérifier qu'il s'agit bien d'une requête http qui passe par ce backend</li>
@ -125,8 +125,9 @@ backend bk-letsencrypt
<p>Bien sûr, rechargez haproxy après ces modifications.</p>
<p>Let's Encrypt utilise par défaut le fichier <em>/etc/letsencrypt/cli.ini</em><em>. </em>Nous allons donc taper dedans directement.</p>
<pre>
```
rsa-key-size = 4096
email = your_admin_email
authenticator = standalone
standalone-supported-challenges = http-01
</pre>
```
<ul>
<li>rsa-key-size ; permet de générer directement des certificats de 4096 bit, plus robustes que le 2048 par défaut. Vous pouvez redescendre à 2048 (mais pas en dessous !) si votre serveur est peu puissant pour gagner du temps de génération.</li>
<li>certonly : précise que l'on souhaite simplement générer le certificat, et pas utiliser un plugin d'installation pour stocker les certificats quelque part</li>
