Wireguard n’est pas disponible sur Raspbian.
Je ne connais pas, je me note ça. Le nom me dit quelque chose…
Oui, mais ça ne fait pas que ça, on peut passer énormément de choses via un tunnel SSH.
Ah bon oO ?
On trouve des tutoriels assez récents expliquant la mise en place depuis les dépôts testing à voir si les dépôts backport de Debian ne contiennent pas non plus le nécessaire 
:
Pour ceux qui ne connaissent pas Wireguard (désolé c’est en anglais)
Le tunnel ssh est une autre utilisation de openSSH en effet, mais nécessite d’avoir établi une connexion permanente, alors que SSH s’utilise le plus couramment en listener.
Ah, oui, je confirme, l’installation est faite, maintenant, il faut le configurer, il faut juste que je trouve comment…
Pour le lien que tu as fourni, merci beaucoup, ça m’a permis de l’installer, mais la mise en œuvre ne semble pas correspondre au besoin. Je dois faire un pont entre deux réseaux, le tutoriel semble indiquer comment joindre des clients au réseau du serveur.
Une fois tes machines connecté tu pourrais via iptables interconnecté tes réseaux ?
C’est pas des plus propre mais ça a déjà fonctionné sur un lab pour ma part
iptables ne sert pas à interconnecter des réseaux mais à filtrer et modifier les paquets IP.
Oui en effet sémantiquement parlant ce que j’ai dit est faux.
J’ai retrouvé un article pas trop vieux assez intéressant :
Après installation, j’ai mis ce fichier /etc/wireguard/nut2lookout.conf sur Nut :
[Interface]
Address = 10.255.255.1
Address = 2001:bc8:3335:ff00::1
PrivateKey = <clef privée Nut>
ListenPort = 11000
Postup = /bin/systemctl restart dnsmasq
[Peer]
PublicKey = <clef publique Lookout>
Endpoint = 2a01:e0a:12c:3940:::11000
AllowedIPs = 10.255.255.2/32
AllowedIPs = 2001:bc8:3335:ff00::2/128
AllowedIPs = 10.255.1.0/24
AllowedIPs = 2a01:e0a:12c:3941::/64
AllowedIPs = 10.255.2.0/24
AllowedIPs = 2a01:e0a:12c:3942::/64
et ce fichier /etc/wireguard/lookout2nut.conf sur Lookout :
[Interface]
Address = 10.255.255.2
Address = 2001:bc8:3335:ff00::2
PrivateKey = <clef privée Lookout>
ListenPort = 11000
Postup = /bin/systemctl restart dnsmasq
[Peer]
PublicKey = <clef publique Nut>
Endpoint = 2001:bc8:6005:1c:208:a2ff:fe0c:686c:11000
AllowedIPs = 10.255.255.1/32
AllowedIPs = 2001:bc8:3335:ff00::1/128
AllowedIPs = 10.255.0.1/24
AllowedIPs = 2001:bc8:3335::/48
et ça marche ! Voilà iperf :
┌ (gilles@Lookout + 0) (31/01/21 - 14:45:45) (0.13 - 0%) (~)
└% iperf3 -c nut.almtesh.net
Connecting to host nut.almtesh.net, port 5201
[ 5] local 2001:bc8:3335:ff00::2 port 59920 connected to 2001:bc8:3335:: port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 25.8 MBytes 216 Mbits/sec 0 598 KBytes
[ 5] 1.00-2.00 sec 28.8 MBytes 242 Mbits/sec 0 663 KBytes
[ 5] 2.00-3.00 sec 29.3 MBytes 246 Mbits/sec 0 766 KBytes
[ 5] 3.00-4.00 sec 33.1 MBytes 278 Mbits/sec 0 887 KBytes
[ 5] 4.00-5.00 sec 35.5 MBytes 298 Mbits/sec 0 979 KBytes
[ 5] 5.00-6.00 sec 35.5 MBytes 298 Mbits/sec 0 983 KBytes
[ 5] 6.00-7.00 sec 34.9 MBytes 293 Mbits/sec 0 1.01 MBytes
[ 5] 7.00-8.00 sec 35.2 MBytes 295 Mbits/sec 0 1.06 MBytes
[ 5] 8.00-9.00 sec 36.7 MBytes 308 Mbits/sec 0 1.06 MBytes
[ 5] 9.00-10.00 sec 35.1 MBytes 294 Mbits/sec 0 1.06 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 330 MBytes 277 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 327 MBytes 274 Mbits/sec receiver
iperf Done.
┌ (gilles@Lookout + 0) (31/01/21 - 14:47:46) (0.70 - 0%) (~)
└% iperf3 -c nut.almtesh.net -R
Connecting to host nut.almtesh.net, port 5201
Reverse mode, remote host nut.almtesh.net is sending
[ 5] local 2001:bc8:3335:ff00::2 port 59924 connected to 2001:bc8:3335:: port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 24.0 MBytes 201 Mbits/sec
[ 5] 1.00-2.00 sec 21.5 MBytes 180 Mbits/sec
[ 5] 2.00-3.00 sec 20.5 MBytes 172 Mbits/sec
[ 5] 3.00-4.00 sec 20.2 MBytes 169 Mbits/sec
[ 5] 4.00-5.00 sec 21.6 MBytes 182 Mbits/sec
[ 5] 5.00-6.00 sec 24.0 MBytes 201 Mbits/sec
[ 5] 6.00-7.00 sec 20.9 MBytes 175 Mbits/sec
[ 5] 7.00-8.00 sec 23.0 MBytes 193 Mbits/sec
[ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec
[ 5] 9.00-10.00 sec 25.5 MBytes 214 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 227 MBytes 190 Mbits/sec 157 sender
[ 5] 0.00-10.00 sec 225 MBytes 189 Mbits/sec receiver
iperf Done.
┌ (gilles@Lookout + 0) (31/01/21 - 14:48:04) (1.86 - 0%) (~)
└%
Par contre, juste avant, @Clochette, la clef me semble très courte, par rapport à celles d’openVPN, c’est normal ?
C’est pas une clé rsa, cela s’appuie sur du Curve25519 les clé sont tout comme avec la génération d’une clé ed25519 via ssh-keygen bien plus courte que de la rsa 256/512 mais bien plus sûr.
Donc oui ça me surprends pas qu’elles donnent une impression d’être plus light, mais il n’en est rien
On dirait bien que les perfs sont meilleurs ^^
PS : à moins d’avoir une obligation particulière lié à du matériel ou à l’infrastructure je n’utilise plus que des clé ed25519 pour le SSH et j’évite quant c’est possible les connexions via certificat pour le ftp/ssh/vpn.
1 J'aime
Le truc c’est que wireguard a moins de choix pour le chiffrement par rapport à openvpn, ce qui rend openvpn plus difficile que wireguard à configurer sur ce point.
Quand aux meilleures performances de wireguard, c’est parce qu’il est lié au noyau (kernel).
Dans les deux cas, il n’y a pas de protection de votre intimité (privacy).
Pas grave, ce n’est pas pour aller sur Internet, c’est juste pour joindre deux réseaux qui ont accès à Internet. Je ne sais pas si c’est de ça dont tu parles…
Je pense plutôt que Zargos reproche le manque d’isolation en cas de multiple tunnel via Wireguard, mais ce n’est clairement pas le problème ici
Non aucunement, la plupart des gens croient que le fait que le tunnel est chiffré que cela rend leurs machines sécurisées ce qui n’est absolument pas le cas. Et pour la privacy (le sens anglais est un peu plus large que le mot intimité en français) il n’y a pas de protection (en clair on identifie toujours où vous êtes, etc…
Du coup je comprends pas ton retour dans le sujet, un VPN n’est pas fait pour ça.
1 J'aime
Tout simplement car « vpn » est devenu un terme générique qui mélange les différents types de vpn qui ont chacun leurs spécificités
C’était juste une précision. Car si dans un réseau LAN tu fait du VPN entre tes machines c’est qu’il y a quelque chose qui ne va pas dans la conception de l’architecture.
C’est à dire?
1 - remote access
2 - site 2 site
AH ok. 
1 J'aime
Je sais :
1 J'aime