El ping por VPN funciona, pero la transferencia se bloquea
La conectividad con paquetes pequeños no garantiza que los más grandes puedan atravesar la ruta VPN. Ilustración conceptual.
Durante una intervención de mantenimiento remoto, el router industrial indica que la VPN está conectada. El ping responde y se establece la conexión con el controlador. Sin embargo, una transferencia de archivos se bloquea, la interfaz web del equipo solo carga parcialmente o una solicitud de mayor tamaño nunca termina.
Empiece por comprobar si el fallo depende del tamaño de los paquetes en la ruta real de la aplicación. Que un ping pequeño funcione no demuestra que los paquetes más grandes puedan atravesar el túnel. La sobrecarga de la VPN y la falta de información sobre la MTU de la ruta son causas posibles, pero el fallo de una transferencia de archivos grandes no basta para diagnosticar un problema de MTU. RFC 2923 describe el caso característico: el ping y las conexiones interactivas funcionan, mientras las transferencias de mayor volumen se bloquean al enviar paquetes más grandes.
PUNTOS CLAVE
Pruebe el mismo túnel, destino y enlace WAN que utiliza la aplicación afectada. Repita las pruebas con distintos tamaños de paquete y en ambos sentidos.
Distinga el paquete IP interno del paquete externo encapsulado. La ruta externa debe admitir la sobrecarga de la VPN.
Elija los ajustes a partir de las pruebas de tamaño de paquete y los mensajes ICMP. La limitación de MSS puede ayudar al tráfico TCP; no cambia directamente el tamaño de los datagramas UDP.
Cambie un solo parámetro cada vez, abra conexiones nuevas y repita la transferencia que fallaba antes de dar la solución por válida.
POR QUÉ FALLAN LOS PAQUETES GRANDES
La MTU, tal como se utiliza aquí, es el tamaño máximo de paquete IP que puede transportar un enlace. La MTU de la ruta, o PMTU, es la menor MTU de los enlaces que componen esa ruta. Un paquete que cabe en la LAN de una fábrica puede no caber, tras la encapsulación VPN, en la ruta hacia la pasarela remota.
La encapsulación añade bytes. Por ejemplo, el paso a través de NAT con IPsec puede transportar ESP dentro de UDP. La versión de IP externa, el protocolo VPN y los túneles adicionales influyen en esa sobrecarga. Por tanto, una MTU WAN de 1500 no implica una MTU interna del túnel de 1500.
En el descubrimiento clásico de la MTU de la ruta para IPv4, un router que no puede reenviar un paquete demasiado grande con Don't Fragment (DF) activado lo descarta y devuelve un mensaje ICMP de «fragmentación necesaria». El emisor utiliza esa información para reducir el tamaño de los paquetes posteriores. En cambio, PMTUD para IPv6 utiliza mensajes ICMPv6 Packet Too Big; los routers de tránsito no fragmentan paquetes IPv6.
Si esos mensajes se filtran o se procesan de forma incorrecta, el emisor puede seguir enviando paquetes que no logran pasar. En una VPN, compruebe tanto si la información de la ruta externa llega al extremo del túnel como la forma en que ese extremo gestiona el tráfico interno. Buscar ICMP únicamente en la LAN del PLC deja parte del proceso sin observar.
«Grande» se refiere aquí al tamaño de cada paquete, no al tamaño total del archivo. Si los fallos dependen de un tipo de archivo, de una acción de la aplicación o del tiempo transcurrido, sin un umbral de tamaño de paquete reproducible, también hay que investigar otras causas.
PRUEBE LA RUTA VPN
Diagnostique la ruta real de la aplicación industrial y después repita la transferencia que fallaba. Escena industrial ilustrativa.
Siempre que sea posible, utilice equipos de prueba bajo su control en ambos extremos de la VPN. Sus resultados ayudan a aislar el problema en la ruta, pero la validación final debe hacerse con el controlador lógico programable (PLC), la interfaz hombre-máquina (HMI) o el equipo de la aplicación original.
1. Registre la ruta
Anote el modelo del router, el firmware, el protocolo VPN, las versiones de IP interna y externa, la conexión WAN, las direcciones de origen y destino, y los ajustes actuales de MTU y MSS. Confirme que el tráfico de prueba entra realmente en el túnel previsto. Hacer ping a la dirección pública del router, a su dirección del túnel o a un equipo situado detrás de él comprueba rutas diferentes.
Reproduzca el fallo original y registre el sentido de la transferencia, la hora y el error antes de cambiar nada.
2. Pruebe tamaños de paquete
Empiece por un paquete pequeño que funcione de forma fiable, aumente su tamaño y acote el intervalo en el que empiezan los fallos. Repita la prueba con cada tamaño: un único tiempo de espera agotado puede deberse a una pérdida de paquetes ordinaria.
En un equipo de prueba Linux con ping de iputils, sustituya <remote-host-ip> por la dirección de un equipo IPv4 bajo su control al que se llegue a través de la VPN:
ping -4 -M do -s 1200 -c 4 <remote-host-ip>
ping -4 -M do -s 1372 -c 4 <remote-host-ip>Son ejemplos de sondeo, no valores de MTU recomendados. Según el manual de ping de iputils, -s establece el tamaño de los datos y -M do activa DF respetando las comprobaciones de PMTU del kernel. Con una cabecera IPv4 de 20 bytes y una cabecera ICMP de 8 bytes, 1372 bytes de datos generan un paquete IP interno de 1400 bytes, antes de añadir la sobrecarga de la VPN. Las opciones IP adicionales modifican ese cálculo.
Un error local «message too long» puede indicar que el kernel rechazó el sondeo antes de transmitirlo. Un tiempo de espera agotado, por sí solo, no identifica dónde se perdió. Registre el comando, el tamaño de los datos y el resultado observado; el tráfico ICMP y el de la aplicación también pueden estar sujetos a políticas diferentes. Estos comandos Linux no son instrucciones para la CLI de un router ni para una prueba IPv6.
3. Revise los mensajes ICMP
Cuando tenga acceso, capture tráfico en las interfaces internas y externas pertinentes de ambos extremos de la VPN. Busque el punto a partir del cual dejan de aparecer los paquetes grandes, los mensajes IPv4 de fragmentación necesaria o IPv6 Packet Too Big, y compruebe si estos llegan al extremo correcto.
Para TCP, compare el establecimiento de la conexión con los datos y las retransmisiones posteriores. La retransmisión repetida de segmentos grandes es un indicio descrito en RFC 2923, pero las retransmisiones por sí solas no demuestran un agujero negro de MTU: paquetes demasiado grandes que se pierden sin que el emisor reciba información útil para corregir su tamaño.
Observación | Siguiente comprobación |
|---|---|
Los errores ICMP pertinentes llegan a un extremo, pero el tráfico sigue siendo demasiado grande | Revise cómo los procesa ese extremo y la MTU efectiva del túnel. |
Los fallos empiezan repetidamente cerca de un tamaño de paquete concreto, pero no se ven mensajes de retorno | Observe otras interfaces e investigue el filtrado o el tratamiento de la ruta de retorno. |
Los fallos no tienen una relación constante con el tamaño de los paquetes | Investigue el comportamiento de la aplicación, los recursos del dispositivo y las condiciones del enlace, además de la hipótesis de MTU. |
No ver ICMP en un punto de captura no demuestra que ningún dispositivo lo haya generado.
4. Pruebe ambos sentidos
Pruebe por separado las transferencias desde la instalación hacia el extremo remoto y las del sentido contrario. Conserve el origen, el destino y la ruta WAN de cada resultado. Una comparación controlada sin VPN puede ayudar, pero utiliza otra ruta y debe registrarse por separado.
No cambie MTU, MSS, keepalive y el protocolo VPN a la vez. Aunque la transferencia vuelva a funcionar, será difícil identificar qué cambio surtió efecto.
¿AJUSTAR LA MTU O EL MSS?
Si el paquete encapsulado supera la capacidad de la ruta externa, consulte las indicaciones de la implementación VPN para configurar una MTU efectiva del túnel. Si los mensajes ICMP necesarios se bloquean o se procesan incorrectamente, corrija ese comportamiento. Reducir el tamaño de los paquetes puede restablecer el servicio sin resolver el problema subyacente con los mensajes de retorno; deje constancia de esa diferencia.
El MSS limita los datos TCP
El MSS de TCP especifica el tamaño de los datos TCP, sin incluir las cabeceras IP y TCP. La limitación de MSS reduce el valor anunciado en los paquetes de establecimiento de la conexión TCP cuando atraviesan un punto donde se aplica esa regla. Influye en el tamaño de los segmentos TCP que enviará después el otro extremo; no equivale a cambiar la MTU de una interfaz y no modifica directamente el tamaño de los datagramas UDP.
Para una MTU IP interna efectiva ya determinada de 1400 bytes, restar únicamente las cabeceras fijas da estos valores:
Versión de IP interna | Cabeceras fijas IP + TCP | MSS ilustrativo |
|---|---|---|
IPv4 | 20 + 20 bytes | 1360 bytes |
IPv6 | 40 + 20 bytes | 1340 bytes |
La MTU de 1400 bytes es una hipótesis de este cálculo, no un ajuste universal. RFC 6691 también exige que el emisor reduzca la longitud real de los datos TCP para tener en cuenta las opciones IP o TCP que incluya. No utilice una MTU de la ruta externa en este cálculo del paquete interno.
El valor de MSS se anuncia en los paquetes SYN, incluido SYN-ACK, y cada valor anunciado limita lo que debería enviar el otro extremo, como especifica RFC 9293. Tras cambiar una regla de limitación, establezca conexiones TCP nuevas e inspeccione ambos sentidos. Una sesión existente no basta para demostrar que la nueva regla ha entrado en vigor.
Distinga los ajustes de cada protocolo
El manual de OpenVPN 2.6 describe mssfix para TCP dentro del túnel e indica que tiene sentido cuando OpenVPN utiliza UDP para comunicarse con el otro extremo. Su argumento mtu cambia el cálculo del tamaño para incluir las cabeceras IP externa y UDP. No trate tun-mtu, mssfix y fragment como ajustes intercambiables ni copie ajustes de OpenVPN en configuraciones de WireGuard o IPsec.
Si falla el tráfico UDP, investigue por separado el tamaño de los datagramas de la aplicación, la encapsulación y el mecanismo de sondeo de la implementación. DPLPMTUD utiliza sondeos y confirmaciones de entrega para descubrir tamaños de paquete utilizables sin depender de mensajes ICMP Packet Too Big. Su disponibilidad depende de la aplicación o de la implementación del protocolo.
COMPRUEBE LA SOLUCIÓN
Repita la transferencia original por la misma ruta. Compruebe que termina, verifique el tamaño y el contenido del archivo cuando corresponda, y pruebe ambos sentidos con conexiones nuevas. En instalaciones con varias conexiones WAN, pruebe cada ruta pertinente por separado: la PMTU puede variar cuando cambia la ruta.
Deje un breve registro de la intervención para el equipo de mantenimiento: síntoma original, ruta de prueba, tamaños de paquete que funcionaron y fallaron, mensajes de retorno observados, ajustes antes y después del cambio, resultados de las transferencias y procedimiento de reversión. Si los paquetes más pequeños restablecen el servicio, pero sigue sin conocerse el cuello de botella, registre: «servicio restablecido tras ajustar el tamaño de los paquetes; cuello de botella aún no localizado».
Para equipos Wavetel, envíe el modelo, el firmware, el tipo de VPN, la topología y el registro de pruebas a través de Soporte técnico. Confirme los controles reales de MTU y MSS y las funciones de captura del modelo en la documentación de su firmware; una lista de protocolos VPN compatibles no acredita esos detalles de configuración.
PREGUNTAS FRECUENTES
¿Un ping correcto descarta problemas de MTU?
No. Confirma que un sondeo de ese tamaño completó el recorrido de ida y vuelta. Pruebe paquetes más grandes y la ruta real de la aplicación; después compruebe si los fallos dependen de forma constante del tamaño de los paquetes.
¿Todas las VPN deben usar una MTU de 1420?
No. El tamaño utilizable depende de la ruta y de la encapsulación. Un valor que funciona en una conexión puede seguir siendo demasiado grande en otra, o resultar innecesariamente pequeño. Base la decisión en observaciones reproducibles y en la documentación de la implementación.
¿Por qué no basta con cambiar el MSS?
Compruebe que se ha creado una conexión TCP nueva, que la regla se aplica al sentido pertinente y que han cambiado los valores observados en SYN y SYN-ACK. El tráfico UDP y los fallos que no dependen del tamaño de los paquetes requieren una investigación aparte.
¿Ayuda el keepalive de WireGuard con paquetes grandes?
PersistentKeepalive mantiene las asignaciones de NAT o el estado de las conexiones en el cortafuegos durante los periodos de inactividad. No cambia el tamaño de paquete que admite la ruta. Puede ser pertinente si un túnel deja de ser accesible tras permanecer inactivo, pero no resuelve un límite de tamaño de paquete reproducible durante transferencias activas.
Comentarios