Atteindre un proxy HTTP ou SOCKS existant via SSH
Atteignez un proxy HTTP ou SOCKS loopback distant via SSH sans exposer publiquement son écouteur.
Si relay.example.net exécute déjà SOCKS sur son propre 127.0.0.1:1080, transmettez l'accès plutôt que d'exposer publiquement cet écouteur :
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Point de terminaison | Rôle |
|---|---|
Ordinateur portable 127.0.0.1:1081 | L'adresse SOCKS à configurer dans l'application de l'ordinateur portable. |
Relais 127.0.0.1:1080 | Le proxy existant atteint depuis le côté serveur SSH. |
La syntaxe de redirection locale attribue la destination fixe au côté serveur. Un proxy HTTP sur le port loopback distant 3128 ou un point de terminaison intranet comme proxy.internal.example:8080 fonctionne selon le même principe. Configurez le client pour ce protocole HTTP existant et le compte ; le transport via SSH ne crée pas de SOCKS ni d'écouteur HTTPS activé par TLS.
Le service existant choisit toujours les versions de protocole prises en charge, l'authentification, les destinations et la sortie finale. Si un autre processus SSH a créé ce proxy distant, les deux processus doivent rester actifs. Un itinéraire portable→relais→passerelle laisse le site web voir la dernière connexion sortante, et non une identité attribuée par le port local 1081.
Gardez la liaison du portable explicitement locale. Une exposition plus large change qui peut atteindre le service, et la connexion SSH n'ajoute pas de mot de passe SOCKS à l'écouteur. En cas de refus, vérifiez l'écouteur du portable, le transport SSH et le proxy distant comme des étapes distinctes.