Seguridad : Firewalls Cisco Compatible IntraGuard

Notas técnicas de los sistemas compatibles: Fragmentación de IP y detección de trayecto MTU con VPN

16 Enero 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (6 Noviembre 2015) | Comentarios


Contenido


Introducción

Este documento describe el framentation IP y la detección de trayecto MTU con el VPN.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Fragmentación de IP problemas

La familia de protocolos IP fue diseñada para usar una variedad de links de transmisión. La longitud máxima del paquete de IP es 65000+ bytes. La mayoría de los links de transmisión aplican un límite más pequeño de la longitud máxima de paquetes, llamado Unidad máxima de transmisión (MTU), o el MTU, que varía con el tipo del link de transmisión. El diseño de IP adapta los límites de la longitud del paquete de link permitiendo que los routers intermedios fragmenten los paquetes IP según sea necesario para sus links salientes. El destino final de un paquete del IP es responsable de volver a reunir sus fragmentos según sea necesario.

Por ejemplo, el MTU para la mayoría de la encapsulación común del IP sobre un link de transmisión de los Ethernetes (RFC 894leavingcisco.com ) es 1500 bytes. Por el convenio el MTU incluye el IP datagram entero, incluyendo todos los encabezados IP, pero excluye los encabezados de encapsulado del link. Los encabezados de nivel de link adicionales para el encapsulado RFC 894 constan de 18 bytes, para tramas Ethernet con un tamaño máximo de 1518 bytes.

En la teoría la fragmentación debe ser en peor de los casos un problema de rendimiento bastante de menor importancia, pero puede llevar en la práctica a una incapacidad completa para comunicar usando los paquetes largos. El descubrimiento del trayecto MTU, una técnica común para evitar la fragmentación a la que nos referimos más adelante, puede fallar en forma catastrófica.

Una conexión TCP tiene dos extremos, y la fragmentación podría ocurrir en cualquier dirección. Existen dos factores que limitan la longitud máxima de los paquetes TCP en cada dirección: el MTU de la interfaz saliente de la computadora de origen, según lo visto por su pila IP, y el Maximum Segment Size (MSS), eventualmente, que fue anunciada por la computadora destino durante la configuración TCP. (Los números del MSS normalmente son 40 bytes más pequeños que los números de la MTU, ya el MSS excluye el encabezado IP de 20 bytes y el encabezado TCP de 20 bytes.)

El IPSec puede hacer los problemas de fragmentación peores, porque alarga cada paquete del IP por uno, o posiblemente dos, los encabezados IP. Estas encabezados agregadas varían de largo por la opción de los Protocolos IPSec (y si la “Transparencia NAT” de IntraPort es también funcionando), pero empírico no exceden 80 bytes por paquete. Para la mayoría de la encapsulación común del IP sobre los Ethernetes, el MTU estándar es 1500 bytes. Pero si una aplicación emitiera un paquete 1500-byte que necesitó viajar sin embargo un túnel IPsec, los Encabezados de ipsec agregados requerirían la fragmentación de cada paquete. Una buena técnica (la mejor técnica, realmente) de evitar la fragmentación con el IPSec está reduciendo el MTU de interfaz que las aplicaciones y la pila del protocolo IP consideran en los ambos extremos de la conexión TCP. Si las aplicaciones y la pila del protocolo IP piensan que el MTU de interfaz es 1420 bytes o menos, no emitirán los paquetes que necesitan ser hechos fragmentos después de la encapsulación de IPSec para el transporte a través del Routers y de los links Ethernet-tamaño-capaces.

Descubrimiento de la MTU del trayecto

La detección de MTU de trayecto (PMTUD) es una optimización por la cual una conexión TCP intenta enviar los paquetes más extensos que no se fragmentarán en el trayecto desde la fuente hacia el destino. Hace esto usando un indicador, DontFragment, en el paquete del IP. Este indicador se supone para alterar el comportamiento de un router intermedio que no pueda enviar el paquete a través de un link porque es demasiado largo. El indicador está apagado normalmente y el router debe hacer fragmentos del paquete y enviar los fragmentos. Pero si el indicador del DontFragment está prendido, el router debe desechar el paquete y volver un paquete de errores que explica la dificultad a la fuente del paquete original. PMTUD es una buena idea en principio, pero es frágil en la práctica. Con implementaciones TCP mal o pobremente configuradas y routers pobremente implementados o escudos de protección mal configurados, puede retornar a un estado persistente en el cual cada extremo de la conexión TCP espere que el otro extremo diga algo. (Llaman el router/el Firewall A donde ocurre este problema graciosamente un agujero negro de la detección de MTU de trayecto.)

Una fuente que hace el PMTUD comienza con una longitud máxima de paquetes que sea el mínimo del MTU saliente de la interfaz y del MSS anunciado durante el TCP puesto (eventualmente) + 40, y los trabajos hacia abajo de esa longitud a encontrar una Longitud del paquete que llegue el beneficiario incluso si se fija el indicador del DontFragment del paquete. Si usted ha elegido su MTU saliente cuidadosamente (y su ISP cuidadosamente), los paquetes de la longitud máxima de paquetes inicial sobrevivirán el viaje sin la fragmentación. Tan si el PMTUD está causando un problema, usted puede apenas apagarlo sin la multa de rendimiento en absoluto.

La detección de MTU de trayecto del soporte de la línea de productos del Intraport. Esto puede ser girada configurando los pares siguientes de Keyword=value en la sección general: PreTunnelFragmentation=true, y MTUDiscoveryTimeout=10.

Más información con respecto al PMTUD se puede encontrar en el RFC 1191leavingcisco.com , en el sitio web IETFleavingcisco.com .

Diagnosis

Suponga que su computadora remota se llama Alpha, que usted está intentando acceder a un servidor llamado Bravo a través del cliente IntraPort y no funciona. Los paquetes ping predeterminados son muy cortos. Si el bravo no responde “para hacer ping” (solamente el bravo responde a un “ping” de un ordenador en el LAN local), la fragmentación no es el problema. Conectividad básica del control. Verifique si traceroute (o tracert, bajo Windows) para la dirección de IP de IntraPort lo llevan a los routers correctos o si lo atascan en un "loop de ruteo" (es decir, si rebota reiteradamente entre el mismo par de servidores).

Si el bravo responde a un ping predeterminado, y si la alfa es un computador con Windows, usted puede ahora intentar (de un prompt DOS) el “ping - dirección IP l 2000 bravo”. Si usted consigue mismo un alto porcentaje de las buenas contestaciones (el >95%), usted sabe que la fragmentación y el nuevo ensamble deben trabajar correctamente, puesto que los paquetes del IP del 2000-byte no pueden viajar posiblemente unfragmented en un Ethernet. Si usted no consigue ninguna contestación, o el porcentaje de respuestas perdidas en gran medida excede el porcentaje de las contestaciones perdidas para los paquetes ping de la valor por defecto-longitud, es plausible que su problema está siendo causado por la fragmentación.

Al jugar con el ping de Windows, sea consciente que cuando usted especifica “- l <n>”, los paquetes del IP que usted genera es realmente <n> + 28 bytes de largo, por el mismo convenio usado en el cálculo del MTU: todos los encabezados IP y no los encabezados de nivel de link. También sea consciente que usted puede fijar el indicador del DontFragment en sus paquetes ping: es “- el parámetro f”. Si usted envía un paquete largo con el indicador “-f” fijado y usted no oye ninguna disculpa y ninguna contestación, usted puede ser que vea a un agujero negro PMTUD. Incluso puede ubicarlo utilizando "tracert" (traceroute de Windows) para analizar la cadena de routers entre usted y su destino, y realizar un "ping" para investigar cada router.

Parámetros de la configuración Fragmentación-relacionados para los diversos sistemas operativos de la computadora cliente

Windows 9x

Un MaxMTU del parámetro de registro opcional se puede asociar a los atascamientos del adaptador. Influencia al parecer el MTU saliente según lo visto por la pila del protocolo IP, y el MSS anunciado durante la configuración TCP. Si el MaxMTU falta de un atascamiento, el MTU predeterminado para el adaptador (1500 para los Ethernetes) se asume. Si usted está viendo los problemas de la fragmentación, fije el MaxMTU en su interfaz de la red activa TCP a 1420. Si usted ha hecho que (reiniciado) y usted todavía está teniendo problema, sugiero que usted fijado el parámetro de registro PMTUDiscovery explícitamente a 0.

Para los detalles en donde encontrar los parámetros, lea el artículo de la base de conocimientos de Microsoft Q158474leavingcisco.com . El parámetro MaxMTU es difícil: no es fácil imaginar que el atar (puesto en un índice por cuatro dígitos decimales) es el usted quiere (indirecta: busque la dirección IP), y los cambios bastantes menores en su configuración de interconexión de redes pueden hacer que el parámetro desaparece. Puede usar la versión de prueba de la utilidad TweakDUN o la versión de donación a voluntad de la utilidad MTUSpeed si prefiere no poner en riesgo la instalación de su sistema operativo con alteraciones manuales del registro.

Windows NT 4.0

Para información general sobre los parámetros de registro IP de NT, lea el artículo de la base de conocimientos de Microsoft Q120642leavingcisco.com . El artículo Q183229leavingcisco.com entra el detalle específico sobre las interacciones del MTU con el Remote Access Services, que el cliente del Intraport hasta la versión 3.3.x utiliza. El artículo parece sugerir que no tiene otra alternativa más que un MTU de 1500 para RAS salvo que instale como mínimo un SP4 y que efectúe los cambios de registro indicados. Usted puede intentar la utilidad de trialware TweakDUN si usted preferiría no arriesgar su instalación del OS con registro-cortar manual.

MacOS

Aparentemente no existe una forma manual de ajustar MTU en una Macintosh. Afortunadamente, hay el sintonizador avanzado OT de la utilidad de trialwareleavingcisco.com , que lleva la semejanza notable al ndd de los Solaris abajo.

Unix

Diversos sabores de Unix lo hacen diferentemente. La utilidad ifconfig puede ser usada (como raíz) para alterar el MTU de una interfaz. Con Unix más viejo el cambio de otros parámetros requiere generalmente recompiling el corazón. Con Unix más reciente, los valores de parámetros normalmente se pueden cambiar durante el tiempo de ejecución empleado las utilidades administrativas. Solaris 2.2 y sus versiones posteriores, por ejemplo, tienen una utilidad administrativa ndd, mientras que 4.4BSD y sus versiones posteriores usan la utilidad sysctl. Marque sus página de man, y/o lea el “TCP/IP ilustrado, el volumen el 1", por W. Richard Stevens, un libro excelente que cubra el tema.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 17639