tunnel
1.0.0
Reenviador de puertos TCP/UDP multiplexado y seguro que utiliza el servidor de tuberías de @nwtgck como retransmisión. Diseñado principalmente para conexiones p2p entre pares detrás de (múltiples) NAT/firewalls.
Para el caso especial de IPFS , consulte #ejemplos a continuación.
ID: cada nodo recibe un ID único (base64).
tunnel -iLa ID está vinculada al hardware (dirección MAC) y a las variables de entorno USUARIO, INICIO y HOSTNAME. Compártelo con tus compañeros de una vez por todas. Nota: dos usuarios en la misma máquina reciben ID de nodo separados porque sus variables USUARIO y INICIO difieren.
Modo servidor: exponga su puerto local a pares con quienes comparte cualquier cadena secreta.
tunnel [options] [-u] [-k < shared-secret > ] < local-port >Modo cliente: reenvíe su puerto local al puerto local expuesto del par.
tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port > Si no se proporciona ningún puerto local usando la opción -b , tunnel usa un puerto aleatorio no utilizado. El puerto utilizado siempre se informa en la salida estándar.
La opción -I es útil cuando el cliente se ejecuta en una computadora portátil que ocasionalmente se conecta a la LAN en la que se encuentra el servidor. Cuando el servidor se puede encontrar en la LAN con IP privada = <IP> , tunnel se conecta a través de la LAN.
El cliente y el servidor deben utilizar el mismo secreto para poder conectarse entre sí. La cadena secreta también se puede pasar utilizando la variable de entorno TUNNEL_KEY . El secreto pasado con -k tiene prioridad.
-u indicador denota el uso de UDP en lugar del TCP predeterminado. Si se utiliza, debe ser utilizado por ambos pares.
Todos los registros están en stderr de forma predeterminada. Sin embargo, con la opción -l <logfile> , se puede iniciar tunnel en segundo plano ( modo demonio ) con los registros volcados en <logfile> . El ID del proceso del demonio se muestra al usuario durante el inicio para que pueda eliminar el demonio en cualquier momento con
tunnel -K < procID >Opciones:
Para obtener una lista completa de opciones, consulte: tunnel -h
Descargar con:
curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnelHazlo ejecutable:
chmod +rx ./tunnelLuego instale en todo el sistema con:
./tunnel -c install Si no tiene privilegios sudo , puede instalar localmente:
./tunnel -c install -lPara actualizar en cualquier momento después de la instalación:
tunnel -c update Este programa es simplemente un script bash ejecutable que depende de herramientas GNU estándar, incluidas socat , openssl , curl , mktemp , cut , awk , sed , flock , pkill , dd , xxd , base64 , etc., que están disponibles en distribuciones estándar de Linux.
Si su sistema carece de alguna de estas herramientas y no tiene el privilegio sudo necesario para instalarlo desde el repositorio de paquetes nativo (por ejemplo, sudo apt-get install <package> ), intente descargar un binario portátil e instálelo localmente en ${HOME}/.bin .
SSH :
El par A expone el puerto SSH local -
tunnel -k " ${secret} " 22El par B se conecta -
tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost IPFS :
Deje que el par A tenga IPFS-peer-ID: 12orQmAlphanumeric . Su demonio IPFS escucha en el puerto TCP predeterminado 4001. Lo expone con:
tunnel -k " ${swarm_key} " ipfs swarm_key es cualquier cadena secreta que el par A puede usar para controlar quién puede conectarse en enjambre a ella usando tunnel .
El par B ahora se conecta con el par A para compartir archivos o pubsub o p2p.
tunnel -k " ${swarm_key} " 12orQmAlphanumericEste último enjambre de comandos se conecta al par A a través del relé del servidor de tuberías y continúa conectándose cada pocos segundos en segundo plano para mantener viva la conexión.
tunnel inicia el demonio IPFS en segundo plano si aún no está activo.
La ruta al repositorio de IPFS se puede pasar con la opción -r . De lo contrario, la variable de entorno IPFS_PATH o la ruta predeterminada ~/.ipfs se utilizan como de costumbre. Ejemplo: tunnel -r ~/.ipfs -i proporciona el ID del par IPFS.
Carcasa remota :
Supongamos que necesita ejecutar comandos con regularidad en el equipo Linux de su lugar de trabajo desde la máquina de su hogar. Y no quieres o no puedes usar SSH a través de tunnel por algún motivo.
En la computadora del lugar de trabajo, exponga algún puerto TCP local aleatorio, por ejemplo, 49090 y conecte un shell a ese puerto:
tunnel -l " /tmp/tunnel.log " -k " your secret " 49090 # Note the base64 node id emitted
socat TCP-LISTEN:49090,reuseaddr,fork SYSTEM: ' bash 2>&1 'De regreso a tu casa:
tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000Usar rlwrap no es una necesidad. Pero seguro que hace que la experiencia sea más agradable ya que utiliza GNU Readline y recuerda el historial de entrada (accesible con las teclas de flecha arriba/abajo similares a sus sesiones de bash locales).
Redis :
¿Necesita conectarse a una instancia remota de Redis alojada por un par o por usted mismo? En el host remoto, exponga el puerto TCP en el que se ejecuta redis-server (predeterminado: 6379), con tunnel .
En su máquina local, utilice tunnel para reenviar un puerto TCP al puerto remoto. Apunte su redis-cli al puerto local reenviado.
A continuación se muestran algunos casos de uso aleatorios que se me ocurren para tunnel . En términos generales, cualquier cosa que implique atravesar NAT/firewall (por ejemplo, WebRTC sin TURN) o unirse a una LAN remota debería resultar útil para tunnel . Algunas de las siguientes ideas son bastante incompletas, no se han probado en absoluto y es posible que no funcionen, pero aun así están documentadas aquí, al menos por el momento, sólo como inspiración. Si encuentra alguno de estos útiles o inútiles, o ha encontrado aplicaciones completamente nuevas para tunnel , publíquelo en las discusiones. Los casos que he probado están etiquetados como "funcionales".
tunnel .tunnel en Heroku (gratis) y reenvíe el puerto almacenado en la variable de entorno PORT al puerto local que desea exponer. Y tienes tu URL pública como: https://your-app-name.herokuapp.com.tunnel . tunnel cifra todo el tráfico entre un par y el repetidor con TLS, si el repetidor usa https. No existe un cifrado de extremo a extremo per se entre los propios pares. Sin embargo, se afirma que el relé del servidor de tuberías no tiene almacenamiento .
Un par cliente puede conectarse con un par servidor solo si usa la misma clave secreta (TUNNEL_KEY). La clave se utiliza principalmente para el descubrimiento de pares en la etapa de retransmisión. Para cada nueva conexión al puerto local reenviado, el cliente envía una clave de sesión aleatoria al par servidor. Luego, los pares forman una nueva conexión en otro punto de retransmisión basada en esta clave aleatoria para que se produzca la transferencia de datos real. Forasteros, a saber. Los malos actores que no conocen TUNNEL_KEY no deberían poder interrumpir este flujo.
Sin embargo, un par malintencionado puede hacer lo siguiente. Como conoce TUNNEL_KEY y el ID de nodo del par servidor, puede hacerse pasar por este último. Por lo tanto, los datos de un par que se conecta desprevenido se reenviarían al imitador, privando al servidor genuino. Las futuras actualizaciones/implementaciones del tunnel deberían manejar esta amenaza utilizando criptografía de clave pública. [En ese caso, la clave de sesión aleatoria generada para cada nueva conexión que se reenvíe sería descifrable únicamente por el servidor genuino].
Dado que tunnel es esencialmente la capa de transporte, los puntos anteriores no deberían ser desalentadores, porque la mayoría de las aplicaciones como SSH e IPFS cifran datos en la capa de aplicación. Cifrar tunnel de extremo a extremo para todas las transferencias de datos solo aumentaría la latencia. Sin embargo, siempre puede crear un túnel SSH después de establecer el emparejamiento de bajo nivel con tunnel , si así lo desea.
El relé predeterminado utilizado por tunnel es https://ppng.io. También puede utilizar alguna otra retransmisión pública de esta lista o alojar su propia instancia en servicios gratuitos como los que ofrece Heroku. No hace falta decir que, para conectarse, dos pares deben utilizar el mismo relé.
Si así lo desea, también puede escribir su propio relé para que lo utilice tunnel utilizando herramientas simples como sertain. Solo asegúrese de que su servicio de retransmisión tenga la misma API que el servidor de tuberías. Si su código de retransmisión es de código abierto, puede presentarlo en las discusiones.
gsocket; ipfs p2p con circuito de relé habilitado; ir-tubería-dúplex; pipeto.me; enlace ascendente; localhost.ejecutar; ngrok; túnel local; sshreach.me ( prueba gratuita sólo por un período limitado ); más
Notas:
tunnel y Piping-Server, puede simplemente implementar su propia instancia de retransmisión, compartir su URL pública con sus pares de una vez por todas, export lo mismo que TUNNEL_RELAY dentro de .bashrc y listo. Además, hay varios servidores de tuberías públicos disponibles para redundancia.IPFS (hecho):
Conectarse a IPFS sería mucho más sencillo:
tunnel -k <secret> ipfs para exponer y tunnel -k <secret> <IPFS_peerID> para conectar.
Estos iniciarán el demonio IPFS por sí solos, si están fuera de línea. El último comando se conectará repetidamente al par dado en intervalos de 30 segundos. El IPFS-peer-ID se utilizará como ID de nodo, por lo que los pares ya no necesitarán compartir sus ID de nodo por separado. Las rutas de repositorio IPFS no predeterminadas se pueden pasar con la opción -r . o IPFS_PATH .
SSH:
Crear un túnel SSH entre el puerto local y el de pares sería tan fácil como:
tunnel -k <secret> ssh para exponer &
tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> para crear.
Tenga en cuenta que, al conectarse, ya no es necesario proporcionar un nombre de inicio de sesión. El ${USER} del nodo de servicio se toma como nombre de inicio de sesión de forma predeterminada. Sin embargo, si es necesario, siempre se puede pasar un nombre de inicio de sesión no predeterminado mediante una variable u opción de entorno.
GPG:
Las máquinas virtuales, como las que utilizan los cloud-shells y dynos, no tienen direcciones de hardware únicas y persistentes. Por lo tanto, el ID del nodo sigue cambiando de una sesión a otra para dicha máquina virtual. tunnel futuro tendría una opción -g que pasaría una clave privada GPG al tunnel . El ID del nodo se generaría a partir de la huella digital de esta clave, similar a lo que hace IPFS. Esto también haría que tunnel fuera más seguro.
Argón2:
Opción [ -a ] para usar argon2 para aplicar hash TUNNEL_KEY antes de su uso, de modo que un secreto más débil no sea demasiado vulnerable.
Informe errores en los problemas. Publique sus pensamientos, comentarios, ideas, casos de uso y solicitudes de funciones en la discusión. Déjame saber cómo te ayudó esto, si es que te ayudó.
También siéntete libre de escribirme directamente sobre cualquier tema relacionado con este proyecto.
Si este pequeño guión te resulta útil, una estrella sería inmensamente alentadora para mí.
Gracias ! ?
