80 lines
6.9 KiB
Markdown
80 lines
6.9 KiB
Markdown
|
---
|
||
|
|
title: Wireguard, le VPN sauce KISS
|
||
|
|
date: 2020-05-14
|
||
|
|
author: raspbeguy
|
||
|
|
template: post
|
||
|
|
tags: tutoriel,vpn,kiss,sécurité,réseau
|
||
|
|
---
|
||
|
|
|
||
|
|
Vous vous souvenez la dernière fois que je vous ai parlé de Wireguard ? Moi non plus, je n'en ai jamais parlé, et c'est un scandale. Ça fait pourtant presque un an que je l'utilise à titre personnel et c'est clairement un de mes outils système préféré toutes catégories confondues.
|
||
|
|
|
||
|
|
Il y a eu beaucoup d'articles sur Wireguard, beaucoup de tests, beaucoup de comparatifs. Il faut dire que ce n'est pas passé inaperçu, à tel point que même le grand Linus en a dit du bien.
|
||
|
|
|
||
|
|
Mais vous savez bien que je ne suis pas du genre à vanter les prouesses d'un outil pour la seule raison qu'il est à la mode. Sinon je ferais du Docker, de nombreux frameworks Javascript, du Big Data et d'autres digitaleries marketeuses.
|
||
|
|
|
||
|
|
Sans plus tarder, je vais donc vous faire l'affront de vous présenter un outil qui est déjà bien couvert.
|
||
|
|
|
||
|
|
Je suis tombé sur Wireguard il y a quelques années en me baladant sur le site de [Jason Donenfeld](https://www.zx2c4.com/), l'auteur de [pass](https://www.passwordstore.org/), un gestionnaire de mot de passe que j'utilisais déjà. De quoi, je vous en ai jamais parlé non plus ? Franchement c'est impardonnable.
|
||
|
|
|
||
|
|
# Présentation
|
||
|
|
|
||
|
|
[Wireguard](https://www.wireguard.com/) est un VPN. Un VPN, pour rappel, c'est le fait de mettre plusieurs machines plus ou moins éloignées géographiquement sur un même réseau abstrait, et bien entendu de manière sécurisée. Les VPN sont très utilisés de nos jour, surtout depuis le début du confinement et l'explosion du télétravail. Je vous ai déjà parlé d'OpenVPN par exemple [ici](/posts/parcs-informatiques-partie-1-lan-to-lan) et [ici](/posts/quand-debian-me-gonfle-stretch-et-openvpn). Pour moi, avant Wireguard, OpenVPN était le VPN le plus pratique à déployer. Cependant il a plusieurs défauts :
|
||
|
|
|
||
|
|
* La sécurité des transferts est faible voire trouée, notament à cause de l'usage de la bibliothèque OpenSSL.
|
||
|
|
* Les performances sont loin d'être optimales.
|
||
|
|
* Plusieurs implémentations différentes mênent à des comportement différents selon les plateformes.
|
||
|
|
* Le volume de code est extravagant.
|
||
|
|
|
||
|
|
D'autres VPN existent et sont un peu plus performants et plus sûrs, comme IPsec. Mais, concernant IPsec, son utilisation est un peu mystique si j'ose dire, et niveau volume de code, c'est encore pire. Mais alors, d'où vient cette malédiction des VPN ? Pas vraiment d'explication si ce n'est que le code est assez vieux, ce qui d'habitude mène à un outil solide et à l'épreuve des bugs, alors qu'ici cela a apporté des couches de codes cancéreuses et la nécrose qui l'accompagne.
|
||
|
|
|
||
|
|
Wireguard est donc un nouveau VPN qui est, malgré son aproche moderne et son chiffrement dernier cri, le premier à miser sur la maintenabilité et le minimalisme de son code. Cette stratégie vise à faciliter les audits de sécurité (afin que tout le monde sache que c'est un protocole sûr) et la réduction de la surface d'attaque de personnes malveillantes (moins de code = moins de failles).
|
||
|
|
|
||
|
|
Autre point très important, et c'est pour moi le point clef, c'est la simplicité d'utilisation pour les administrateurs systèmes. En gros, une connexion Wireguard pourra être manipulées avec les outil réseau standards disponibles sur UNIX. La simplicité se retrouve aussi dans la configuration. L'établissement d'une liaison Wireguard est pensée pour être aussi simple qu'une connexion SSH. Il s'agit en effet d'un simple échange de clef publiques. Donenfeld dit s'inspirer de la simplicité des outils OpenBSD.
|
||
|
|
|
||
|
|
Le protocole étant été prévu comme intégré directement au noyau, il s'est présenté sous la forme d'un module kernel jusqu'à sa [fusion directe dans le noyau Linux le 30 mars dernier](https://lists.zx2c4.com/pipermail/wireguard/2020-March/005206.html). Un [patch pour le noyau OpenBSD](https://lists.zx2c4.com/pipermail/wireguard/2020-May/005427.html) est en cours de peaufinage et fera d'OpenBSD le deuxième système d'exploitation intégrant Wireguard nativement.
|
||
|
|
|
||
|
|
# Topologie
|
||
|
|
|
||
|
|
Contrairement à OpenVPN qui par défaut a une vision client/serveur, c'est à dire que tous les membres du réseau privé gravitent autour d'un unique point d'accès, Wireguard laisse une grande liberté de manœuvre et considère tous les membres du VPN comme des pairs indépendants : chaque nœud possède une liste de pair à qui il va parler directement. Par example, imaginons un réseau privé de trois machines Alice, Bob et Carol. Le plus efficace serait que chacune des trois machines connaisse toutes les autres, c'est à dire qu'elle ait deux pairs correspondant aux deux autres machines :
|
||
|
|
|
||
|
|
* Pairs d'Alice :
|
||
|
|
- Bob
|
||
|
|
- Carol
|
||
|
|
* Pairs de Bob :
|
||
|
|
- Alice
|
||
|
|
- Carol
|
||
|
|
* Pairs de Carol :
|
||
|
|
- Alice
|
||
|
|
- Carol
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
L'ennui, c'est que si on veut ajouter une nouvelle machine Dave en respectant cette topologie, il faut récupérer les infos de toutes les autres machines (Alice, Bob et Carol) pour dresser la liste de pairs de Dave, et ensuite on doit ajouter Dave à la liste de pairs d'Alice, Bob et Carol.
|
||
|
|
|
||
|
|
De plus, pour établir une liaison entre deux pairs, il faut un point d'accès connu pour au moins un des pairs (une IP et un port UDP). Si on ne connait pas les points d'accès d'Alice et Bob, ou alors si Alice et Bob n'ont pas besoin de se parler entre eux et s'intéressent uniquement à Carol, alors Alice et Bob n'ont besoin que de Carol dans leurs liste de pairs. Carol doit avoir Alice et Bob dans ses pairs. C'est le scénario connu sous le nom de *roadwarrior* : Alice et Bob sont des pairs mobiles et Carol est une passerelle vers un autre réseau dont les pairs mobiles ont besoin. Dans le cas d'usage du télétravail, Alice et Bob sont des salariés chez eux et Carol est la passerelle du parc informatique de l'entreprise.
|
||
|
|
|
||
|
|
* Pairs d'Alice :
|
||
|
|
- Carol
|
||
|
|
* Pairs de Bob :
|
||
|
|
- Carol
|
||
|
|
* Pairs de Carol :
|
||
|
|
- Alice
|
||
|
|
- Bob
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
Ainsi, quand on voudra ajouter Dave dans la topologie, il suffira que Dave ait connaissance de Carol dans sa liste de pairs, et il faudra dire à Carol d'ajouter Dave à ses pairs.
|
||
|
|
|
||
|
|
Ne vous méprenez pas, dans la topologie *roadwarrior*, le fait que les pairs mobiles ne soient pas les uns dans les listes de pairs des autres ne signifie pas obligatoirement qu'il ne pourront pas communiquer entre eux. Simplement, ils devront communiquer en passant par la passerelle (qui devra être préparée à cet effet) au lieu de communiquer directement comme dans le cas où tout le monde connait tout le monde.
|
||
|
|
|
||
|
|
# Paire de clefs
|
||
|
|
|
||
|
|
Je vous ai parlé d'échanges de clefs sauce SSH. Pour établir une laison entre deux pairs, il faut que chacun des pairs génère une paire de clef.
|
||
|
|
|
||
|
|
```
|
||
|
|
wg genkey | tee private.key | wg pubkey > public.key
|
||
|
|
```
|
||
|
|
|
||
|
|
`wg genkey` va générer une clef privée et `wg pubkey` va créer la clef publique correspondante.
|
||
|
|
|