Configure una conexión SSH directa de A a C sin IP públicas utilizando un servidor SSH público

Configure una conexión SSH directa de A a C sin IP públicas utilizando un servidor SSH público

Tengo disponibles estos servidores/clientes SSH:

A - sin IP pública

B-IP pública

C - sin IP pública

Lo sé, puedo establecer una conexión SSH de A a C de la siguiente manera:

1) Enganche C a B. Haciendo desde C:

ssh -R 10100:localhost:22 B_IP

2) Configure el reenvío de puertos de A a C usando el enlace B para poder utilizar el agente ssh en la máquina A:

ssh -L 5000:localhost:10100 B_IP

3) Ahora puedo usar mis claves ssh para acceder "directamente" a C desde A:

ssh -p 5000 localhost

... mi punto es:

¿Puedo de alguna manera establecer una nueva conexión "pura" de A a C?¿Para que después de que la máquina B se apague, pueda continuar mi trabajo?

Creo que debería ser posible siempre y cuando estas dos computadoras se den cuenta de que ya comparten una conexión, ¿o me equivoco?

Gracias por tu tiempo e ideas :)

Respuesta1

  • ElhabitualEl método consiste en configurar el "reenvío de puerto NAT" en el enrutador A o C. (La forma en que se hace depende del enrutador, pero hay instrucciones en todas partes). Una vez que lo haga, puede conectarse a la dirección pública del enrutador C + el puerto "reenviado", y la conexión se realizará a C.

    (Nota: el reenvío de puertos NAT y el reenvío de puertos SSH son similarespero distintocosas, como un martillo y un destornillador. No los confundas.)

  • Si no tiene acceso administrativo a ninguno de los enrutadores, puede intentar usar UPnP o NAT-PMP para configurar una regla de reenvío de puertos, como lo hacen muchos juegos y programas P2P. Para esto, use upnpco natpmpccomandos.

  • Si ninguno de los métodos anteriores funciona, necesitará algún tipo dePerforación NAT. (Ver también eltcpyICMPartículos para perforar agujeros.)

    Desafortunadamente, si bien se usa ampliamente en variosespecíficoprogramas, no parece haber muchosgenéricoherramientas para TCP, aunquechownatpodría funcionar.

Respuesta2

Probablemente esto sea imposible a menos que pueda realizar algún tipo de reenvío de puertos en los enrutadores, pero en este caso no necesita la computadora C en absoluto.

La cuestión es que en su ejemplo no va directamente desde A -> C, todos los paquetes todavía están atravesando B.

Si tiene otra computadora con direcciones públicas, probablemente pueda configurar una VPN en una topografía en estrella y usar el enrutamiento entre las VPN para crear una red virtual donde cualquiera de los hosts públicos pueda caer y todo pueda continuar funcionando. . He hecho esto con OpenVPN; hay algunos problemas, uno importante es deshabilitar el filtrado de ruta inversa.

Respuesta3

Una forma de hacerlo sería utilizar una VPN de igual a igual, una VPN que no requiere que uno de los hosts tenga una dirección IP estática o un nombre de dominio estático que apunte a él. Otras ideas que se mencionan a continuación no son realmente VPN, sino software que establece una conexión de igual a igual a través de algún tipo de protocolo. Aquí hay algunas opciones:

Residencia entox.chatred:

Personalmente probé ambas soluciones, pero fueron bloqueadas por la red de mi trabajo (gran estilo corporativo).

  • toxvpn- No parece muy bien mantenido a día de hoy, pero debería funcionar.
  • tuntox- Idea similar, aunque no es una VPN real, pero puede establecer una conexión y reenviar puertos ssh entre dos máquinas en la red tox. Hay ejemplos de ssh disponibles en el archivo README.
Basado en servicios de chat públicos y no gratuitos.

No he probado ninguno de estos personalmente y dudo que funcionen, pero puede que valga la pena intentarlo.

  • VPN para fiestas LAN- Basado en Discordia. No parece muy bien mantenido a día de hoy, además README no incluye muchos ejemplos, pero tal vez valga la pena comprobarlo.
  • robotitos- No parece muy bien mantenido. Además, la instalación parece difícil: usosvoz de Google(anteriormente GTalk).
VPN basadas en un servidor público (mantenido por otros)

Experiencia personal: lo intenté n2n, pero la red de mi trabajo (gran estilo corporativo) lo bloqueó.

  • n2n- utiliza un "supernodo"que es mantenido por elarribaequipo: está funcionando según n2nel archivo README de supernode.ntop.org:7777(el supernodo también es software gratuito, pero ejecutarlo requiere nuevamente un servidor de acceso público).
  • Nubela- Concepto similar como n2n, pero en lugar desupernodose llama unfaro. No ofrecen un faro público para que todos lo usen, pero en realidad debes ejecutarlo dnclienten tu VPS disponible públicamente como se explica ensus doctores. Por lo tanto, no responde a sus requisitos, pero pensé que aún así valdría la pena mencionarlo.
Otras soluciones VPN que requieren una suscripción paga.

A diferencia de la mayoría de los servicios VPN comerciales que existen, sólo unos pocos dirigidos a usuarios avanzados permitirán que dos usuarios se comuniquen entre sí a través de las subredes de VPN que obtenga. Es probable que haya otros proveedores disponibles que puedan proporcionar esta funcionalidad. Acá hay uno:

Basado en redes mantenidas por la comunidad.

Incluso detrás de una NAT intensa, si su firewall no es demasiado restrictivo (no es así en mi caso), es posible que pueda realizar cualquiera de las siguientes opciones (no VPN):

  • colina- Intentaresta guía. Básicamente, estás creando un .oniondominio (servicio Tor) al que pueden acceder los usuarios de Tor de todo el mundo.
  • i2pd- Intentaresta guíaque también tienen instrucciones para i2dpel i2pcliente que recomendaría.
Solución de último recurso

Incluso con los cortafuegos, NAT y otras restricciones de red más molestos a los que pueda estar sujeto, debería poder utilizar maravillosashttps://tmate.io/software y servicio gratuitos (como en cerveza gratis y como en libertad de expresión). Sin embargo tiene algunos inconvenientes:

  • Sin comandos interactivos (vernúmero 179).
  • Sin scpsoporte.
  • tmuxLa versión en la que se basa la bifurcación es a partir de hoy 2.6.0, mientras que la última versión actual de tmux es 3.3a; esto significa que para que ~/.tmux.conffuncione como ~/.tmate.conf, tendrá que hacer ajustes no triviales (consultepor ejemplo, de mis archivos de puntos personales).

Aunque los mantenedores de tmate no mencionan esto explícitamente, creo que los dos primeros inconvenientes mencionados son restricciones intencionales, ya que las personas pueden abusar de estas capacidades para transferir cargas de datos a través tmate.iodel servidor. Por lo tanto, esto constituye tmaterealmente una especie de "escritorio remoto" para su shell. Tendrá que encontrar otros métodos para transferir archivos entre las dos máquinas (consideresincronizando).

En conjunto, la facilidad de uso de tmate y su maravilloso rendimiento lo convierten en la mejor solución, en mi opinión. Junto consincronizandopara transferir archivos, creo que es la mejor solución y la más confiable.

información relacionada