¿Qué es TCP-sobre-TCP y cómo evita el problema OpenVPN en modo TCP?

A mi entender, el problema del "tcp meltdown" no es difícil de resolver: sólo hay que establecer un tiempo de espera de retransmisión grande para la conexión tcp interna.

Al aumentar considerablemente el tiempo mínimo de retransmisión de la conexión TCP interna, hemos desactivado de forma efectiva el mecanismo de retransmisión por tiempo de espera del TCP interno. Por lo tanto, se evita el problema del colapso del TCP.

Por ejemplo, en linux, puede utilizar ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12s para aumentar el tiempo de espera de retransmisión mínimo de todas las conexiones internas establecidas a través de OpenVPN de 0,2 segundos a 12 segundos (se supone que 192.168.168.1/24 es su segmento de red OpenVPN).

Puede establecer el comando anterior como evento de llamada de OpenVPN. De esta manera, hemos evitado el problema de tcp meltdown de una manera sencilla.

Utilizamos este método para optimizar el enlace tcp-sobre-tcp. Incluso en la línea con alta latencia (cientos de milisegundos) y alta pérdida de paquetes, no hemos encontrado efectos adversos.

PD: En una línea con alta latencia, alta pérdida de paquetes y alto ancho de banda, es obvio que hay que preparar una ventana grande para que las conexiones tcp internas ocupen todo el ancho de banda.

ACTUALIZACIÓN:

La cuestión aquí es ¿por qué TCP-sobre-TCP no tiene un efecto notable en la VPN basada en TCP?

Porque en una línea de alta calidad que rara vez pierde paquetes, el fenómeno del colapso de TCP no es prominente.

Yo diría que esto tiene más que ver con la forma en que TCP funciona, y no con OpenVPN per se. Aquí viene una larga diatriba y mis pocos centavos:

¿Es correcto lo que he entendido?

A grandes rasgos sí, pero la conexión TCP interna no está "protegida". Si la conexión externa deja caer un paquete y el rendimiento disminuye o la latencia aumenta, la conexión interna también se vería limitada por ello, notaría que no puede utilizar todo el rendimiento y empezaría a retroceder.

Parece que el colapso TCP-sobre-TCP es sólo interno (es decir, sólo afecta a los búferes locales), pero ¿afecta también a la red?

Sólo tendrás una conexión TCP con el servidor, por lo que esto sólo afectará a esa conexión en particular y a lo que haya en ella. A lo que se refiere el meltdown es a lo que describo en la respuesta anterior.

¿Causa más congestiones en la red y degrada otras conexiones en la misma red?

No, pero necesitaría que aquí se definiera "red". Si tiene una mala conexión a Internet, entonces sí, todo sufriría caídas de paquetes u otros problemas de transmisión. Si te refieres a que sólo hay un problema con tu conexión cliente<=>servidor, entonces tus conexiones no VPN no se verían afectadas.

¿Cómo resuelven este problema las VPN basadas en TCP?

Utilizando una única conexión al servidor, envíe el tráfico dentro de esa conexión y espere lo mejor.

OpenVPN tiene un artículo sobre esto, pero no dice por qué no es un problema en la práctica, es un problema en la práctica.

Sí. TCP tiene una sobrecarga mucho mayor en términos de tamaño de paquete que UDP, por lo que siempre estás pagando una penalización de tamaño al tener dos cabeceras TCP (interna más externa) en tu conexión. Los reenvíos y el aumento de TCP también afectarán a tu rendimiento. Si tienes una buena conexión, es decir, sin caídas, baja latencia y gran ancho de banda, entonces no verás mucho el aumento/retorno/reenvíos, y por lo tanto no lo notarás. Si tienes una mala conexión, entonces la primera respuesta entra en juego, las conexiones externas podrían disminuir, esto afectará al tráfico interno que disminuirá, los paquetes pueden quedar fuera de orden y ser reenviados y así sucesivamente, lo que sin duda afectará al rendimiento del túnel.

La respuesta es larga. Espero que esto tenga algún sentido para alguien más que yo.