Comportamiento de WSA en la detección de MTU de ruta con el uso de WCCP

Introducción

Este documento describe un problema encontrado en el que el router descarta paquetes cuando su configuración incluye la detección del Protocolo de comunicación de caché web (WCCP) y de la Unidad de transmisión máxima (MTU) de trayecto, y proporciona una solución al problema.

Antecedentes

Prefase

Cuando se analizan por separado, muchas funciones son excelentes para abordar un problema específico. Sin embargo, a veces, si se combinan dos o tres técnicas, se produce un comportamiento incómodo y se debe introducir otra función o solución alternativa para que funcione correctamente. Por ejemplo, el uso del árbol de extensión y de la convergencia OSPF (Abrir primero la ruta de acceso más corta) y L2 (Capa 2) lleva más tiempo (20 segundos) que OSPF (1 segundos si se utiliza el intervalo muerto mínimo), pero se reemplaza el árbol de extensión por el árbol de extensión múltiple (MST) y vuelve a funcionar correctamente.

Se ha observado el mismo comportamiento de interoperabilidad entre WCCP y la detección de MTU de ruta; muchos creen que se trata del problema del encabezado de encapsulación de routing genérico (GRE). Sin embargo, este documento explica la verdadera causa.

Cómo funcionan por separado Path MTU Discovery y WCCP

Descubrimiento de la MTU del trayecto

Cada línea tiene su límite en el tamaño que puede tener un paquete. Si envía un paquete mayor de lo que se admite, se descarta. Una de las funciones de los dispositivos L3 (routers) en el camino es cuidar y cortar paquetes grandes de una de las líneas a la otra para asegurarse de que la comunicación de extremo a extremo sea transparente para las capacidades de cada línea.

A veces, sin embargo, los hosts finales se configuran de tal manera que sus paquetes no se pueden cortar (por ejemplo, archivos cifrados, llamadas de voz). Esta información se comunica a través del bit Don't Fragment (DF) dentro del encabezado IP. Los routers descartan paquetes como estos, pero el router intenta informar al host final a través del mensaje del Protocolo de mensajes de control de Internet (ICMP) (tipo 3-Destino inalcanzable, código 4 - fragmentación necesaria, pero bit DF configurado). De esta manera, el host sabe que debe enviar paquetes más pequeños en el futuro.

Este es el corazón de la detección de MTU de trayecto. Puede enviar paquetes grandes con el bit DF configurado para ver si llegan al final o si recibe un informe ICMP como se describió anteriormente. Una vez que determine el tamaño máximo factible del paquete, utilícelo para cualquier otra comunicación. Consulte RFC 1191 para obtener más información.

El dispositivo de seguridad web (WSA) emplea la detección de MTU de ruta de forma predeterminada. Por lo tanto, todos sus paquetes generados tienen el bit DF configurado por la configuración predeterminada.

WCCP

Si necesita imponer seguridad en su red en el tráfico web sin que otros lo sepan, ejecutará su tráfico a través de un proxy que no sea visible. WCCP es el protocolo que se utiliza para comunicarse entre el dispositivo que intercepta (router/firewall) y el motor/proxy de caché web, que es WSA en este caso.

Este diagrama ilustra cómo fluye el tráfico en este escenario:

Funciona de la siguiente manera:

1. El cliente envía HTTP GET con el origen IP, su dirección IP (dirección IP del cliente) y la dirección IP del servidor de destino.
   
   
2. El firewall o router intercepta el HTTP GET y lo reenvía a través de WCCP GRE o L2 puro a la caché web/WSA. El origen sigue siendo la dirección IP del cliente y el destino sigue siendo la dirección IP del servidor Web.
   
   
3. El WSA inspecciona la solicitud y, si es legítima, la refleja en el servidor web. Aquí la dirección IP de destino es la dirección IP del servidor Web y la dirección IP de origen puede ser el WSA o el cliente, en función de si ha activado la suplantación de direcciones IP de cliente. Para este ejemplo, no importa porque el tráfico de retorno en ambos casos tiene que llegar a WSA.
   
   
4. El tráfico de retorno se inspecciona en el WSA.
   
   
5. El WSA envía la respuesta al cliente con la dirección IP de origen, SIEMPRE la dirección IP del servidor Web (para que el cliente no sospeche) y la dirección IP del cliente de destino.

Problema

¿Qué sucede si uno de los routers del diagrama tiene que fragmentar el tráfico? El WSA coloca el bit DF en el paquete número 5, pero debe fragmentarse. El router lo descarta y le dice al remitente que la fragmentación es necesaria pero el bit DF está configurado (código 4 de ICMP tipo 3). Después de todo, RFC 1191 tiene que funcionar ahora y el remitente debe reducir el tamaño de su paquete.

Con WCCP, la dirección IP de origen es la dirección IP del servidor web, por lo que este ICMP nunca va al WSA; más bien, intenta ir al servidor web real (recuerde, este router de la parte inferior no es consciente de WCCP). Así es como WCCP y la detección de MTU de trayectoria juntas a veces rompen su diseño de red.

Solución

Existen cuatro formas de resolver este problema:

• Descubra la MTU real y luego utilice etherconfig en el WSA para reducir la MTU de la interfaz. Recuerde que el encabezado TCP es 60, IP es 20, y cuando utiliza ICMP, eso agrega 8 bytes al encabezado IP.
  
  
• Inhabilite la detección de MTU de ruta (comando WSA CLI pathmtudiscovery). Esto da como resultado un TCP MSS de 536, que podría causar un problema de rendimiento.
  
  
• Cambie la red para que no haya fragmentación de capa 3 entre el WSA y los clientes.
  
  
• Utilice el comando ip tcp mss-adjust 1360 (u otro número calculado) en cada router de Cisco en el camino en las interfaces relevantes.

Notas complementarias

Mientras se investigaba este problema, se descubrió que si establecía el proxy explícitamente en el cliente durante un par de minutos y luego lo eliminaba, el problema se resolvía durante las siguientes cuatro a cinco horas. Esto se debe al hecho de que, en el modo explícito, el mecanismo de detección de MTU de trayectoria entre el WSA y el cliente funciona. Una vez que el WSA detecta la MTU de la trayectoria, la almacena junto con el TCP MSS detectado en la tabla interna para referencia. Al parecer, esta tabla se actualiza cada cuatro o cinco horas, lo que hace que la solución no funcione de nuevo después de tanto tiempo.