Donnez à un Pi distant un proxy SOCKS via votre client SSH

Un transfert dynamique distant place l’écouteur SOCKS sur le Pi et établit la connexion suivante depuis le chemin VPN approuvé de votre ordinateur portable. Pas de second serveur SSH.

Vous supposez qu’un proxy SOCKS doit tourner là où l’accès réseau existe déjà. OpenSSH peut placer l’écouteur tout à fait ailleurs. Un transfert dynamique distant ouvre le port SOCKS sur un hôte distant et fait naître chaque connexion depuis votre client SSH local, qui porte le chemin VPN approuvé de votre ordinateur portable. Le Pi obtient un proxy limité ; il n’hérite ni de votre tunnel ni de vos privilèges.

L’écouteur et le côté d’où part la connexion peuvent différer

Un ssh -D 1080 ordinaire exécute l’écouteur sur votre propre machine et envoie les connexions depuis là. Un transfert dynamique distant inverse cela : l’écouteur apparaît sur l’hôte distant et chaque connexion qu’il accepte est ouverte depuis le côté local. Le manuel du client OpenSSH documente -R sans destination fixe exactement comme cet arrangement SOCKS4/5.

Une commande prise en charge depuis l’ordinateur portable ressemble à ceci, le compte, les hôtes et le port étant traités comme des espaces réservés :

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Trois détails y font un travail utile. -S none garde la session à l’écart d’un maître de contrôle partagé, ExitOnForwardFailure échoue vite au lieu de vous laisser avec une session à moitié ouverte, et PermitRemoteOpen limite ce que l’écouteur distant peut atteindre. Utilisez un compte Pi autorisé et vérifiez la clé de l’hôte avant d’ajouter quoi que ce soit de tout cela.

Ce que l’écouteur distant expose vraiment

Vérifiez la politique de transfert du serveur avant de compter sur l’écouteur. Avec GatewayPorts no, le transfert distant reste lié à loopback, ce qui est l’exposition que vous voulez. Un serveur configuré pour forcer un transfert générique publie le même port sur chaque interface, ce qui transforme un proxy personnel en quelque chose que le réseau local peut atteindre.

Loopback n’est pas non plus une frontière par utilisateur. Un autre processus sur le Pi peut se connecter à 127.0.0.1:1080 s’il connaît le port, donc les comptes locaux du Pi et tout ce qui y tourne font partie de votre conception d’accès. C’est une raison de garder la liste de destinations étroite, pas une raison de sauter le contrôle de politique.

Gardez la destination autorisée propre à l’application que vous cherchez à atteindre. La remplacer par un transfert sans restriction pour faire fonctionner un programme sans rapport élargit le chemin bien au-delà du problème de départ. Une liste de destinations consigne aussi à quoi servait la session, ce qui aide quiconque l’auditera plus tard. Notez-la à côté du compte utilisé.

Faites passer une application par le proxy

Un client conscient du proxy sur le Pi peut alors faire la requête. Le préfixe socks5h remet le nom de destination au proxy, si bien que la résolution et la connexion ont lieu toutes deux côté ordinateur portable, et il correspond à la destination nommée dans PermitRemoteOpen :

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

Conservez la validation normale des certificats et l’authentification propre à l’application. Le proxy change l’endroit où la connexion TCP est établie ; il ne rend pas sûr un service sans authentification et ne transforme pas un point de terminaison auto-signé en point de confiance.

L’ordinateur portable a toujours besoin de sa propre route et d’un accès au résolveur vers le serveur SSH comme vers l’application. Le trafic de son client SSH doit être sélectionné par la politique VPN approuvée, et une exclusion de tunnel partagé peut l’envoyer par un chemin différent de celui que vous avez testé.

Prouvez le chemin et refermez-le

Confirmez que l’écouteur existe là où vous l’attendez et que seule la destination prévue répond :

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure peut prouver que le transfert a été établi, et il ne peut toujours pas certifier que la connexion à l’application réussit en aval. Testez l’application, pas seulement le port. Un écouteur qui accepte puis fait échouer chaque requête signifie généralement que le nom de destination ou la route de l’ordinateur portable est faux, pas que le tunnel a échoué.

Cet arrangement ne transporte que TCP. UDP, ICMP et les programmes qui ignorent les réglages de proxy restent en dehors, et le transfert se termine à l’instant où la session SSH se termine. Arrêtez cette session quand vous avez fini et retirez le réglage de proxy que vous avez ajouté à l’application.

Pour un accès permanent, utilisez plutôt l’enrôlement pris en charge par le propriétaire du réseau ou une passerelle gérée. Un proxy inverse est le mauvais outil pour contourner les restrictions d’appareil ou de ressources d’un VPN ; utilisé à l’intérieur de celles-ci, il n’est qu’un chemin applicatif autorisé aux limites explicites.

Articles similaires