Dele a un Pi remoto un proxy SOCKS a través de su cliente SSH

Un reenvío dinámico remoto coloca el oyente SOCKS en el Pi y realiza la conexión posterior desde la ruta VPN aprobada de su portátil. Sin un segundo servidor SSH.

Usted da por hecho que un proxy SOCKS tiene que ejecutarse donde ya existe el acceso a la red. OpenSSH puede colocar el oyente en un lugar completamente distinto. Un reenvío dinámico remoto abre el puerto SOCKS en un host remoto y origina cada conexión desde su cliente SSH local, que transporta la ruta VPN aprobada de su portátil. El Pi obtiene un proxy acotado; no hereda su túnel ni sus privilegios.

El oyente y el lado del que nace la conexión pueden ser distintos

Un ssh -D 1080 normal ejecuta el oyente en su propia máquina y envía las conexiones desde allí. Un reenvío dinámico remoto invierte eso: el oyente aparece en el host remoto y cada conexión que acepta se abre desde el lado local. El manual del cliente OpenSSH documenta -R sin un destino fijo exactamente como esta disposición SOCKS4/5.

Un comando admitido desde el portátil tiene este aspecto, con la cuenta, los hosts y el puerto tratados como marcadores:

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

Tres detalles hacen trabajo útil ahí. -S none mantiene la sesión lejos de un maestro de control compartido, ExitOnForwardFailure falla rápido en lugar de dejarle con una sesión a medio abrir, y PermitRemoteOpen limita hasta dónde puede llegar el oyente remoto. Use una cuenta de Pi autorizada y verifique la clave del host antes de añadir nada de esto.

Qué expone realmente el oyente remoto

Compruebe la política de reenvío del servidor antes de confiar en el oyente. Con GatewayPorts no el reenvío remoto queda ligado a loopback, que es la exposición que usted quiere. Un servidor configurado para forzar reenvío comodín publica el mismo puerto en cada interfaz, lo que convierte un proxy personal en algo que la red local puede alcanzar.

Loopback tampoco es una frontera por usuario. Otro proceso del Pi puede conectarse a 127.0.0.1:1080 si conoce el puerto, así que las cuentas locales del Pi y todo lo que se ejecuta en él forman parte de su diseño de acceso. Eso es un motivo para mantener estrecha la lista de destinos, no un motivo para saltarse la comprobación de la política.

Mantenga el destino permitido específico para la aplicación que intenta alcanzar. Sustituirlo por un reenvío sin restricciones para que funcione un programa ajeno amplía el camino mucho más allá del problema con el que empezó. La lista de destinos también registra para qué servía la sesión, lo que ayuda a quien la audite después. Anótela junto a la cuenta que utilizó.

Envíe una aplicación a través del proxy

Un cliente del Pi que entiende de proxy puede entonces hacer la petición. El prefijo socks5h entrega el nombre de destino al proxy, así que la consulta y la conexión ocurren ambas en el lado del portátil, y coincide con el destino nombrado en PermitRemoteOpen:

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

Conserve la validación normal de certificados y la autenticación propia de la aplicación. El proxy cambia dónde se establece la conexión TCP; no hace seguro un servicio sin autenticación ni convierte un extremo autofirmado en uno de confianza.

El portátil sigue necesitando su propia ruta y acceso al resolutor tanto al servidor SSH como a la aplicación. El tráfico de su cliente SSH tiene que ser seleccionado por la política VPN aprobada, y una exclusión de túnel dividido puede enviar ese tráfico por un camino distinto del que usted probó.

Demuestre el camino y ciérrelo

Confirme que el oyente existe donde lo espera y que solo responde el destino previsto:

$ 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 puede demostrar que el reenvío se estableció, y aun así no puede certificar que el inicio de sesión en la aplicación tenga éxito aguas abajo. Pruebe la aplicación, no solo el puerto. Un oyente que acepta y luego falla en cada petición suele significar que el nombre de destino o la ruta del portátil son incorrectos, no que el túnel haya fallado.

Esta disposición solo transporta TCP. UDP, ICMP y los programas que ignoran la configuración de proxy quedan fuera, y el reenvío termina en el momento en que termina la sesión SSH. Detenga esa sesión cuando haya terminado y quite la configuración de proxy que añadió a la aplicación.

Para un acceso permanente, use en su lugar el alta compatible del propietario de la red o una pasarela gestionada. Un proxy inverso es la herramienta equivocada para eludir las restricciones de dispositivo o de recursos de una VPN; usado dentro de ellas, es simplemente una ruta de aplicación autorizada con límites explícitos.

Artículos relacionados