sshuttle

[Laurent Caillette]

sshuttle est un tunnel sur IP combinant les fonctionnalités d'un VPN ("Virtual Private Network", réseau privé virtuel) avec la souplesse de mise en œuvre de SSH. 

sshuttle a "déjà été évoqué"

https://groups.google.com/d/msg/techos/Q6OLPjJw4a8/RRxTdt1fBwAJ

dans une discussion précédente. Mais depuis :

- Une nouvelle version de Tunnelblick supporte -- enfin -- l'arrêt d'urgence ("kill switch").

- Linus Torvalds a grandement accru la visibilité de WireGuard en disant que leur code n'était pas trop pourri, en tout cas beaucoup moins qu'IPsec et OpenVPN.

- J'ai installé OpenWRT sur mon routeur domestique.

Donc c'est l'occasion de se remettre à jour.

WireGuard est une solution de réseau privé virtuel qui limite la configuration en faisant tous les bons choix. Que de l'UDP, que du chiffrement dernier cri. Donc rien à voir avec OpenVPN dont l'installation est une horreur. Mais WireGuard est encore en beta et tout ne fonctionne pas idéalement. 

D'ailleurs sur OpenWRT je n'ai réussi à faire fonctionner ni OpenVPN ni WireGuard, donc je me préparais à utiliser un bon vieux proxy SOCKSv4 (``ssh -D <port-local> m...@serveur.com``) jusqu'à la fin de mes jours. Sur OpenWRT la configuration se limite à ouvrir convenablement l'accès à une zone du pare-feu.

Le proxy SOCKS on aime bien parce que ça permet de choisir l'application dont les flux HTTP seront reroutés. Et ça fait transiter des données par TCP sans le problème du double contrôle de flux. Mais il reste le problème des requêtes DNS. C'est une fonctionnalité de SOCKSv5 qui nécessite que l'application qui se connecte au serveur SOCKS supporte l'option, que je n'ai vue ni sur Chrome ni sur Firefox.

C'est là qu'intervient sshuttle. Après un ``brew install sshuttle`` sur son poste de travail on fait juste :

<<<

sshuttle --dns -r m...@serveur.com 0.0.0.0/0

>>>

sshuttle demande le mot de passe de l'administrateur pour avoir le droit d'écouter sur toutes les adresses. Puis il se connecte par SSH en tant que ``m...@serveur.com``. À l'autre bout il suffit d'avoir un compte SSH valide et un interpréteur Python. Le client sshuttle télécharge automatiquement son code sur le serveur.

sshuttle peut aussi écouter sur une plage d'adresses plus restreinte genre ``10.0.0.0/8``, et lancer plusieurs instances de sshuttle avec des paramètres différents. On peut aussi définir des exclusions.

Comme sshuttle écoute en permanence, il n'y a pas besoin d'arrêt d'urgence ("kill switch"). Mais ce n'est pas si rose. Comme sshuttle ne démarre pas s'il ne peut pas se connecter, on est obligé d'activer le Wi-Fi avant, donc de laisser fuiter du trafic pendant quelques secondes. Un bon client VPN devrait éviter ça.

sshuttle fait transiter le trafic dans du TCP mais ce n'est pas une encapsulation des paquets TCP, ce sont juste les données, donc on n'a pas le problème du double contrôle de flux des tunnels TCP (c'est pour ça qu'OpenVPN conseille l'UDP). Le coup d'écouter sur toutes les adresses est juste génial et je ne savais pas qu'on pouvait faire ça. Oui ça fonctionne aussi pour IPv6. Une autre astuce notable -- déjà popularisée par Ansible -- c'est de pousser les scripts côté serveur au moment de l'exécution pour sauter la case installation. SSH, c'est la solution de déploiement ultime.

Comme le disaient Kernie et Henri à propos de SSH, sshuttle ne remplace pas un VPN, surtout quand on veut se téléporter au milieu d'un réseau distant. Mais si on veut juste un tunnel pour faire passer du trafic par un réseau non-sûr, y compris et notamment les requêtes DNS, et qu'on souhaite tendre vers zéro configuration, alors en attendant WireGuard on trouvera sûrement son bonheur avec sshuttle.

[Laurent Caillette]

Après quelques jours d'usage itinérant de sshuttle je découvre que l'arrêt d'urgence ne fonctionne pas du tout. Si la connexion Wi-Fi tombe après une mise en veille par exemple, sshuttle finit par se déconnecter. Les applications qui se reconnectent utilisent alors une connection non-tunnelisée. Redémarrer sshuttle ne suffit pas si entre temps des applications ont établi des connexions non-tunnelisées. Bref si on veut rendre son trafic parfaitement étanche, sshuttle n'est pas suffisant.

WireGuard a l'air de supporter l'arrêt d'urgence grâce à une action ``PreDown`` dans la déclaration des interfaces. Ça semble primitif mais il faut lire la présentation de WireGuard qui insiste sur l'intégration avec les outils standards d'Unix. Après il y a toujours moyen d'automatiser les opérations.

C'est terrible, on est en 2018 et on voit à peine se profiler une solution de tunnel décente. C'est sûrement ce que voulait dire Steve Jobs avec sa quasi-phrase d'adieu : "Le meilleur reste à venir". Façon optimiste de constater qu'il reste un paquet de trucs à réparer.