sshuttle face à un VPN complet : ce que sa méthode couvre vraiment
sshuttle ne transporte que ce que sa méthode de transfert prend en charge : vérifiez d'abord la couverture TCP, DNS et UDP, le privilège local requis et l'assistant distant.
sshuttle est choisi parce que SSH fonctionne déjà et que la cryptographie semble familière, et ce raisonnement saute la seule question qui décide de l'adéquation. Quels paquets quittent la machine, quel compte les transporte de l'autre côté et combien de privilèges locaux l'outil exige. Ces trois réponses varient selon la méthode de transfert, donc une configuration qui marche pour une application peut échouer en silence pour la suivante. Le parcours ci-dessous part du protocole dont l'application a réellement besoin.
Partez du protocole dont l'application a besoin
La prise en charge des protocoles dans sshuttle 2.0 dépend de la méthode que vous choisissez. Les méthodes NAT et nft de Linux traitent TCP et DNS, et TPROXY ajoute UDP général. Chaque plateforme et chaque méthode apportent leurs propres limites, et macOS intercepte par un mécanisme entièrement différent. Notez la version installée, la méthode retenue et les protocoles dont l'application a besoin avant de choisir quoi que ce soit.
Une requête TCP qui fonctionne prouve donc très peu de choses sur une application UDP ou sur chaque requête DNS. sshuttle traite aussi TCP comme des flux au lieu de tunneliser des paquets IP entiers, si bien qu'une conclusion de débit empruntée à un VPN classique ne se transpose pas. Comparez le mécanisme que vous exécutez réellement à la charge que vous avez réellement.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
Ce dont le client a besoin localement
La disposition client documentée exige root ou sudo, car elle installe des règles d'interception locales au lieu de créer une interface de tunnel. Ce seul fait change l'histoire de la sécurité : un processus disposant de ce privilège peut rediriger le trafic de toute la machine, pas seulement celui d'une application. Traitez le privilège comme une partie de la conception et non comme un détail d'installation.
Vérifiez quelles règles l'outil a installées et qu'elles disparaissent à sa sortie. Une session qui plante en laissant des règles d'interception peut envoyer le trafic dans un trou noir longtemps après que l'opérateur croit la connexion partie, et le symptôme ressemble à une panne réseau plutôt qu'à une règle oubliée.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeLa première commande donne la forme d'un appel typique, avec le préfixe qu'il vous faut réellement. La deuxième montre ce que l'outil a installé, et la troisième confirme qu'aucune interface de tunnel n'est apparue, ce qui est le résultat attendu pour cette conception.
Ce que le côté distant exécute
Le côté distant est un compte SSH autorisé plus un environnement d'assistant Python compatible. Une connexion qui réussit sous un shell restreint n'accorde pas automatiquement le droit d'exécuter cet assistant, et un compte capable d'exécuter l'assistant n'atteint pas automatiquement chaque service cible. Ces deux faits relèvent de la demande d'accès et non des notes de dépannage.
Protégez la vérification de l'identité de l'hôte et l'authentification du compte. Accepter une clé d'hôte inconnue pour faire fonctionner la première connexion supprime le contrôle que le côté distant est bien la machine voulue, et cela compte ici plus que dans un transfert à usage unique.
Limitez le compte distant aux services dont le flux de travail a besoin et négociez ce périmètre avec ceux qui exploitent l'hôte. Ils font partie de la relation de confiance, et aucun réglage côté client ne change cela.
Où se situe la frontière de confiance
Transférer une connexion API privée par SSH n'autorise pas chaque opération API. Le TLS de l'application et la connexion à l'application s'appliquent toujours, et l'outil ne peut pas rendre sûr un service sans authentification. Un saut supplémentaire depuis l'hôte distant n'est pas non plus automatiquement le même segment protégé que le canal SSH, car cette seconde connexion suit la politique que l'hôte distant applique.
Écrivez la frontière en une phrase : le trafic vers ces préfixes sort par ce compte sur cet hôte. Si la phrase exige un paragraphe d'exceptions, la conception fait plus que ce que sa documentation prétend et mérite un second regard avant d'atteindre la production.
Prouvez-le protocole par protocole, puis choisissez l'outil
Testez chaque protocole requis avec une requête inoffensive, y compris le chemin du résolveur et les familles d'adresses que l'application utilise. Incluez une déconnexion dans le test, afin que le comportement d'échec autorisé de l'application devienne un résultat connu plutôt qu'une surprise pendant un incident. Une session qui transférait correctement tant qu'elle tournait ne dit rien de ce qui se passe quand elle tombe.
Pour une poignée de services nommés explicitement, un transfert local ordinaire est plus facile à posséder et à auditer. Pour le trafic applicatif qui correspond à sa méthode, sshuttle offre un juste milieu légitime. Quand l'exigence est une connectivité IP large, une conception VPN est la réponse honnête, et le choix suit la couverture et la responsabilité opérationnelle plutôt qu'un classement d'algorithmes de chiffrement.