¿Cuál es la diferencia entre el reenvío de IP local y remoto?

10

¿Cuál es la diferencia en funcionalidad entre los dos? Estoy un poco confundido por eso.

El reenvío local hace que un puerto remoto esté disponible localmente.

El reenvío remoto hace que un puerto local esté disponible de forma remota.

Pero esta 'disponibilidad' funcionará en ambas direcciones ... ¿o no?

Por ejemplo, el siguiente (emitido desde un host 'hogar')

ssh -R 1234:localhost:2345 user@work

Esto establecerá un túnel seguro entre el trabajo :: 1234 y el hogar :: 2345, ¿verdad?

Si pongo algo en un extremo, saldrá en el otro extremo.

Pero entonces, puedo lograr lo mismo con la siguiente llamada del host 'trabajo':

ssh -L 1234:localhost:2345 user@home

Entonces, la única diferencia es desde dónde lo llamo, ¿correcto?

ssh ssh-tunnel

— nandaloo
fuente

En su ejemplo, no hay diferencia en la funcionalidad. Se autocompensa por usar el argumento opuesto intercambiando hosts de destino. Si no hubieras hecho esto y los hubieras usado desde un solo host, ya provocaría un comportamiento completamente opuesto.

— XXL

2

La principal diferencia práctica es que si conecta 2 computadoras A y B, y B está detrás de un firewall o enrutador NAT que no controla, y está bloqueando la entrada. Está sentado en A. No puede obtener A para conectarse a B. Pero B no bloqueará el saliente. Entonces, obtendrá B para conectarse a A.

--aclaración añadida--

Lo anterior, que el interrogador entendió ... significa la principal diferencia práctica entre el reenvío local y remoto. ssh -L y ssh -R cuando usarías cada uno. No estaba comentando sobre los comandos de ejemplo específicos que dio, dónde cambia -L y -R, y a qué servidor sshd se conecta. Pero ahora intentaré comentarlo ... Con los comandos ssh que dio, desde la perspectiva del cliente regular y el servidor regular, parece que no hay diferencia, ya que no dice "ah, este es un cliente ssh y este es un servidor ssh ... "no conoce ssh, y cuál es el aspecto cliente / servidor de ssh es irrelevante y desconocido para el cliente regular y el servidor regular también. Solo les importa quién está escuchando, y desde su perspectiva, se ve igual. La computadora del trabajo está escuchando y en 1234. Ellos no t observe que en un caso es un servidor sshd.exe ssh, y en el otro caso es un cliente ssh.exe, ssh. Por cierto, donde está el cliente ssh, se considera local.

— barlop
fuente

ok, gracias, eso respondió exactamente mi pregunta! :-)

— nandaloo

@nandaloo Creo que se llama un túnel ssh inverso. Si usamos términos inventados iniciador y oyente (porque esos términos son menos ambiguos que cliente y servidor). La idea es que tenga su iniciador y oyente regulares y su iniciador y oyente ssh. No puedes elegir dónde están tu iniciador y oyente habitual. por ejemplo, el servidor HTTP (escucha regular) está en B. B está detrás de un firewall. A tiene el cliente HTTP (iniciador regular). Pones tu iniciador SSH en B. Mira con un túnel inverso que el iniciador SSH y el oyente están en computadoras opuestas al iniciador y oyente regular.

— barlop

10

Sí, si lo entiendo correctamente, el reenvío de puerto local de a a b debe ser idéntico al reenvío de puerto remoto de b a a (y viceversa). Un túnel saliente de a a b (visto desde a) debe ser igual a un túnel entrante de a a b (visto desde b).

El reenvío de puertos locales crea un túnel saliente que puede usarse para llevar una computadora pública de Internet a la máquina local. Un usuario local puede acceder a una combinación de host remoto: puerto en un host local, porque el puerto dado en el host local (cliente) se reenvía al host y puerto dados en el lado remoto:

ssh -L local_port:remote_host:remote_port user@hostname

El reenvío de puerto remoto crea un túnel entrante que se puede utilizar para llevar una computadora local a Internet público. Un usuario de Internet puede acceder a un determinado host local: combinación de puertos en un host remoto. El puerto dado en el host remoto (servidor) se reenvía al host y al puerto dados en el lado local:

ssh -R local_port:remote_host:remote_port user@hostname

— 0x4a6f4672
fuente

1

Supongo que otra diferencia, además de la sintaxis, sería el proceso que escucha para que el usuario se conecte. ssh.exe -L le dice a ssh.exe que escuche (además de la conexión saliente que ya está haciendo). ssh.exe -R le dice a sshd.exe que escuche (además de la escucha que ya está haciendo).

— barlop

@ 0x4a6f4672, ¿Qué 0x4a6f4672significa?

— Pacerier

@Pacerier solo mis iniciales "JoFr" en notación hexadecimal :-)

— 0x4a6f4672

3

Con el reenvío de puerto local, usted (el cliente) abre un socket de escucha en su computadora y conecta su cliente de protocolo de nivel de aplicación a este socket. Ahora la conexión se reenvía a través de SSH al servidor. El servidor se conecta al host remoto y canaliza los datos desde su cliente de protocolo hasta el destino final.

Con el reenvío de puertos remotos, el servidor abre un socket de escucha en el host del servidor. Algunas aplicaciones remotas se conectan a este host y envían información que se transfiere a su computadora cliente. Aquí se establece la conexión con el destino final (algunos servidores de protocolo de nivel de aplicación que se ejecutan en su computadora o en su red) y los datos se transfieren desde la aplicación remota al destino final.

— Devolución de llamada de Eugene Mayevski
fuente

gracias, eso dejó más claro cómo funciona el reenvío de puertos. Y gracias por mover la pregunta. Simplemente no sabía nada sobre este sitio de superusuario :-)

— nandaloo

1

Esto se entiende mejor con pequeños ejemplos. En estos ejemplos, las conexiones se estructuran así:

Servidor local - (LAN) - Terminal ----- (SSH, generalmente a través de Internet) ----- Punto final del túnel - (LAN) - Máquina remota

Utiliza el reenvío de puerto local si quieres hacer un túnel a una determinada máquina / puerto remoto, al que puedes acceder desde el punto final del túnel al que tienes acceso ssh. Therby, el puerto de esa máquina remota también es accesible localmente en su propio terminal, es decir, http: // localhost: terminal_port /.

Eso se hace usando la siguiente sintaxis:

ssh -L terminal_port:remote_machine_ip:remote_service_port -p tunnel_endpoint_ssh_port ssh-login@tunnel_endpoint_ip

Puede usar el reenvío de puertos remotos si desea habilitar CUALQUIERA (!) Control remoto, que pueda alcanzar el puerto de escucha del punto final del túnel para poder acceder de forma remota a una ip / puerto en su LAN local. Para su servidor local, parece que la conexión desde la máquina remota es iniciada por el terminal.

La sintaxis es:

ssh -R tunnel_endpoint_listen_port:local_server_ip:local_server_port -p tunnel_endpoint_ssh_port ssh-login@tunnel_endpoint_ip

— NStoeckm
fuente

0

La página de manual de socat lo aclara muy bien. Sí, sé que ssh y socat son dos cosas completamente diferentes, pero la documentación de socat es muy buena.

— user400344
fuente