tunneler

tunelizador

Este repositorio contiene un cliente y un servidor que le permiten canalizar el tráfico TCP y UDP a través de otros protocolos de red.

Actualmente, los túneles admitidos son:

• DNS (servidor autorizado o conexión directa)
• TLS (autenticación mutua)
• tcp

La herramienta principal está escrita en Rust y las pruebas de un extremo a otro están escritas en Python.

Instalación

Opción 1: imágenes acoplables de cliente y servidor

docker pull ghcr.io/dlemel8/tunneler-server:latest
docker pull ghcr.io/dlemel8/tunneler-client:latest

Opción 2: compilar desde el código fuente

cargo --version || curl --proto ' =https ' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo build --release

También hay un archivo acoplable si prefiere crear una imagen acoplable local.

Uso

Opción 1: imágenes acoplables de cliente y servidor

docker run -e LOCAL_PORT=45301 
           -e REMOTE_PORT=5201 
           -e REMOTE_ADDRESS=localhost 
           -e TUNNELED_TYPE=udp 
           --rm -p 45301:45301 ghcr.io/dlemel8/tunneler-server:latest tcp

Opción 2: binario compilado localmente

./target/release/client 
  --tunneled-type tcp 
  --remote-address 1.1.1.1 
  --remote-port 53 
  --log-level debug 
  dns 
  --read-timeout-in-milliseconds 100 
  --idle-client-timeout-in-milliseconds 30000

Ejecute la imagen de Docker o el binario compilado con --help para obtener más información

Pruebas

Ejecutar pruebas unitarias

cargo test --all-targets

Ejecute pruebas de un extremo a otro

python3 -m pip install -r e2e_tests/requirements.txt
PYTHONPATH=. python3 -m pytest -v

Ejemplos

Este repositorio contiene algunos ejemplos de implementación de servidores usando Docker Compose:

• Prueba de velocidad: el servidor iperf3 expuesto a través de todos los túneles compatibles le permite comparar la velocidad de los túneles.
• DNS autorizado: servidor Redis expuesto a través de un túnel DNS en el puerto UDP/53. Dado que el túnel no verifica a los clientes, se necesita la autenticación de Redis.
• Canalización: servidor Redis expuesto a través de un túnel TLS que a su vez se expone a través de un túnel DNS. Dado que el túnel verifica a los clientes, no se utiliza la autenticación de Redis.

Puede ejecutar cada ejemplo localmente o implementarlo usando Terraform y Ansible. Ver más información aquí.

Arquitectura

Cada ejecutable contiene 2 componentes que se comunican a través de un canal de flujos de cliente (una tupla de lector y escritor de bytes):

• Client Listener vincula un socket y convierte el tráfico entrante y saliente en una nueva secuencia.
• Client Tunneler traduce el lector y escritor de flujo al protocolo de túnel.
• Server Untunneler vincula un socket de acuerdo con el protocolo de túnel y traduce el tráfico tunelizado al flujo original.
• Server Forwarder convierte el escritor y lector de transmisiones nuevamente en tráfico.

El tráfico basado en TCP se convierte trivialmente en flujo. La conversión de tráfico basada en UDP depende del protocolo del túnel.

El tráfico basado en UDP también necesita una forma de identificar a los clientes existentes para continuar con sus sesiones. La solución es una caché de clientes en memoria que asigna un identificador del cliente a su flujo.

Protocolos

UDP tunelizado

Para convertir el tráfico UDP en una secuencia, un encabezado de 2 bytes (en big endian) precede a cada carga útil del paquete.

UDP Listener utiliza la dirección del par del paquete entrante como clave para su caché de clientes.

Túnel DNS

Tenemos algunos desafíos aquí:

• La carga útil de DNS debe ser alfanumérica.
• Cada mensaje requiere una respuesta antes de que podamos enviar el siguiente mensaje.
• Cada consulta de DNS utiliza un puerto de origen y un ID de transacción aleatorios, por lo que no podemos usarlos como clave de caché del cliente.

Para resolver esos desafíos, cada sesión de cliente comienza generando una ID de cliente aleatoria (4 caracteres alfanuméricos). El cliente lee los datos para hacer un túnel y los ejecuta a través de una canalización de codificadores:

• Los datos están codificados en hexadecimal.
• Se adjunta el ID del cliente.
• Se añade el sufijo del cliente. En caso de que el servidor se esté ejecutando en su servidor DNS autorizado, el sufijo es ".<su dominio>".

Luego, los datos codificados se utilizan como nombre de una consulta DNS TXT.

Si posee un servidor DNS autorizado, el cliente puede enviar la solicitud a un solucionador de DNS recursivo. Resolver obtendrá su IP de su registrador de nombres de dominio y reenviará la solicitud a su IP. Otra opción (más rápida pero más obvia para cualquier analizador de tráfico) es configurar el cliente para que envíe la solicitud directamente a su IP (en el puerto UDP/53 o en cualquier otro puerto que el servidor esté escuchando).

El servidor decodifica los datos (ignorando cualquier tráfico que no sea del cliente) y utiliza la ID del cliente como clave para la caché de sus clientes.

Para manejar respuestas grandes del servidor y ACK TCP vacíos, se utiliza el tiempo de espera de lectura tanto en el cliente como en el servidor. Si el tiempo de espera de lectura expira, se enviará un mensaje vacío. Tanto el cliente como el servidor utilizan el tiempo de espera de inactividad para detener el reenvío y limpiar los recursos locales.

Túnel TLS

Para implementar la autenticación mutua, utilizamos una Autoridad de certificación privada:

• Se genera un certificado de CA autofirmado a partir de una clave privada.
• La clave privada del servidor se genera aleatoriamente y su parte pública se utiliza en un certificado firmado por la CA.
• La clave privada del cliente se genera aleatoriamente y su parte pública se utiliza en un certificado firmado por la CA.

Tanto el cliente como el servidor están configurados para usar su clave y certificado en el protocolo de enlace TLS. El certificado de CA se utiliza como certificado raíz.

Dado que se utiliza la extensión de indicación de nombre de servidor, el cliente solicita un nombre de servidor específico y el servidor entrega su certificado solo si se solicitó ese nombre. El nombre del servidor también debe formar parte del certificado, por ejemplo como nombre alternativo del sujeto.