Redirection dynamique SSH comme proxy SOCKS par-dessus votre VPN

Une application qui ne parle que SOCKS n’a rien à qui parler sur un VPN ordinaire, parce que le tunnel transporte des paquets et que l’application veut un point de sortie proxy. OpenSSH peut fournir ce point lorsque le propriétaire de l’accès l’autorise, car la redirection dynamique transforme une session SSH en proxy local. Ensuite, il y a deux sauts à garder distincts : le tunnel qui atteint l’hôte SSH, et la connexion que cet hôte ouvre ensuite. Les séparer explique à la fois pourquoi ce montage fonctionne et ce qu’il ne fera jamais.

Ce que l’écouteur SSH devient et ce qu’il ne devient pas

La redirection dynamique fait écouter le client SSH localement et parler SOCKS4 ou SOCKS5 à tout ce qui se connecte. Chaque requête nomme une destination et le serveur SSH ouvre la connexion suivante, ce qui explique que la résolution de la destination puisse se faire de l’autre côté. C’est du transfert TCP au niveau applicatif, pas un VPN pour tout l’appareil. Il ne transporte ni association UDP, ni ICMP, ni rien pour les applications qui ignorent complètement les réglages de proxy. Le saut du serveur SSH vers l’application n’est pas non plus dans votre tunnel, ce qui compte lorsque la destination n’accepte du trafic que depuis des réseaux connus.

Les prérequis sont réels : une route vers l’hôte SSH, un compte autorisé, une clé d’hôte de serveur vérifiée et l’autorisation de rediriger. Aucun n’est créé par le proxy, et le dernier est généralement le premier à manquer. Vérifiez les quatre avant de déboguer quoi que ce soit d’autre, car l’échec se présente de la même façon côté client, quel que soit celui qui manque.

Lancez-le sur loopback avec un port explicite

Choisissez un port local inutilisé et liez-le explicitement à loopback plutôt que d’omettre l’adresse. Les trois options ci-dessous existent chacune pour une raison.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N saute la commande distante et -T saute le pseudo-terminal, si bien que la session n’existe que pour rediriger. ExitOnForwardFailure fait quitter le client lorsque l’écouteur ne peut pas être créé, au lieu de tourner sans la redirection demandée. ControlPath=none garde la session hors d’une connexion multiplexée existante qui pourrait ajouter ses propres redirections. Loopback garde l’écouteur hors du LAN, mais sur une machine partagée ce n’est pas une frontière d’autorisation, car d’autres processus locaux peuvent aussi l’atteindre. La référence du client OpenSSH documente toutes ces options, et l’avertissement sur loopback découle de ce qu’est une socket en écoute.

Faites passer les noms par le proxy, pas à côté

Un client SOCKS5 peut résoudre la destination lui-même ou demander au proxy de le faire, et ce choix décide quel résolveur répond. Avec socks5h, curl envoie le nom d’hôte à travers le proxy, donc la résolution se fait sur le serveur SSH. Avec socks5 simple, l’ordinateur portable résout d’abord et seule la connexion voyage, ce qui annule discrètement l’intérêt quand le nom est interne. La requête ci-dessous vide aussi la liste sans proxy, afin qu’une valeur NO_PROXY héritée ne puisse pas la détourner du proxy.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

La validation du certificat et la connexion propre à l’application s’appliquent toujours, car le proxy ne remplace ni l’une ni l’autre. Deux résolutions restent : l’ordinateur portable doit atteindre l’hôte SSH par le chemin VPN et DNS autorisé, et le serveur SSH doit résoudre lui-même le nom de l’application. La seconde se teste seule avant que le moindre trafic ne passe par le proxy.

ssh [email protected] getent hosts app.corp.example

Prouvez une destination autorisée, puis fermez la session

Testez une destination que la politique autorise et une qu’elle devrait refuser, car une redirection qui fonctionne prouve seulement que l’écouteur fonctionne, et rien de plus. L’application voit l’adresse source que le serveur SSH choisit, et ce n’est pas l’adresse de tunnel de votre ordinateur portable. Là où l’extrémité distante journalise les connexions par source, cette différence est la première chose à vérifier quand une requête est refusée.

Arrêtez la session par le processus qui la possède plutôt qu’en tuant un shell sans rapport. Confirmez ensuite que l’écouteur a disparu, car un port qui répond encore est une session que vous n’avez pas vraiment fermée. Retirez uniquement le réglage de proxy introduit par cet exercice, et laissez le reste de la configuration de l’application tranquille. Un terminal sans surveillance qui détient une règle de redirection n’est pas un service, et un proxy permanent exige un cycle de vie approuvé, pas une fenêtre oubliée.

ss -ltn | grep 1080

Pannes que ce montage ne peut pas corriger

Certains symptômes pointent droit vers les limites ci-dessus, et les reconnaître tôt épargne un après-midi de débogage du proxy. Le tableau associe ce que vous observez à ce que cela signifie généralement. Tout ce qui figure dans la dernière colonne est une question de conception, pas une erreur de configuration.

Les trois premières lignes sont celles que les gens diagnostiquent mal, car chacune produit une tentative de connexion plutôt qu’une erreur sur le proxy lui-même. Un nom qui se résout sur l’ordinateur portable ne dit rien du résolveur du serveur, et l’échec se lit à la place comme un problème de certificat ou de délai. Les applications uniquement UDP restent hors du montage, pas cassées à l’intérieur, et aucune option ssh supplémentaire n’y change rien. La ligne du navigateur est le rappel habituel que les réglages de proxy valent par application. La dernière ligne est la raison d’être du contrôle de fermeture : un port qui écoute encore signifie que quelque chose d’autre le possède désormais.