•  untoreh-light

TCSplitter

Un túnel para dividir la conexión TCP o UDP a través de múltiples conexiones TCP

Objetivo

¿Cuándo querría dividir una conexión TCP en varias? Usualmente usas un túnel conseguir exactamente lo contrario . Mi caso de uso fue eludir las limitaciones de ancho de banda en una red móvil, por lo que las pruebas se realizaron con una tarjeta SIM sin más datos en su plan[1].

Como funciona

los túnel fue escrito en golang ya que es lo suficientemente rápido y se usa comúnmente para herramientas de red. El cli apenas se puede utilizar ya que la mayoría de las opciones se modificaron cuando probé diferentes métodos.

Inicialmente había "flings" y "lazos", para dividir el número de conexiones para salientes (flinged) y entrantes (lassoed), pero esta fue una abstracción innecesaria ya que es mejor etiquetar los paquetes con su destino, aunque la intención principal era para ofrecer diferentes límites de velocidad para conexiones entrantes y salientes, por lo que una separación de mayor nivel entre arriba / abajo parecía práctica.

El cliente tiene que crear una instancia de todas las conexiones, ya que asumimos que el servidor no puede abrir conexiones salientes. Cuando los clientes reciben una conexión de una aplicación de usuario, configura el grupo de conexiones requerido con el servidor, y cualquier dato que recibe, lo divide entre las conexiones dedicadas, de acuerdo con un límite definido por el usuario.

Luego, los paquetes se envían al servidor, que tiene que reconstruirlos en el orden correcto, porque diferentes conexiones TCP pueden terminar el flujo de datos en cualquier momento (no se respeta el orden enviado, porque enrutamiento ) y luego se reenvía a la aplicación receptora.

Las conexiones se cierran y se abren nuevas a medida que se alcanza el límite de datos configurado por conexión, similar a cómo shadowsocksProxies tuneliza datos a través de diferentes flujos con el objetivo de enmascarar el comportamiento de los flujos de datos, excepto que nuestro túnel lo hace con la mayor frecuencia posible.

Por que funciona

La intención aquí es controlar la cantidad de datos que debe manejar cada conexión. Para nuestros propósitos, nunca fue más allá de lo que generalmente es el MTU tamaño de ventana. Puede pensar en la MTU como el límite superior de un dato que pasa por completo a través de la red, y era nuestro objetivo porque queríamos eludir los límites de velocidad de ancho de banda de una red cerrada. Para limitar la cantidad de datos que puede transmitir un cliente, debe contar ¿bien? Si su lógica funciona con algo como undo-while

Entonces necesitas por lo menos recibir unpacket . No estoy seguro de si esto es lo que realmente sucede, o la razón por la que mi túnel funciona es otra. Tal vez sea totalmente posible verificar incluso el primer paquete, pero desde una perspectiva de diseño, eso significaría que tendría que verificar cada conexión única, lo que debilitaría el sistema a los ataques de DOS, y sí, mi túnel podría usarse fácilmente como una herramienta eficiente de DOS / Stress, ya que puede dividir los datos en paquetes muy pequeños (lo que significa que las conexiones TCP tendrán una alta presión de reciclaje ) y tenga un grupo de conexiones tan grande como desee.

Las pruebas en diferentes puertos también mostraron que solo era posible algunos puertos, y que el lmite era constantemente diferente entre los puertos, con443 dando una de las ventanas más altas, alrededor20kb , adivinando porqueTLS los apretones de manos requieren más datos y que estos límites de velocidad cambiarían según la hora del día[2].

Resultados

Probé la codificación de borrado con la esperanza de aumentar el rendimiento de los datos. Mediante el uso de una biblioteca de codificación de borrado y enc / decodificando los datos en sí, y también superponiendo el KCP protocolo sobre mi protocolo de división. Probar KCP puede parecer un enfoque al revés, ya que intercambia una mejor latencia por un rendimiento más bajo, pero mi suposición inicial fue que mi cuello de botella estaba en las conexiones caídas a mitad de la transmisión, lo que causaría muchos paquetes corruptos, por lo que podría haber logrado un mayor rendimiento con corrección de errores.

Resultó que era solo un límite de velocidad sobre la cantidad de conexiones TCP que un cliente puede enviar a través de la red, así que solo una protección DOS sobre la que no puedo hacer nada. Después de X cantidades de conexiones cualquierSYN los intentos dejan de recibir su debidoACK , llenando la acumulación y eventualmente haciendo que el túnel se detenga. Prueba y error demostró que era posible entre4-8[3] conexiones abiertas en cualquier momento dado, y con un MTU de500-1000 bytes que podría mantener un flujo constante alrededor de al menos128kbps , si un flujo constante no fuera un requisito, podría lograr velocidades más altas en un período de tiempo más corto al muy lleno muchas conexiones bajo demanda.

En contraste, un (verdadero)DNS el túnel apenas puede empujar56kbps y puede acelerarse rápidamente porque creo que una gran cantidad de solicitudes de DNS parece más sospechosa que las solicitudes de TCP. Tenemos que especificar que untrue El túnel DNS codifica datos (salientes) sobre subdominios falsos y decodifica datos (entrantes) recibidos al consultar registros DNS, mientras que a veces se puede pensar que un túnel DNS es una conexión UDP sin procesar a través del puerto DNS, que probablemente en algún momento del pasado, servidores DNS permitido y reenviado correctamente.

Conclusiones

No estoy seguro de haber alcanzado mi meta utilidad sabio, ya que ejecutar ese tipo de túnel puede hacer que tu teléfono se caliente bastante y desperdiciar mucha batería, pero tenerlo como una conexión de respaldo puede ser reconfortante ... si realmente me molestara en hacerlo lo suficientemente estable :)

[1]Por lo general, cuando una tarjeta SIM no tiene más datos para navegar por la web, las solicitudes web se redirigen a la puerta de enlace de captura (para indicarle que compre más datos)
[2]Los planes de datos móviles pueden proporcionar una mejor conexión durante las horas nocturnas.
[3]Este número, algo alineado con los recuentos de núcleos comunes, podría inducirlo a sospechar que el kernel está limitando las conexiones de alguna manera, el escenario de conexiones abiertas de nuestro túnel es definitivamente inusual, pero ajustar las perillas de Linux nunca dio mejores resultados por mi parte.

Etiquetas de publicación: