Redirection locale SSH vers un proxy HTTP existant : deux adresses de loopback

Votre proxy approuvé tourne sur un hôte de rebond où il n’écoute que sur loopback, donc rien en dehors de cette machine ne peut l’atteindre. Vous n’avez pas besoin d’un VPN ni d’un nouveau proxy ; il vous faut un port de cette machine transporté vers un port de la vôtre. Une redirection locale fait exactement cela, et elle demande une commande plus un réglage d’application. La confusion vient généralement de ce qu’on mélange quelle adresse de loopback appartient à quelle machine.

Déterminez si un proxy fixe existe déjà

Cette technique redirige un service qui tourne déjà. Si l’hôte distant n’a qu’un démon SSH et aucun proxy, aucune quantité de redirection n’en créera un, et la connexion sera refusée depuis le côté distant. Vérifiez que le proxy est lié, quel est son port, et s’il écoute sur 127.0.0.1 ou sur une adresse d’interface précise, car c’est cette adresse que la redirection doit viser.

Vérifier cela d’abord vous évite de déboguer un tunnel qui n’a jamais été relié à quoi que ce soit.

Construisez la redirection et lisez la commande

La forme voulue lie un port de loopback sur votre portable et le connecte, côté serveur, à l’adresse du proxy telle que le serveur la voit.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N supprime une commande distante et -T supprime l’allocation de termios, car vous voulez un tunnel et non un shell. La première adresse de loopback est celle où le portable écoute ; la seconde est résolue par le serveur SSH, donc 127.0.0.1 y désigne le proxy de cette machine. ExitOnForwardFailure fait échouer bruyamment la commande si le port local est déjà pris, au lieu de démarrer une session qui ne redirige rien. Écrivez l’adresse cible telle que le serveur la résout, car un nom que seul votre portable peut résoudre échouera de l’autre côté.

La politique du serveur lui-même s’applique avant que tout cela fonctionne. AllowTcpForwarding doit l’autoriser, et PermitOpen peut restreindre les destinations et les ports qu’une session peut atteindre, donc une redirection que le client accepte peut encore être refusée par le serveur. Le refus apparaît comme une erreur de redirection ou de canal côté client, et lire ce message est plus rapide que modifier la commande.

Pointez une application vers la redirection

Configurez l’application pour utiliser un proxy HTTP à http://127.0.0.1:13128, avec des identifiants si le proxy distant les exige. Conservez la vérification des certificats propre à l’application pour les destinations HTTPS, car le tunnel du proxy ne la remplace pas. Il s’agit d’une redirection fixe d’un service, donc l’application doit être informée d’un proxy plutôt que laissée à le découvrir.

Une vérification rapide avant toute configuration permanente : curl -x http://127.0.0.1:13128 -I https://example.com, qui exerce la méthode HTTP CONNECT que le proxy doit prendre en charge.

Gardez l’autorité là où elle était

Le proxy distant décide toujours des destinations et des méthodes qu’il autorise, et une connexion SSH ne devrait pas accorder silencieusement un relais web général à chaque compte. La liaison à 127.0.0.1 sur le portable évite de publier le port sur votre réseau local, et elle ne rend pas le port privé vis-à-vis d’autres processus de la même machine. Remplacer cette liaison par une adresse wildcard pour partager le proxy, c’est ainsi que naît un relais ouvert non géré.

Le transport SSH protège le saut jusqu’au serveur. Au-delà de ce point, le proxy ouvre sa propre connexion, donc une requête HTTP simple vers une destination reste simple au-delà du serveur, même si le premier segment était chiffré.

Vérifiez les deux extrémités, puis nettoyez

La mise en place du tunnel local et le succès du service distant sont deux résultats différents, et le code de sortie de la commande ne vous parle que du premier. Vérifiez que l’écouteur existe avec ss -ltn, puis faites une requête autorisée de l’application et une requête que le proxy devrait refuser. Si les deux se comportent comme prévu, le chemin est réel ; si le tunnel est actif et que chaque requête échoue, le proxy refuse ou n’atteint pas la destination.

Quand vous avez terminé, arrêtez le processus SSH propriétaire, retirez le réglage de proxy de l’application et confirmez que le port local a disparu au lieu de laisser un écouteur qui survive à la tâche.