0x00: Introducción — cuando la sesión no cae por lentitud, sino por tamaño
Pocas cosas son tan engañosas como una “desconexión aleatoria” en acceso remoto.
Desde fuera parece un fallo difuso; desde dentro, muchas veces es un problema estrictamente determinista.
En este caso, la hipótesis de trabajo apunta a una desalineación entre el tamaño efectivo que tolera el trayecto y el tamaño de ciertos flujos que la sesión remota intenta transportar con normalidad.
El resultado práctico lo conoce cualquiera que trabaje sobre escritorio virtualizado, congelaciones, pérdida de respuesta, retrasos anómalos y colapso progresivo del túnel.
RESUMEN EJECUTIVO
MTU efectiva del trayecto: inferior al tamaño estándar de ciertos flujos de la sesión remota
Overhead de encapsulación: suficiente para tensionar el túnel y reducir el espacio útil
PMTUD: degradado por señalización ICMP insuficiente en el primer tramo
Trayecto: sin garantía de coherencia de MTU extremo a extremo
Resultado: reintentos, pérdida de ACKs, descarte silencioso y degradación progresiva del plano de datos
0x01: Desalineación de MTU
Tras varias pruebas manuales, la hipótesis más sólida es una discrepancia entre el tamaño real que el trayecto admite y el tamaño que algunos flujos de la sesión remota esperan utilizar.
La validación se realizó mediante sondas manuales con ping -f -l, buscando el punto a partir del cual el trayecto dejaba de aceptar el payload sin fragmentación.
PRUEBA REPRESENTATIVA DE MTU
C:\> ping -f -l <payload_tolerado> <destino_remoto>
Reply from <destino_remoto>: bytes=<payload_tolerado> time=<baja_latencia> TTL=<ttl>
C:\> ping -f -l <payload_estandar_de_sesion> <destino_remoto>
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
El patrón es claro, existe un techo práctico inferior al tamaño con el que ciertos flujos intentan circular.
Cuando esos paquetes alcanzaban el trayecto con el bit DF activado, eran descartados.
| COMPONENTE | TAMAÑO ESPERADO | LÍMITE OBSERVADO | IMPACTO |
|---|---|---|---|
| Flujos estándar de sesión remota | Superiores al margen útil del túnel | Inferior al tamaño estándar de algunos paquetes | Colisión de tamaño / descarte silencioso |
| Túnel VPN | Capacidad nominal superior | MTU efectiva reducida por encapsulación | Overhead acumulativo |
| Señal observada | Fragmentation needed but DF set | Comportamiento equivalente | Descarte con DF activado |
HIPÓTESIS DE TRABAJO
-
El payload máximo tolerado por el trayecto era inferior al tamaño estándar de ciertos flujos de la sesión remota.
-
La encapsulación del túnel reducía el espacio útil disponible.
-
Los paquetes con DF activado eran descartados de forma repetida.
-
El sistema entraba en un bucle de reintentos y degradación progresiva.
Este es el impuesto invisible del encapsulamiento: la capa de seguridad protege el tráfico, pero también consume parte del margen que ese tráfico necesita para sobrevivir al trayecto.
0x02: PMTUD degradado — el mensajero no llegaba
En condiciones normales, el mecanismo PMTUD (Path MTU Discovery) debería permitir al host ajustar el tamaño del tráfico cuando aparece una restricción en el camino.
El problema aquí no era solo que hubiese descarte: era que el trayecto no estaba devolviendo de forma útil la señalización ICMP necesaria para que el host redujese el tamaño de los segmentos.
TRAZA REPRESENTATIVA DEL TRAYECTO
Tracing route to <destino_remoto> over a maximum of 30 hops: 1 <1 ms * * <gateway_de_acceso> [señalización insuficiente] 2 * * * Request timed out. 3 x ms x ms x ms <interconexión_remota> 4 x ms x ms x ms <destino_remoto>
La lectura más razonable es que el primer tramo del trayecto no devolvía correctamente mensajes ICMP equivalentes a Type 3 Code 4.
Sin esa retroalimentación, el host seguía enviando tráfico demasiado grande hacia un agujero negro de MTU.
FALLO DE DISEÑO POSIBLE
Bloquear o degradar señalización ICMP crítica puede dar una falsa sensación de endurecimiento. En la práctica, puede romper la adaptabilidad del transporte y provocar retransmisiones innecesarias, pérdida de rendimiento y sesiones inestables.
0x03: Trayecto — no es solo latencia
La lectura del path añade un factor que no aparece en la latencia, y es que cuanto más largo y más intermediado sea el trayecto, más probable es que algún salto tenga una MTU efectiva menor que la que el túnel negocia.
Eso no demuestra por sí solo la causa raíz, pero sí explica por qué el margen útil del trayecto puede ser menor y más frágil.
LECTURA DE RENDIMIENTO
La latencia aparente no es necesariamente mala. El problema real está en el coste lógico del trayecto, encapsulación, reintentos, descarte silencioso y necesidad de reensamblado o retransmisión.
En otras palabras…una ruta puede devolver buen ping y aun así, ser hostil para una sesión remota si el tamaño efectivo del tráfico no encaja con la realidad del trayecto.
0x04: DNS roto, cola creciente y descarte final
Errores de resolución y parsing DNS
Los logs del cliente de acceso remoto muestran errores repetidos de parsing y resolución asociados al tráfico DNS.
La señal técnica más interesante era la incapacidad de extraer correctamente el FQDN de determinadas consultas.
FRAGMENTO REPRESENTATIVO
Packet parser: failed to extract FQDN from DNS query packet Packet parser: failed to extract FQDN from DNS query packet Packet parser: failed to extract FQDN from DNS query packet
Esto no prueba por sí mismo corrupción de paquetes, pero sí es consistente con un entorno donde la resolución no se completa de forma limpia y donde el transporte ya está bajo estrés.
El colapso del plano de datos
La parte más reveladora aparece en el módulo de envío ordenado, el sistema espera una secuencia de confirmaciones que no llega, mientras la cola de paquetes pendientes sigue creciendo.
FRAGMENTO REPRESENTATIVO DE RETRANSMISIONES
SendQueue: packet out of sequence SendQueue: pending packets count increasing SendQueue: retry threshold exceeded SendQueue: resetting expected packet pointer
LECTURA TÉCNICA
El sistema queda atrapado en una espiral de retransmisión, espera ACKs, no los recibe, reintenta, acumula cola y finalmente degrada o descarta tráfico. La sesión no cae por falta de cobertura, sino por agotamiento progresivo del transporte.
SEÑAL FINAL DE COLAPSO
SendQueue: dropped packet after repeated retries
Cuando aparece esa firma, la sesión ya está funcionalmente rota es decir, el flujo deja de ser confiable y el usuario percibe congelación, saltos o pérdida completa de respuesta.
0x05: Resolución, tiempo y recursos bajo presión
A nivel de sistema operativo aparecen además indicadores compatibles con degradación del host.
Aquí conviene ser prudente, pero la correlación temporal es real, aunque no toda señal debe interpretarse como consecuencia directa del túnel.
Familias de eventos esperables
| FAMILIA | SEÑAL | LECTURA |
|---|---|---|
| DNS Client Events (p. ej. 8018 / 1014) | Repetición periódica | Pérdida o degradación de resolución / registro dinámico |
| Time Service (p. ej. 129) | Fallo de sincronización | Dependencias de red / dominio afectadas |
| Application Popup (p. ej. 26) | Memoria virtual bajo presión | Thrashing y degradación de respuesta |
| DistributedCOM (p. ej. 10010) | Burst de errores | Servicios bloqueados o incapaces de responder a tiempo |
| Service Control Manager (p. ej. 7043) | Cierre no limpio | Sistema ya muy degradado al apagarse |
| EventLog (p. ej. 6006) | Fin de registro | Cierre del sistema / fin de trazabilidad local |
INTERPRETACIÓN PRUDENTE
-
La pérdida de resolución y de sincronización temporal apunta a degradación real de conectividad interna.
-
El burst de errores de servicios apunta a un host bajo estrés.
-
La presión sobre memoria y paginación agrava la experiencia de congelación.
-
No toda degradación del host debe atribuirse de forma automática al túnel, pero la correlación merece atención.
0x06: El cambio en el trayecto como factor desencadenante
Hay un factor que conviene valorar aparte, y es que un cambio en un equipo intermedio basta para alterar el comportamiento del trayecto sin que nadie toque el acceso remoto.
Un filtrado de ICMP nuevo, un reajuste de MTU en un salto o un cambio de path bastan para mover el punto de descarte.
Antes del episodio más severo aparecen cortes periódicos breves compatibles con una anomalía de capa 2.
HIPÓTESIS COMPLEMENTARIA
Un cambio de path o de equipamiento intermedio puede dejar una desalineación entre MTU, filtrado ICMP y comportamiento del acceso remoto. No es una causa raíz única por sí sola, pero sí una correlación razonable y lo primero que conviene comprobar.
La idea central no cambia, pero la red pudo pasar de un fallo visible y periódico a un fallo menos vistoso, eso si, más destructivo para el transporte encapsulado.
0x07: Conclusión — Resiliencia de Capa 4
La hipótesis de trabajo más consistente es la siguiente:
El túnel opera sobre un trayecto con MTU efectiva demasiado ajustada, sin una retroalimentación PMTUD suficientemente funcional, y eso provoca retransmisiones, pérdida de confirmaciones y degradación progresiva de la sesión remota.
La consecuencia operativa no es solo “va lento”, sino algo peor, y es que el sistema entra en una espiral donde red, resolución y recursos locales se deterioran a la vez.
| PROBLEMA | LECTURA TÉCNICA | MITIGACIÓN CONCEPTUAL |
|---|---|---|
| Paquetes descartados de forma repetida | MTU efectiva del trayecto inferior a la esperada por ciertos flujos | Aplicar MSS clamping o equivalente en el punto de acceso remoto |
| PMTUD degradado | La señalización necesaria no llega al host a tiempo | Permitir ICMP útil para ajuste de Path MTU |
| Retransmisiones y cola creciente | Pérdida de ACKs / bucle de reintentos | Revisar umbrales de retransmisión y tamaño de segmento efectivo |
| Trayecto intermediado y sin coherencia de MTU | Mayor complejidad del path y menor margen útil | Auditar rutas, interconexiones y coherencia de MTU extremo a extremo |
| Degradación del host | Thrashing, bloqueos parciales y cierre no limpio de servicios | Validar impacto real de reintentos sobre recursos y observabilidad local |
A TENER EN CUENTA
Alinear el tamaño efectivo del transporte: revisar MSS / MTU real del trayecto y no solo la nominal del túnel.
Recuperar PMTUD funcional: permitir la señalización ICMP estrictamente necesaria para que el host pueda adaptarse.
Auditar coherencia extremo a extremo: verificar que no existan diferencias de MTU ni de filtrado entre segmentos.
Revisar el trayecto remoto: entender si la complejidad del path está reduciendo el margen útil del tráfico encapsulado.
Ajustar la tolerancia a reintentos: evitar que el cliente permanezca demasiado tiempo atrapado en estados de retransmisión improductiva.
“En acceso remoto, endurecer no siempre es sinónimo de resistir. Una red puede estar muy protegida y, al mismo tiempo, ser incapaz de transportar con normalidad el tráfico que ella misma exige.”
[EOF] — “Sometimes the problem is not bandwidth, but transport coherence.”