VPN par SSH

Bonjour,

J’avais configuré un VPN avec openVPN, mais c’est assez lent à cause du chiffrement.


Du coup, ce que j’ai fait, c’est que j’ai viré le chiffrement espérant avoir un débit plus élevé, ça a été le cas, mais on passe de 20-30 Mbits/s à 60-70 Mbits/s, c’est pas fifou et en plus le traffic n’est plus chiffré ni authentifié.
Je viens de tester le débit via un tunnel SSH et j’ai un débit mesuré de 170 Mbits/s, SSH avec chiffrement. J’envisage donc sérieusement de changer de VPN, de passer de openVPN à SSH.

Pour ce faire, j’ai remarqué l’option -w de ssh :

     -w local_tun[:remote_tun]
             Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server (remote_tun).

             The devices may be specified by numerical ID or the keyword “any”, which uses the next available tunnel device.  If remote_tun is not specified, it defaults to “any”.  See also the Tunnel and TunnelDevice directives in ssh_config(5).

             If the Tunnel directive is unset, it will be set to the default tunnel mode, which is “point-to-point”.  If a different Tunnel forwarding mode it desired, then it should be specified before -w.

mais je ne trouve pas comment mettre en œuvre ça.

Pour info, un machine est sous Debian 10 et l’autre est sous Raspbian 10, les deux sont joignables directement sur Internet, peu importe qui sera le client et qui sera le serveur.

Pour info, encapsuler du trafic VPN dans TCP n’est pas une bonne idée.

Oui, je le sais ça, parce que ça fait deux couches de TCP qui gèrent les retransmissions de la même façon en même temps, mais ce n’est pas la question de savoir si c’est une bonne idée, je veux retrouver le chiffrement et avoir un débit plus élevé. D’après mes mesures, openSSH est mieux que openVPN.

As-tu essayer de monter un VPN avec Wireguard ? voir aussi du côté de Tinc …

En fait la bonne question est plutôt de savoir quel traffic tu fais passer dans ton lien virtuel.
openSSH et openVPN n’ont pas la même finalité. Ce n’est pas les mêmes fonction.
openVPN créé un réseau virtuel privé, openSSH créé un shell chiffré.

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 :wink: :

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 :wink:

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 :wink:

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 :wink:

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